[Mew-dist 08112] B-encoded header routine
(Dezawa Shin-ichiro)
dezawa at example.com
1999年 3月 16日 (火) 22:09:37 JST
出沢 です
この ML に居る方の何人かはご存知のことなのですが、ruby という言語での、
B-encode/decode ルーチンを造ろうとしています。メールやnewsを扱う諸々の
モジュールでの B-encoded header の処理に使おうか、と。
どうせ作るなら、全体をまとめて encode などというのは止めて、RFCに沿った
ものにしたいという、暗黙の了解事項があって(あるんだろうな、、)取り組んで
みたら以外と手ごわいという事態になっています。
一応らしきものはできたのですが、問題含みがあり、私にとっての MIME の
寄り所であるこの ML での御意見を伺いたいと思った次第です。
1 RFC とは rfc2047 のつもりです。もっと新しいものは出ていますか?
2 これによると以下のようになる。 これは正しいですか。
憲法1:encode を含む行が 76Byteを越えないこと。
憲法2:encode の前後には \s+ が有ること。
憲法3:encode と encode の間が \s+ だけの場合は復号時にその \s+ は削除される
憲法4:それ以外の、encode 前後の \s+ は復号後も保存される。
これから以下が要請される。
法律A:76Byteを越える場合は、encodeされるべき文字列を分け2行に分ける。(1,3から)
法律B:ASCIIと日本語文字の間に \s が無い場合は、これらをまとめて encodeする
(2,4から)
法律C:日本語文字列の間にある \s+ は、その前後の日本語文字列全体をまとめて
encodeする。 (2,3,4から)
法律D:ASCII文字列(\sを含む)が続く場合は、改行を追加してはならない(4から)
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から起きます。
4 over する文字列をできるだけ少なくして、と考えると encode後の行末に
ダミーのencodeを入れる事できます。このような空のencodeの追加は許されるか。
例えば ......white_space =?ISO-2022-JP?B??= <-- 改行escape のための空encode
=?ISO-2022-JP?B?GyRCJCIbKEI=? <-- あ をencode
5 ascii 文字列も encode してしまうことで、76byte に収める方が良いのか。
---------------------------
で、わが mew を参考にしようと思ったらば、、、、
1Mew version 1.93b37 では混じりけ無しの日本語だけの時は、76Byteを越えても
分けていなかった。
2 あああlいいい を mew したら
=?iso-2022-jp?B?GyRCJCIkIiQiGyhC?=l=?iso-2022-jp?B?GyRCJCQkJCQkGyhC?=
と encode の前後に \s がないものができていた。
3 上の ダミー encode を入れた場合、mew のdecoder はdecodeせず、
=?ISO-2022-JP?B??= を残したままであった。
----------------------------
さて、ここで迷いました。MIMEの RFC って欠陥含みなのだから、憲法、法律 を
守るなどは諦めて、76BYTE over も気にしないで良いものでしょうか。
Mew-dist メーリングリストの案内