[Mew-dist 07534] Re: [Mew-Win32 01196] Re: 文字化け
Shun-ichi GOTO
gotoh at example.com
1999年 2月 19日 (金) 03:13:59 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行にまたがっていて
(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
Mew-dist メーリングリストの案内