SqWebMail has an ability to handle multiple character set (charset) like utf-8, iso-2022-jp, iso-8859-01, and so on. The charset is specified in html template directory CHARSET file. The charset is used to send data with Web browser and SMTP server.
I use sqwebmail in japanese with japanese patch which I developed. In Japan, iso-2022-jp is widely used as e-mail contents charset. Iso-2022-jp is shift-in and shift-out style 7bit encoding. The japanese patch assumes CHARSET is iso-2022-jp, and do some iso-2022-jp specific fix, so I think that merging with main source is hard. To use SqWebMail in other languages (at least in japanese), I suggest to enhance current SqWebMail charset capability. Practically, I suggest to separate the Web browser charset and e-mail content charset to send. CHARSET specifies Web browser charset like until now, and OUTGOING_CHARSET specifies outgoing e-mail content charset. Then, In japanese environment, I can set CHARSET=utf-8 and OUTGOING_CHARSET=iso-2022-jp. Utf-8 (generally, 8bit non-shift-in-out sytle coding) is preferred to handle strings inside SqWebMail, Iso-2022-jp is preferred to be received by many poor terminals including celler phone. Of course, when CHARSET is same as OUTGOING_CHARSET, the behavior is same as now. I have developed such patch and attach it in this mail. I developed it under 3.6.0. (Time flies during I straggled) I hope this concept will be merged into main source tree. I found some modification between 3.6.0 and 3.6.2 corrupt with my patch. rfc2047_print_unicode() and header_wrap() are similar works, and I think it's possible to integrate these works. And my patch includes some rfc2047 compliance bug fix. toshi -- Toshikazu Ichikawa <[EMAIL PROTECTED]> Site: http://www.toshikazu.org/ (including my PGP public key) Key fingerprint = 1C98 7233 F225 D783 0A70 A958 2876 F825 F0CD 25EA
sqwebmail_3_6_0_outgoing_charset_20040203.patch.gz
Description: Binary data
