[bugfixed] mm-charset-override-alist isn't used in decoding headers

[bugfixed] mm-charset-override-alist isn't used in decoding headers

[Katsumi Yamaoka]

Hi,

I receive Japanese mails that are labeled with charset=gb2312,
however most of them use charset=gbk in reality.  So, Gnus normally
fails in decoding those messages.  Adding the `(gb2312 . gbk)' pair
to `mm-charset-override-alist' solves it in decoding bodies, however
it is not effective in decoding headers.  Here is an example:

(rfc2047-decode-string "=?gb2312?b?srubcg==?=")

I've fixed the rfc2047 decoder so as to use `mm-charset-override-alist'.

In addition, I've added the `(gb2312 . gbk)' pair to the custom
choices (not the default value) of `mm-charset-override-alist'.
Although the `gbk' charset is a superset of the `gb2312' charset,
the reason I didn't add the pair to the default value of
`mm-charset-override-alist' is that the `gbk' is not available in
Emacs 21 normally and there seemed to be no smart way to exclude
it in such Emacs versions.

(Note that that I mention here is the `gbk' charset, not the `gbk'
 coding system.  So, `mm-charset-to-coding-system' is the best
 choice for checking whether it is available or not.  However,
 when loading mm-util,elc the default value section and/or the
 `:set' section of `(defcustom mm-charset-override-alist ...)'
 are processed before defining that function.)

Regards,

Re: [bugfixed] mm-charset-override-alist isn't used in decoding headers

[Reiner Steib]

On Wed, Dec 10 2008, Katsumi Yamaoka wrote:

> (Note that that I mention here is the `gbk' charset, not the `gbk'
>  coding system.  So, `mm-charset-to-coding-system' is the best
>  choice for checking whether it is available or not.  However,
>  when loading mm-util,elc the default value section and/or the
>  `:set' section of `(defcustom mm-charset-override-alist ...)'
>  are processed before defining that function.)

Would it help to move the defcustom down (or the defun up)?  Or would
this introduce other problems?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: [bugfixed] mm-charset-override-alist isn't used in decoding headers

[Katsumi Yamaoka]

>>>>> Reiner Steib wrote:
> On Wed, Dec 10 2008, Katsumi Yamaoka wrote:

>> (Note that that I mention here is the `gbk' charset, not the `gbk'
>>  coding system.  So, `mm-charset-to-coding-system' is the best
>>  choice for checking whether it is available or not.  However,
>>  when loading mm-util,elc the default value section and/or the
>>  `:set' section of `(defcustom mm-charset-override-alist ...)'
>>  are processed before defining that function.)

> Would it help to move the defcustom down (or the defun up)?  Or would
> this introduce other problems?

Thanks.  There were two other reasons that made me hesitate to
add the `(gb2312 . gbk)' pair to `mm-charset-override-alist':

1. In Emacs 22 the `gbk' charset is available because of
`mm-charset-synonym-alist', however it does not support gbk
characters fully.  For example:

(rfc2047-decode-string "=?gbk?B?m3I=?=")
 => "\x9br"

2. In XEmacs 21.4 w/o the Mule feature,
(mm-charset-to-coding-system 'gbk) returns the symbol `gbk'.

But I decided to consider that 1. is not due to a Gnus bug, and
realized 2. is not a real problem (it won't get to be a straight
cause of an error, and it is a matter of course that non-Mule
XEmacs doesn't display gbk messages correctly).

So I've added the `(gb2312 . gbk)' pair to the default value of
`mm-charset-override-alist' for Emacsen that supports gbk, having
moved `mm-charset-to-coding-system' and `mm-charset-eval-alist'
forward.  In addition, I've added the optional argument `silent'
to `mm-charset-to-coding-system' so that it may not issue a warning
message when examining whether gbk is available.

Regards,