[Mew-dist 08115] Re: B-encoded header routine

1999年 3月 16日 (火) 23:35:30 JST

後藤＠太陽計測です

＃Mewに直接関係無い話題に長文で返すのは少々気が引けるのですが...

出沢さん、こんにちは。以前ruby-listのほうでbase64.rb モジュールに難癖を
つけてしまった記憶が。。。(^_^;

rubyはめっきり触ってないし、ruby-listは読み流しです。。。あぁ

>>>>> at Tue, 16 Mar 1999 22:09:37 +0900
>>>>> 出沢 <dezawa at example.com> said,
出沢>    法律D：ASCII文字列(\sを含む)が続く場合は、改行を追加してはならない(4から)

なぜ？

ASCII文字列が「何に」続く場合のことか不明ですが、「4から」ということか
らすると、日本語(encoded-word)に空白またはASCIIが続く場合ということで
すよね？

空白が続く場合は １つのLWSP-charは CRLF + LWSP-char に置き換えて保存す
ることが出来る(folding)はずですので問題はないですよね。

unfold時のルールは以下のように記述されています

[RFC822 3.1.1]
>             The process of moving  from  this  folded   multiple-line
>        representation  of a header field to its single line represen-
>        tation is called "unfolding".  Unfolding  is  accomplished  by
>        regarding   CRLF   immediately  followed  by  a  LWSP-char  as
>        equivalent to the LWSP-char.

encoded-word に空白ではなくASCIIが続く場合は、そもそも許されていません
からこれはまとめてencodeするケースにあたりますから、このばあいは改行は
別の個所になりますので問題とはならないのでは？

出沢> 3 しかし、2,3,4,A,B,C,D を守ると 1 を満たすことができなくなる場合がでてきます。
出沢>   このような場合どうすべきでしょう。
出沢>     53_bytes_ASCII_string_with/without_white_space あ
出沢>     あ 53_bytes_ASCII_string_with/without_white_space
出沢>     23_bytes_ASCII_string あ 30_bytes_ASCII_string_wi
出沢>     20_bytes_ASCII あ 10_bytes_ASCII あ 23_bytes_ASCII

出沢>     あ のencodeで 28 byte使いますから全体で 82 byte になります。
出沢>     でも この ASCII 文字列と あ のencode の間も、ASCII文字列の間も改行を
出沢>     追加できません。

出沢>     この様な問題は、ASCII文字列が 48 Byteから起きます。

上で述べた通り、改行は追加できます。

挙げていた例を mew-1.94b12で試してみると

X: 53_bytes_ASCII_string_with/without_white_space あ
X: あ 53_bytes_ASCII_string_with/without_white_space
X: 23_bytes_ASCII_string あ 30_bytes_ASCII_string_wi
X: 20_bytes_ASCII あ 10_bytes_ASCII あ 23_bytes_ASCII

というヘッダは

X: 53_bytes_ASCII_string_with/without_white_space
 =?iso-2022-jp?B?GyRCJCIbKEI=?=
X: =?iso-2022-jp?B?GyRCJCIbKEI=?=
 53_bytes_ASCII_string_with/without_white_space
X: 23_bytes_ASCII_string =?iso-2022-jp?B?GyRCJCIbKEI=?=
 30_bytes_ASCII_string_wi
X: 20_bytes_ASCII =?iso-2022-jp?B?GyRCJCIbKEI=?= 10_bytes_ASCII
 =?iso-2022-jp?B?GyRCJCIbKEI=?= 23_bytes_ASCII

とencode & folding されます。おかしいですか？

＃mew-1.93b37での例を出していますが、その辺のバージョンってencode方法が
＃一番変化していた時期だったような。。。

出沢> 4 over する文字列をできるだけ少なくして、と考えると encode後の行末に
出沢>   ダミーのencodeを入れる事できます。このような空のencodeの追加は許されるか。
出沢>   例えば  ......white_space =?ISO-2022-JP?B??=  <-- 改行escape のための空encode
出沢> 	    =?ISO-2022-JP?B?GyRCJCIbKEI=?       <-- あ をencode

これはencoded-textが 1* である(RFC2047)ため許されないでしょう。

[RFC2047 - 2. Syntax of encoded-words]
>   encoded-text = 1*<Any printable ASCII character other than "?"
>                     or SPACE>
>                  ; (but see "Use of encoded-words in message
>                  ; headers", section 5)

出沢> 5 ascii 文字列も encode してしまうことで、76byte に収める方が良いのか。

それしか方法が無ければ、それでよいのではないでしょうか。たとえば可読な
ASCII部分を出来るだけエンコードせずに、というのはRECOMENDEDのレベルで
あって、MUSTではないですよね。

というわけで、出沢さんのルールでは linear-white-spaceの扱い方が間違っ
ているように思うのですが。私が出沢さんのルールを理解し損ねているでしょ
うか。。。問題点をちょっと理解し損ねているかも＞私

P.S.

「MIMEは欠陥規格だ」とよく聞くのですが、RFC-2045～2049において、具体的
な問題例を「私は」知らないのですよね。

その例ってすぐ挙げられます？ ＞ どなたか

実装方法が難しいのは確かなのですが。。。

P.P.S.
アタマが眠くてオオボケしてるかも

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