🚀 go-pugleaf

In article <855.891655161@rananim.ie.u-ryukyu.ac.jp>,
  kono@ie.u-ryukyu.ac.jp (Shinji Kono) writes:

> >RFC1522(および RFC2047)では, encoded-word 間の空白を消すように変わって
> >います。
> 
> じゃあ、必ず行末まで先読みしないとdecodeできないではないです
> か。困ったなぁ... できないことはないけど、聞かなかったことに
> しょうっと。

linear-white-space の定義を知れば, さらに嫌になるかもしれない...

> そうね。ちなみにlinear-white-spaceってのはなんなのでしょう。

RFC822 では次のように定義されています。

     linear-white-space =  1*([CRLF] LWSP-char)  ; semantics = SPACE
                                                 ; CRLF => folding

     LWSP-char   =  SPACE / HTAB                 ; semantics = SPACE

つまり, 改行, スペース, タブの並び, ただし, 改行の後には必ずスペースも
しくはタブがあること, というものです。

ヘッダ中での(継続行も考慮した)空白の並びと考えれば間違いないです。

というわけで, 行末まで先読みしても足りないんですな, これが。改行, スペー
ス, タブ以外のものが出てくるまで読まないといけない。で, 見つけたものが
= だったらそれが encoded-word の始まりであることを確認して, やっと間の
空白が無視しても良いことがわかるわけです。

(ちなみに, UTF-8 などのデコードできない encoded-word が現れた場合には,
空白を無視しないほうが無難です。完璧とはいかないけれど。)

まぁ, 基本的に MIME ってのは RFC822 の BNF に従ってメッセージを parse
するツールのための規格だと思うので, nkf みたいに入力をフラットなテキス
トと思うツールと相性が悪いのはしょうがないと思いますけどね。

とはいえ, ちょっとした変更でずいぶんと扱いやすくなったのではないか, と
思うところもありますけれど。

> ちゃんと実装しながら作れば、こんな規格にはならなかったはず...

encoded-word を空白で区切らなきゃならない, という点に関しては全くその
通りだと思います。

(ついでにいえば, 76バイト制限も。)

逆にいえば, 実装しなきゃいけなくなった人が「えぇい, 面倒だ。全部エンコー
ドしちまえ。」と考えやすい規格なのかも知れません。
(その結果, Re: も含めてエンコードする, と。)
-- 
[田中 哲][たなか あきら][Tanaka Akira]