Fri, 4 May 2007 21:58:53 -0400
|
On Thu, 3 May 2007 15:27:56 -0500, Winship <[log in to unmask]> wrote:
> On Thu, 3 May 2007, Hal Keen wrote:
>> But all three of your email samples were conveyed in quoted-
>> printable. Some
>> sample header information and demonstration text from each (with
>> colons used
>> as "vertical ellipses" to indicate where I have snipped):
>
> If you will look at the headers, the person often uses utf-8 for
> her email
> to this list (check the Contnet-Type: field).
Thank you for helping me understand what's going on here. You seem to
be saying that it's the way a particular email client renders
content. If that's the case though why are do about 10% of people's
messages have these = characters and not all or none of them?
Curiously the characters don't appear with the = coding on the
archive. 4′33″ gets rendered as 4′33″ in the archive.
It seemed to make sense that it was the Content-Transfer-Encoding:
field that was not converting the characters and adding =20 for line
feeds, but then I saw the messages that appear this way on my
apparently utf-8 Apple Mail.app also appeared with the = characters
on my Palm Treo, so I suppose that's utf-8 as well.
Apple Mail uses Automatic encoding
<http://docs.info.apple.com/article.html?path=Dotmac/Mail/en/mac70.html>
What seems to be happening is that when someone using an email
application that does "automatic encoding" encounters a utf-8
character, it changes to that content-type. This can be done with cut
and paste (as with my 4'33' example) or by replying to an email that
is already encoded in utf-8.
Accents will trigger the utf-8 encoding as well.
I'll send a small email after this without any accents, extended
characters or pastes that will show Content-Transfer-Encoding to be
7bit.
It seems there should be a way for listserv to overlook 8 bit
characters. Perhaps that is what "Translate = No" will do.
KEF
|
|
|