Hatuka*nezumi - IKEDA Soji writes:
On Thu, 06 May 2004 07:18:31 -0400 Sam Varshavchik <[EMAIL PROTECTED]> wrote:
The unicode list includes most common character sets in use. The unsupported charsets are rarely seen, and in any case if their Unicode map is known they can simply be added.
Sometimes adding new charset costs much. For example: JIS X 0213 (ISO-2022-JP-3 etc.) will be used for a language of indigenous people in Japan. However, it is a superset of JIS X 0208 (ISO-2022-JP etc.) and adds over 4000 charater maps.
If the character set is not referenced in the unicode list, sqwebmail will not have anything to do with it.
It's always was true that in order to set sqwebmail to use a particular character set (excluding the non-unicode iso-8859-1 baseline), that character set must be compiled in via the unicode option). Although it might be possible to force sqwebmail to pretend to use a character set that it doesn't really know about, this has never been a âsupportedâ configuration, whatever âsupportedâ actually means in this context.
Therefore, if someone wants to use ISO-2022-JP-3 for encoding headers, or message content, they'll just have to provide a unicode map for it.
I think an inexpensive alternative to adding charsets is encoding text off-line and upload it as inline text/plain attachment. This workaround will also reduce update works caused only by addition of charset support, even if it's a small charset (such as VISCII).
How about this idea?
The problem: after uploading the message sqwebmail will have to be able to display it, so it must know the character set.
pgpZ1jCIcdahj.pgp
Description: PGP signature
