[xyzzy:08065] Re: KaMail/ スペースを含む宛先

[Yoichi Katogi <ykatogi@xxxxxxxxxxxxxxxxxxx>]

> そのルールは、structured なフィールドにのみ適用される
> という説があったりなかったり。

あ、確かにそうですね。


> エンコードとデコードの実装が違ってるというのがそもそも
> ナニなのですが。

ま、相手の MUA を規定するわけにはいかないので、この「eoncoded-word が
からんだらスペース見えたり見えんかったり」問題は、あまり追いつめてもしゃ
あないわな、とは思います。ただ個人的には、(KaMail において) draft で書
いたつもりになっているものが、保存した時点ですでに微妙に違っている (よ
うに見える) のは少し気持ち悪かったり。せめて KaMail の中にいる間だけで
も、こちらが当初意図したように見えていてほしい、と素朴に思ったりするわ
けで。

しかしまあ、元の RFC 自体、「スペースで単語を区切らない言語」を、少な
くとも日常的には使っていない人たちの頭から出たものですからね。「読めた
らええやんか、あんた」というのは、基本的には正しいし。

ちょっと興味がわいたので、Mew の IM がどうやってるか調べてみました。こ
れ、優れもんですね。ホンマかどうか知らんけど、噂では RFC 2047 を完全に
満たしているとか。Mew 自体は使ったことないけど (笑)。

でもって、こいつはだいたい以下のように処理しているみたいです。「釈迦に
説法」だと感じつつ書きますが...

・linear-white-space でとりあえず分割して
・分割後のそれぞれの文字列をチェックして、必要があればエンコードする
・ただし、隣りあった文字列がともにエンコードされる場合は、それらと間の 
  linear-white-space をひとまとめにしてエンコードする

# 隣りあった文字列がともにエンコードされるけど、コード体系が違う、みた
# いな場合は、スペースをどちらか片方に押しこんでるのかな？ (調べきれず)

わかってみればなんてことはないけど、感心しました。知ってる人はみんな知っ
てるんだろうけど (そらそうや)。このやりかたなら、「eoncoded-word がか
らんだら以下略」問題をクリアできますね。本来エンコードする必要のないも
のまでエンコードする場合がある (ちゅうか日本語なんかとくっついてれば必
ず)、というのはナニだという人も当然いるでしょうけど。

--
加藤木 洋一
ykatogi@xxxxxxxxxxxxxxxxxxx