Re: charset list

A. Vine wrote:

>Bob Jung wrote:
>
>>A. Vine wrote:
>>
>>>Mail client generated names and mail server recognized names can also be
>>>useful,
>>>but there are way too many of them to list, and this info is usually not
>>>readily
>>>available.
>>>
>>Mail charsets are trickier.  While the core mail RFCs allow any charset
>>encoding, there are other RFCs (e.g., for Japanese) and other internet
>>conventions which enourage the use of certain charsets for certain languages
>>to enhance interoperability.  When creating new email, Mozilla/Netscape
>>restricts the user to sending in charsets an accordance with these charsets.
>>
>
>Thanks to Bob for the excellent info on Mozilla.  Note that while there are
>informational RFCs on what specific charsets to use for email in certain
>scripts, they are not necessarily followed.
>
Exactly, that is why I wrote "internet conventions" in addition to the RFCs:

> there are other RFCs (e.g., for Japanese) and other internet conventions
> which enourage the use of certain charsets for certain languages to
> enhance interoperability.

>  For example, Korean emails are
>supposed to be formatted with EUC-KR in the headers and ISO-2022-KR in the body,
>according to RFC 1557.  I don't think I've ever seen this actually occur.  In
>the list of Mozilla mailedit charsets, ISO-2022-KR isn't even listed, see:
>
>http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/locale/en-US/navigator.properties#29
>
Although there is an RFC for ISO-2022-KR, the more widely used 
convention in Korea is to use EUC-KR in email.  And that is what 
Mozilla/Netscape uses for creating new email.  

>So, once again, it's best to know which mail clients/servers you're supporting
>and make a consolidated list from them, although this is not information which
>is readily available like it is for Mozilla.
>
The email standards AND conventions can be very complicated.  And 
sometimes the conventions change over time...

-bob