Re: content encoding etc.

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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQBAmsvOx9p3GYHlUOIRAuD5AJ9pqDlOkYsySFE3AwNRxe5hPZ3oswCfWeAr
wjzKskxxA0PiOFwvVGihOs8=
=Mmp/
-----END PGP SIGNATURE-----