Re: detecting encoding for Japanese

[Katsumi Yamaoka <yamaoka@jpl.org>]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

>>>>> In <vaf1y8g5yck.fsf@INBOX.auto.gnus.tok.lucy.cs.uni-dortmund.de>
>>>>>	Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:

>> So, I recommend Japanese Gnus users customize the option
>> `mm-coding-system-priorities' to have popular Japanese charsets
>> as follows:
>>
>> (setq mm-coding-system-priorities
>>       '(iso-2022-jp iso-2022-jp-2 japanese-shift-jis utf-8))

Kai> Why are euc-jp and euc-jisx0213 missing from this list?  (Maybe
Kai> they are different names for an encoding already in the above
Kai> list?)

Yes, there's not euc-jp.  Saying beforehand, I'm not so detailed
to characters.  Before MIME generally spread, iso-2022-jp and
similar 7-bit codes were used in Japan without using any
designator.  It would be the cause that iso-2022-jp is generally
used even now, and any codes other than iso-2022-jp cannot be
read in very old MUAs.

iso-2022-jp-2 is for Japanese extra characters including a part
of Korean symbols like:

[-- Attachment #2: Type: text/plain, Size: 12 bytes --]

♤♡♧♨☎

[-- Attachment #3: Type: text/plain, Size: 1813 bytes --]


shift-jis is the addition for katakana-jisx0201 characters
(which is normally called hankaku-katakana), it is rarely used,
though.  And utf-8 is the addition for characters other than
these.

Kai> Also, if the above change is good for Japanese users, why isn't
Kai> it good for everybody else, too?  Do you think that there are
Kai> non-Japanese out there who prefer the current behavior?

Kai> Maybe it is a good idea to put your change in Gnus.

By surely using this, I can write Japanese and doubtful English.
However, I do not know the other language (also Chinese and
Korean).  Therefore, I cannot judge whether it is proper.

[...]

Kai> Another thought: Mule itself also has a priority list of
Kai> encodings.  So I wonder why does Gnus need another priority list?
Kai> Normally, I'd guess that Japanese would normally configure their
Kai> Emacs for the right priorities, and then Gnus should do the right
Kai> thing automatically.  There could be two reasons why this is not
Kai> happening: (1) Japanese use a different encoding in email than in
Kai> editing files, or (2) the priorities that Emacs sets up normally
Kai> do not propagate properly to Gnus, or (3) Emacs does not set
Kai> itself up for the right priorities at all when users setup a
Kai> Japanese language environment.  Yes, I can't count...

That's a good consideration.  (1) is the main reason.  Though
iso-2022-jp is used for mail messages, euc-jp has mainly been
used in UNIX and DOS has used shift_jis.  Although it will be
different with the system-type, Emacs gives a priority to euc-jp
or shift_jis in general and it is a right way for editing files.
It seems to be a good way that Emacs offers the priority list
for mails apart from the list for files for the specified
language environment.
-- 
Katsumi Yamaoka <yamaoka@jpl.org>