河野真治 @ 琉球大学情報工学です。

In article <dn3oc8$366$1@caraway.media.kyoto-u.ac.jp>, Masanori HATA <hata@iname.com> writes
> この辺の詳細をご教示願えませんでしょうか？　扱いがややこしいのはわかるの
> ですが、RFC 2047 を見る限り欠陥という風に思えるところには気がつかなかっ
> たので……。

=?...?= の間には任意の空白改行を入れて良いですよね。一方で、
空白はbase64 encodeしないっていうルールがあるので、元からあ
る空白は、=?...?= の外にでます。さらに、長くなりすぎたbase64
は適当に分割して良いってことになってます。この時に=?...?= を
続けてはだめで、空白または改行をいれなくてはなりません。

ってことは、元からある空白と、長くなり過ぎて分割された空白と
は区別がつきません。この空白を無くすことは元々の空白を消す可
能性があるので、それは許されません。消さないと余計な空白が入
る可能性があります。

HTMLでも類似の問題があって改行されたHTML textは、表示される
時に改行が変更されますが、その時に強制的に一つ空白がはいりま
す。入れないと英語が読めなくなり、入れると日本語が不自然にな
ります。

単語を空白で区切る言語とかはそれで問題ないんですが、日本語み
たいに長い空白のない文が続く言語で分割が起きると、不自然に空
白が挿入されてしまいます。空白が増えると分割される可能性が増
えるので、さらに空白が増えるという現象が起きます。

HTMLは改行自体を削ってしまえば良いんですが、MIME subject で
はそれもできない。空白改行を含めてencodeして、=?...?= 間の空
白改行は無視するとか、?= の他に「続く空白改行を無視する終了
マーク」を用意するとかすれば解決するんですけどね。

---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科