畑です。

Hideki Kato wrote:
>>RFC 2047 の「6.2. Display of 'encoded-word's」によると
>>
>>>When displaying a particular header field that contains multiple
>>>'encoded-word's, any 'linear-white-space' that separates a pair of
>>>adjacent 'encoded-word's is ignored. (This is to allow the use of
>>>multiple 'encoded-word's to represent long strings of unencoded text,
>>>without having to separate 'encoded-word's where spaces occur in the
>>>unencoded text.)
>>
>>となっていて、「encoded-word と encoded-word の間の空白文字は表示時に無
>>視される」と書いてあるので、復号時の挙動に関してはは１．の方針が（RFC
>>的）標準だと考えていました。
> 
> 本来はそうするのが正しいのかも知れませんが，欧米圏では，encode はそれが
> 必要な単語のみに対して行い，単語間の空白は encode せずそのまま残す，とい
> う実装が広く採用されていた様に記憶しています．
> ＃元々分かち書きされている言語ではそれが自然なんでしょう．．．
（中略）
> ＃規則に関係した話と既存のメイラー絡みの問題がごっちゃになっていますが，
> ＃ご容赦下さい．

なるほど、加藤さんのご指摘で畑のぼんやりした頭が多少クリアになりました。
僕の発想が、RFC さえ規範にしていれば、あとはどうでもいいや──的な、態度で
あったのが問題だったみたいです。メイラーの実装実態のことについては相当無
頓着でした。

少なくとも、日本語では、encode に関しては「文字列中の範囲」として考える
方がいいと思いますが（ISO-2022-JP の発想がこれですよね）、欧語の場合は、
個別の単語を encode するか否かという発想になるのでしょうね。RFC 2047 中
で ABNF で
phrase = 1*( encoded-word / word )
と定義されているわけですね。

# 結局、UTF-8 のメールを送信テストしてみたところ、（相当ユーザ人口があ
# ると思われる）Yahoo! Japan の Web メーラでは、UTF-8 に未対応で文字化
# け（MIME はちゃんとデコードするのにね）してガックリ。要望は出してお
# いたけど、いつになったら対応してもらえるのやら。
# あと、携帯メールなんかも未だ UTF-8 は駄目かもれませんね。

-- 
Masanori HATA