🚀 go-pugleaf

In article <96g7o6.kv5.ln@sou.nerv.org>,
  Kazushi Jam Marukawa <jam@pobox.com> writes:

> あるんですが、'comment'中の"("と")"と"は、"Q"エンコードしちゃ
> いけないんだそうです。5.のルール2参照。

うぅむ。encoded-word が character を contain するとはどーゆーことか,
ってことに関する解釈の相違, ってやつですね。

私はこれをエンコードされた US-ASCII の文字列内に "(", ")", "\" が含ま
れないと解釈しました。

# あ, RFC2047(と RFC1522)は文書の整形の失敗なのかその行が切れてます。
# 切れている内容が "\" であることは, RFC1342 まで遡るとわかります。

"(", ")", "\" を書いてはいけないのは, そのへんが encoded-word に含まれ
ていると RFC822 による parse を失敗するからだと理解しています。だから
エンコードされた形で現れるのはまったく問題がないと思います。

# 問題: 上記の RFC2047 の制限がなかったとして, 次の To: の宛先はどこか?
# To: (=?US-ASCII?Q?(?=)akr@jaist.ac.jp(=?US-ASCII?Q?))jam@pobox.com(?=)

>    > RFC822 の文法は, US-ASCII の文字列(またはバイト列)と構文木のあいだの対
>    > 応を示しています。そして, RFC2047 はその構文木の変換規則を定義していま
>    > す。
> 
> ですね。そもそもデコードできない(MIME非対応の)可能性もあるわけで、
> 僕の話はちょっと変ですね。ボケてたようです。単純に"B"ならいい
> という話じゃないですね。

てゆーか, デコードしなくても MTA が扱えないといけないていうのが, この
一見奇妙にも思える階層構造が作られた理由だと思いますが。

ちなみに, MUA が MIME に対応してたってデコードできない可能性もあります。
知らない charset がついていることがありますんで。
この場合, 「謎の文字列 =?...?.?...?=」というような要素が構文木に含まれ
ることになります。

# encoded-word のままの US-ASCII の文字列に「デコード」すればいいんじゃ
# ないの, というのはちょっと甘い考えです。encoded-word の形をした文字
# 列を扱えないという問題を無視しても, 奇妙なことが起こる可能性がありま
# す。
-- 
[田中 哲][たなか あきら][Tanaka Akira]