[Mew-Win32 01198] Re: 文字化け

1999年 2月 19日 (金) 03:11:29 JST

後藤＠太陽計測です

ちょっとMIMEな話しが絡むので Cc: mew-dist します（ちょっと長文）

まずは mew-win32でのmew-fake-cdp問題

>>>>> at 18 Feb 1999 23:00:32 +0900, 新岡 <ken at example.com> said,

新岡> 新岡です。
新岡> mew-fake-cdp には、大変お世話になっております。

＃でも X-Mailer:が。。。(^^;

新岡> 以下のようなケースでファイル名が ``"hoge'' としか表示されなくなりました。
新岡> 以前のバージョンでは表示されていたように思います。
新岡> ``"'' を削ると問題無く表示されます。
新岡> 仕様が変更になったのでしょうか。

結論から言いますと、RFC-2231のサポートのための弊害といえます。

こういった場合でも、それなりに処理できるようにした
mew-fake-cdp.elの修正版(rev. 1.12)をおいておきます。
げっとしてちょ。

http://www.imasy.or.jp/~gotoh/lisp/mew-fake-cdp.el

以下ちょっと解説

新岡> Mew version 1.94b7 での表示のされかた。

新岡> Content-Type:	application/octet-stream
新岡> Encoding: 	base64
新岡> Size:		22528 bytes
新岡> Filename:	"hoge
新岡> Program:	fiber.exe

これはmew-fake-cdp処理でエラーが発生しているなどの原因によるものではな
く、mewの mew-decode-mime-headerがsyntaxを作った時点で情報が欠落してい
るのが原因です。mew-fake-cdpでは、mew-decode-mime-headerの解析結果を
後加工しているため、これに依存してしまうわけです。

ではなぜ情報が欠落してしまうかというと、これがちょっと複雑で、

新岡> メールの内容
新岡> ------ =_NextPart_000_01BE598A.1349DFC0
新岡> Content-Type: application/octet-stream; name="=?iso-2022-jp?B?aG9nZQo=?=
新岡>  =?iso-2022-jp?B?g2WDWINn?="
新岡> Content-Transfer-Encoding: base64

name=の内容が
 (1) ２行にまたがっていて
 (2) parameterのvalueがquoteされている
のが原因のようです。

パラメータの切り出しをするmew-addrstr-parse-syntax-listにて処理される
際にvalue がquoteされているため\nは残されます。この時点では
name="=?iso-2022-jp?B?aG9nZQo=?=\n =?iso-2022-jp?B?g2WDWINn?="となって
います。

次に、これをRFC-2231にしたがったパラメータ解析を行うmew-param-analyze
でstring-matchすると、\nの前までがmatchするため 
name="=?iso-2022-jp?B?aG9nZQo=?= というパラメータとなってしまい、結果
うまく表示できず、

Filename: "hoge

となってしまうわけです。

quoteをはずすとうまくいくというのは、この場合は
mew-addrstr-parse-syntax-listが\nを無視(削除)するため、
その後、mew-param-analyzeにかかる際には

name==?iso-2022-jp?B?aG9nZQo=?==?iso-2022-jp?B?g2WDWINn?=

となっているため、全ての情報がsytnaxに格納されるというわけです。
結果、mew-fake-cdp君もデコードすると。

＃ちょっとややこしいですね。:-(

mew-fake-cdpでの今回の対処は、mew-param-analyzeに文字列が渡る前に
"\n "を削除してしまうようなadviceを入れたことで対処しています。

しかしquoteをはずせばうまくいくというのは偶然の産物のようなもので、本
筋はもう少し考えなければならないと思う次第で、さて、やっとこさ、
mew-distに振った本題です。

ここいらへんは結構やらしいのですが、RFC-2045(MIME)ではparameterのvalue
はquoted-stringを許しています。RFC-822ではquoted-stringは
linear-white-spaceを許しています。RFC-2231では

  regular-parameter := regular-parameter-name "=" value

となっています。つまりvalueとしてはquoteされて複数行にまたがるものが許
されているのですが、mew-param-analyzeはそれを許容していないようです。

valueとして=?ISO-2022-JP?B?....?=というエンコードをすること自体が間違
いだということは置いといて、、今回のケースでのmew-param-analyzeの解析
結果は

name="=?iso-2022-jp?B?aG9nZQo=?= =?iso-2022-jp?B?g2WDWINn?="

となるべきではないかな、と思います。いかがなものでしょう。

また、この件で調べていて気づいたのですが、先にkazuさんがいっておられた

>>>>> in Subject: [Mew-dist 07459] filename and quote
>>>>> at Mon, 15 Feb 1999 22:56:42 +0900, kazu <kazu at example.com> said,
kazu> "." は特殊な文字なので、これは quote で囲まないといけません。

というのは、RFC-822のspecialsとしては正しいのですが、RFC-2045のtokenを
あらわすtspecialsでは以下のように「除外される」とあります。
つまり、name=hoge.txtはquoteする必要無いと思いますが、いかがでしょうか。

>>> [RFC-2045] Section 5.1
>     value := token / quoted-string
>
>     token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
>                 or tspecials>
>
>     tspecials :=  "(" / ")" / "<" / ">" / "@" /
>                   "," / ";" / ":" / "\" / <">
>                   "/" / "[" / "]" / "?" / "="
>                   ; Must be in quoted-string,
>                   ; to use within parameter values
...snip...
>   Note that the definition of "tspecials" is the same as the RFC 822
>   definition of "specials" with the addition of the three characters
>   "/", "?", and "=", and the removal of ".".
                       ~~~~~~~~~~~~~~~~~~~~~~~

P.S.
ちなみに件のメールのX-Mailer:は何者でしょうか？＞新岡さん

name="=?iso-2022-jp?B?aG9nZQo=?=
 =?iso-2022-jp?B?g2WDWINn?="

を好意的にデコードすると"hogeテスト" となりますが、"テスト"の部分が
Shift_JISですね。それに、hogeの後にLFが入ってます。
つまり、"hoge\n\203e\203X\203g" となります。X-(
＃なんじゃそりゃ！ 誰だおまえ！ ってカンジ

いじょ

--- Regards,
 Shun-ichi Goto  <gotoh at example.com>
   R&D Group, TAIYO Corp., Tokyo, JAPAN