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

1999年 3月 17日 (水) 01:22:11 JST

出沢＠フジフイルム　です

余計なこだわりかも知れないのですが、
    encode されたものを decode したら全く同じに戻る

様にしたいのです。もしそうでなくて構わないのなら、古い rfc のままで
追加された \s+ が decode後もそのまま残ってしまって構わないのですから。

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

ごめんなさい。

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

いやいや、それが発展の元ですから。

gotoh> 出沢>    法律D：ASCII文字列(\sを含む)が続く場合は、改行を追加してはならない(4から)
gotoh> 
gotoh> なぜ？
gotoh> 
gotoh> ASCII文字列が「何に」続く場合のことか不明ですが、「4から」ということか
gotoh> らすると、日本語(encoded-word)に空白またはASCIIが続く場合ということで
gotoh> すよね？

いえ、ここでは ASCII文字だけが続く事を言っています。
  53_bytes_ASCII_string_with/without_white_space あ

の例の  53_bytes_ASCII_string_with/without_white_spac の部分です。
ここには改行を追加できない。なぜなら、その追加された改行は、decode の時に
追加されたものとは判断出来ないから、残ってしまう。

gotoh> 空白が続く場合は １つのLWSP-charは CRLF + LWSP-char に置き換えて保存す
gotoh> ることが出来る(folding)はずですので問題はないですよね。
gotoh> 
gotoh> unfold時のルールは以下のように記述されています

これは 822 ですから、MIME化前の話、というか、人が入力する時の 見たいな
話ですよね。  この形で入力されているのなら、その改行は保存するだけの
話なので、問題はないです。
問題は、同じ行でこれに前後する部分が encodeの必要があり、その場合に 76Byte
overしてしまうとき。その時にどこに(decode時に削除されるべき)改行を追加出来
るのか、という問題です。

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

これらの場合に追加された 改行は、「encode に挟まれた ^\s+$」ではないから
decode時に削除されずに残ってしまいます。

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

＃ そろそろ新しいのに変えよう、、、

gotoh> 出沢>   例えば  ......white_space =?ISO-2022-JP?B??=  <-- 改行escape のための空encode
gotoh> 出沢> 	    =?ISO-2022-JP?B?GyRCJCIbKEI=?       <-- あ をencode
gotoh> 
gotoh> これはencoded-textが 1* である(RFC2047)ため許されないでしょう。

decodeの邪魔にはならないのだがな、、、ぶつぶつ。。
でもこれを許しても、76Byteルールが守れるというわけでもないのですが、
なにしろ空でも18byte くっちまうんだから。

＃ しかし、B にせよ Q にせよ、encoded が 1* てこたあなかろうに、最低 3* だぞ。

gotoh> 出沢> 5 ascii 文字列も encode してしまうことで、76byte に収める方が良いのか。
gotoh> 
gotoh> それしか方法が無ければ、それでよいのではないでしょうか。たとえば可読な
gotoh> ASCII部分を出来るだけエンコードせずに、というのはRECOMENDEDのレベルで
gotoh> あって、MUSTではないですよね。

76byte がMUSTなのかどうかですね。
Received: header なんて、平気で80Byteをoverしたりしてるのだから。
全体を encode してしまうのが 76Byte ルールを含めた楽な解決策で
ある事が理解出来てきた。でも ML での れれれ 対策を考えると、、、、

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

次の節への私の答え/例 でもあるのですが、
	encode して decode したら 同じになる。

ということへのこだわり、が問題意識の違いだと思います。
元通りに復元出来ないなんて、encodeルールじゃあないよ、っていうのが
私の問題意識です。

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

＃ あれ、2045-49 も読んでおく必要があるのかな。47しか見てないぞ。

これへのもうひとつの例/答え は、
  同じルールに従ったencodeなのに、答えが一致しない。

だと思っています。  実装方針で変わってしまう。

＃ とりあえず、「境界条件では 76Byteルールは破る。出来るだけ短くはするが。」
＃ で実装してみました。最大、Prefix SI １文字 SO postfix の 30Byte over
＃  空encode をなくし、出来るだけ短く のためにえらく見通しが悪くなってしまった。
＃ 76もこだわるなら、ASCII部分もencodeすることになるか、、、