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