improving eword-decode.el

[Katsumi Yamaoka]

>>>>> In [emacs-mime-ja : No.01991]
>>>>>	Shun-ichi GOTO <gotoh ＠ taiyo.co.jp> wrote:

> どうも、後藤です。

こんばんは。フォローありがとうございます。

> 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 のデコーダはどうしましょうか?

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

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

はい、同意します。じゃあ

山岡> ただし、ご要望が無ければ CVS commit しないつもりです。

これは、しばらく待ってみて反対が無かったら CVS commit します、に
変更しましょう。;-)

ところで、さっきは書きませんでしたが、ぼくが書き換えたコードでは
error-handler を再実装するのが面倒だったので、ばっさり捨ててしまっ
てあります。

--------
そもそも `encoded-text' というものの実体が、人間が読んで意味のあ
る `text' だとは思えないので、これは元の `text' を encode した結
果として得られたもの、と解釈したところからぼくの考えは始まりまし
た。だから

'encoded-text' MUST NOT be continued from one 'encoded-word' to
another.

という一文は、単一の `encoded-text' をデコードした結果が、元の
`text' を文字単位で切り刻んだ断片になることを求めているのだろう、
と読んだわけです。

加えて、あのロシア語の encoded words はいかにも低品質なエンコー
ダで作られたように見えたので、そんなの放っておけばいいじゃんとい
う気持ちが強かった一方で、とにかく FSF の親分が (彼はキリル文字
を ??? としか見ることができないみたいだけれど) 対処しろって言っ
ているんだから、やっぱりやらなきゃだめなのかなあ、と揺れていたの
でした。