pmaydell@chiark.greenend.org.uk wrote:
Of course this is all rather mishandled anyway. What we ought to be
doing is letting the user read and compose messages in their local
charset (as defined by LC_CTYPE) and using iconv to automatically
convert to/from whatever charset is required for the email being
This can mostly all be done now. I made some changes that are in 1.2
that use iconv for converting encoded headers. These default to LC_CTYPE
where MM_CHARSET is not set. And using mime makes it easy to compose
messages in other charsets.
For viewing messages, it is easy to add a few profile entries to do the
conversion:
mhshow-charset-utf-8: csconv utf-8 '%s'
mhshow-charset-iso-8859-15: csconv iso-8859-15 '%s'
and so on...
This is at least flexible enough that you can do things like:
mhshow-charset-us-ascii: csconv windows-1252 '%s'
mhshow-charset-iso-8859-1: csconv windows-1252 '%s'
to cope with lying Windows mailers (windows-1252 is a superset of the
other charsets). Originally, this mhshow profile entry was intended to
launch xterm with the different font but I just call iconv or recode
I've got a few different variants of the csconv script. For example:
eval "$2" | iconv -f "$1" -t "${MM_CHARSET:-UTF-8}//TRANSLIT"
That isn't perfect, however. One difficulty lies with things like HTML
e-mails - the charset can be in an HTML meta tag instead of the MIME
header. The same can apply to XML files. None of w3c, links, lynx or
html2text seem to cope well with the different charsets.
Would you want to hardcode use of iconv for message bodies within
mhshow?
Oliver
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers