nmh-workers
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] base64 ... just looking for advice

From: Wolfgang Denk
Subject: Re: [Nmh-workers] base64 ... just looking for advice
Date: Sun, 24 Jan 2016 18:40:23 +0100 
Dear David,

In message <address@hidden> you wrote:
> 
> > Either fixmhmsg should not touch the HTML part at all, i. e. leave it
> > quoted-printable encoded as it was in the original message,  or, if it
> > decodes it, it should use the same character set for all parts.
> 
> I'd rather not leave it as quoted-printable.  More generally, the content
> could be base64 encoded, which I would really want to decode.

Yes, I understand your intentions.  But I cannot see how this could be
done easily...

> > Using two different character sets for parts in a single message is
> > somehow bound to break...
> 
> I'm not sure what mhfixmsg should do here.  Should it convert
> text/html content?  All text content?

Well, converting all text content would at least be consistent - but
this would raise new problems.  For example, the HTML text in question
looks like this:

Content-Type: text/html; charset="iso-8859-1"
MIME-Version: 1.0 
Content-Transfer-Encoding: quoted-printable
 
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
...

If we convert the text to UTF-8, we would probably confuse the
browser, when we present a UTF-8 encoded file which claims to be
iso-8859-1.  And I feel that parsing and modifying the actual content
of the message parts is something that should NOT be done.

OTOH, we might always have such a problem.  We cannot know if even
a text/plain part comes in some internal format that includes
information about the used character set.  So converting is always
a somewhat risky operation.

It depends on the user - speaking for myself only, I would happily
accept this risk for text/plain parts, as the number of cases where
this is really helpful is huge compared to ny theoretical pitfalls;
for text/html I hesitate, as the very first example I ran into shows
such a problem.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: address@hidden
"Plan to throw one away. You will anyway."
                              - Fred Brooks, "The Mythical Man Month"
reply via email to
[Prev in Thread] Current Thread [Next in Thread]