improving eword-decode.el

[Shun-ichi GOTO]

どうも、後藤です。

>>>>> On Mon, 17 Oct 2005 15:49:08 +0900,
>>>>> 山岡 == Katsumi Yamaoka wrote,

山岡> これは、テキストを utf-8 でエンコードしたデータを、文字の境界で
山岡> はない場所で分割し、それぞれを B エンコードしたものです。Gnus の
山岡> rfc2047.el だけでなく、FLIM の eword-decode.el も、このようなも
山岡> のを扱うことができません。RFC2047 には次のような記述があります。
...snip...
山岡> ぼくは最初、上記のようなものはこの「MUST NOT」に該当するのではな
山岡> いかと思ったのですが、

character boundary を強制するのはその部分の文章ではなく、その2つ下の

   Each 'encoded-word' MUST represent an integral number of characters.
   A multi-octet character may not be split across adjacent 'encoded-
   word's.

の部分ではないでしょうか？

# 後半が may not なのは、そういう事も想定してdecode は出来るべき、という
# 意味なのだろうなと思ってますが、そこは自信なし。


山岡> FLIM のデコーダはどうしましょうか?  分割された encoded words の
山岡> 境界がテキストの文字単位になっていないものを他には見た記憶が無い
山岡> ので、現在のままでもたぶん問題は無いと思うのですが、いちおう書い
山岡> てみました。ただし、ご要望が無ければ CVS commit しないつもりです。

バイト列の途中というのはあったかどうかはもう覚えてないのですが、
以前はNetscape Communicatorとかが
"<ESC>$Bxxxx"
"xxxx<ESC>(B"
みたいな分割をしてた事がありました。
今でも怪しいのは時々見かけます。

decode の際にそういうのに対応する柔軟性はあった方が良いかと思います。
というか、そうでないとユーザは結構困ると思うので。

--- Regards,
 Shun-ichi Goto  <gotoh ＠ taiyo.co.jp>
   R&D Group, TAIYO Corp., Tokyo, JAPAN