On 2010-07-27, Paul E Condon wrote:
> I use Mutt in a system that is running Debian Squeeze. I have
> installed the system recently and it should have no legacy
> cruft from Lenny or whatever. I did this new install because
> I was having serious problems with charsets and utf8. Almost
> all such are gone from this. But a problem with Mutt remains.
>
> In the pager, I see backslash strings instead of quotes and
> apostorphies in incoming emails. The offending emails (one of
> them, at least) are charset="iso-8859-1".
> locales -a indicates that this charset is loaded on the system
>
> I have looked at the MuttFaq/Charset web page.
>
> 1) The short answer does not work. My copy of Mutt informs me that
> LC_TYPE is not a recognized variable name.
>
> 2) I have verified that my system settings conform to the Long Answer
> except that I have replace 'de_DE' with 'en_US'. The verify check
> gives the correct indication that utf-8 is detected. locale -a gives
>
> C
> POSIX
> en_US
> en_US.iso88591
> en_US.utf8
>
> But I still see lines like
>
> African-American experience, ones who understand \223the slave thing,\224 as
> a top
> ^^^^ ^^^^
>
> (Not sure this will appear correctly on your computer. Your computer may
> actually catch the backslash sequences and display the intended quotes.
> On my computer there are TWO backslashes, each followed by three digits.)
>
> I incline toward the belief that my problem is rooted in Squeeze, not Mutt.
The problem is rooted in Redmond.
> But there may be some suggestions that you can make that will firm up
> evidence for some sort of bug report to somebody. The Mutt that I use is
> from a Debian repository, not compiled by me, and downloaded with a very
> ordinary sources.list.
>
> Has anyone here seen this? Could the problem be that 'en_US.iso88591'
> should be 'en_US.iso88591-1'? The email in the expample contains
> 'charset="iso-8859-1"'. Suggestions for a fix/work around?
The problem is that those characters, \223 and \224, are not part of
ISO-8859-1, but are part of Microsoft's extensions to ISO-8859-1.
Microsoft e-mail clients and possibly other clients that strive for
compatibility will include those characters in a message but
improperly identify the content as "iso-8859-1". Within Mutt at
least, that Microsoft-extended charset is referred to as
windows-1252. It was suggested on this list some time ago to add
the following to one's muttrc to work around this problem.
set assumed_charset=windows-1252
charset-hook ^us-ascii$ windows-1252
charset-hook ^iso-8859-1$ windows-1252
That's what I've done and it seems to work, but I'm no expert in
charsets.
HTH,
Gary