From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/46335 Path: main.gmane.org!not-for-mail From: Katsumi Yamaoka Newsgroups: gmane.emacs.gnus.general Subject: Re: detecting encoding for Japanese Date: Mon, 02 Sep 2002 21:16:40 +0900 Organization: Emacsen advocacy group Sender: owner-ding@hpc.uh.edu Message-ID: References: <87sn0y43mc.fsf@ghidra.vail> <87fzwxycy9.fsf@ghidra.vail> <873csxws40.fsf@ghidra.vail> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: main.gmane.org 1030969017 5551 127.0.0.1 (2 Sep 2002 12:16:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 2 Sep 2002 12:16:57 +0000 (UTC) Cc: ding@gnus.org Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17lq8V-0001RP-00 for ; Mon, 02 Sep 2002 14:16:55 +0200 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 17lq94-0003Cs-00; Mon, 02 Sep 2002 07:17:30 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Mon, 02 Sep 2002 07:18:04 -0500 (CDT) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id HAA22914 for ; Mon, 2 Sep 2002 07:17:51 -0500 (CDT) Original-Received: (qmail 28842 invoked by alias); 2 Sep 2002 12:17:12 -0000 Original-Received: (qmail 28837 invoked from network); 2 Sep 2002 12:17:12 -0000 Original-Received: from unknown (HELO mars.web-hosting.com) (207.228.244.150) by gnus.org with SMTP; 2 Sep 2002 12:17:12 -0000 Original-Received: from localhost ([207.228.245.242]) by mars.web-hosting.com (8.11.1/8.11.1) with ESMTP id g82CH9g00457; Mon, 2 Sep 2002 08:17:10 -0400 (EDT) Original-To: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai =?iso-8859-15?q?Gro=DFjohann?=) User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.4 (Informed Management, sparc-sun-solaris2.6) X-Face: #kKnN,xUnmKia.'[pp`;Omh}odZK)?7wQSl"4o04=EixTF+V[""w~iNbM9ZL+.b*_CxUmFk B#Fu[*?MZZH@IkN:!"\w%I_zt>[$nm7nQosZ<3eu;B:$Q_:p!',P.c0-_Cy[dz4oIpw0ESA^D*1Lw= L&i*6&( Cancel-Lock: sha1:XeQAQKS3VaTNEOr4nX6eT8/6bGQ= X-Hashcash: 020902:Kai.Grossjohann@CS.Uni-Dortmund.DE:98b70074536f5c8c X-Hashcash: 020902:ding@gnus.org:0b2d17330565b076 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:46335 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:46335 --=-=-= Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable >>>>> In >>>>> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Gro=DFjohann) 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: --=-=-= Content-Type: text/plain; charset=euc-kr Content-Disposition: inline Content-Transfer-Encoding: base64 oruivaK/os2izw0K --=-=-= Content-Disposition: inline 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 --=-=-=--