Le Mer 10 nov 15:50:54 2004, Brian Candler écrit: > On Wed, Nov 10, 2004 at 11:56:28AM +0100, Laurent Wacrenier wrote: > > I've noticed that when displaying an HML message with a charset > > different than sqwebmail one's (utf-8 in my case), non ascii > > characters are not converted, so they are badly rendered. It work fine > > when the message is a multipart/alternative and the "Display HTML > > E-Mail" preference is off. > > > > I've looked in folder.c to try a patch, but theyre is a big stack of > > filters, so it's uneasy for me to make a clean fix. > > Can I suggest that for any sqwebmail rendering problem, the first step is to > provide us with a sample message, and this must be done by taking the > message file directly out of the Maildir/cur directory, gzipping it, and > then attaching it to a message posted to the list (in other words, simply > forwarding the message to the list is not sufficient). A screenshot showing > how it renders in your browser would also be useful, as well as a > description of how you think it should be rendered differently. Also useful > is a tcpdump of the HTTP session between the client and browser when > fetching that page: try something like > tcpdump -i eth0 -n -s1500 -X tcp port 80 >tcpdump.out > on the server.
tcpdump is unusable on a server with a lot of people connecting. Just drop a file with this in your Maildir/cur folder ------- >From [EMAIL PROTECTED] Fri Nov 12 11:58:01 2004 Return-Path: <[EMAIL PROTECTED]> Date: Fri, 12 Nov 2004 11:58:00 +0100 From: Laurent Wacrenier <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: test Mime-Version: 1.0 Content-Type: text/html; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable euro: =A4 ------- Then read it with "lynx -mime_header", got a Content-Type: text/html; charset=utf-8 header as I have configured in the CHARSET file Then using "LANG=C od -c" to read the content, I got : 0032260 > < t r > < t d > \n e u r o : 0032300 244 \n < / t d > < / t r > < / t a 244 is the octal value of the euro sign position in iso-8859-15 but not a legal utf-8 value. replacing text/html by text/plain, all is fine 0032120 t e x t - p l a i n " > e u r o 0032140 : 342 202 254 \n < / p r e > < b r 342 202 254 is the real octal representation of the euro sign in utf-8. > Next, please provide information on the exact version of sqwebmail you are > running, the O/S and webserver you are running it under, and the browser you > are viewing the page in. Also list the ./configure options used to build > sqwebmail, and any changes you have made to templates. I'm using 4.0.6 version. I've looked into the source, seen a conversion routine used for plain text but not for html. Then, I've checked in the CVS version before complaining and the code around this has not changed. The templates are translated in french and customized for my need, it's too much posting for a missing routine. All localization file refer to utf-8 and it works, for plain/text % grep . CHARSET LOCALE CHARSET:utf-8 LOCALE:fr_FR.UTF-8 The sole browser dependency about this is theyre way to display a invalid character. The configure option --enable-unicode is on, as the converted text/plain show it. If you read only english messages, you don't have to care with this (you may have sometime glitch with the POUND sign in England or EURO in Ireland). If you use a west european language you may simply configure sqwemail for ISO 8859-1 or ISO 8859-15, both are used in equal proportion, and the message will be readable most of the time, even if theyre is a warning about unsuported character set. On the other case (russian, japanese, etc.), or if you don't want the warning and the glitches, you should use a universal character set and utf-8. > There are many problems which could be there, some of which may not be > sqwebmail's: for example, the message itself may be malformed (e.g. wrong > MIME headers), or there may be a bug in your browser. Without visibility of > the exact message which causes the problem, we'd only be able to guess at > what the problem might or might not be. The problem, is simply that the charset conversion routine is missing in html decoding. I'll had produced a patch if they was not a lot of filters in message display routines, each filter having different API. It should be much more easy to do for the guy who write/manage the routines.
