🚀 go-pugleaf

In article <9b07o6.bud.ln@sou.nerv.org>,
  Kazushi Jam Marukawa <jam@pobox.com> writes:

>    > From: akr@jaist.ac.jp (あ(い)う)
> 
> "Q"だと"("はエンコードできませんが、"B"ならできるし、
> エンコードしちゃえば何の問題もないのではないでしょうか。

Q だって =28 という手がありますが...

>    > # コメントのネストとはなにを示しているのか? という点は議論を呼ぶような
>    > # 気もしますが, ここではコメントを単なる文字列ではなく木構造をなすもの
>    > # だと思うことにします。そうすると, 木構造を保存する限りは括弧を
>    > # encoded-word に入れてしまうことはできません。
> 
> そういう話はデコードしてからすべきではないかと
> 思いますよ。

RFC822 の文法は, US-ASCII の文字列(またはバイト列)と構文木のあいだの対
応を示しています。そして, RFC2047 はその構文木の変換規則を定義していま
す。

# 実際, (字句解析のみならず)構文解析しないとデコードしていいかどうかわ
# からない場合もあります。phrase 以外で現れる atom をデコードしないよ
# うにするとかね。

そして, 送信側でユーザの作った構文木は, それらの変換を通して US-ASCII
の文字列に変換されて network を通り, 受信側でその逆変換がおこなわれる
ことによって構文木が再構成されてユーザに提示されます。

ここで, コメントに Non-ASCII が使える, というのは, 構文木中の ctext の
ところに ASCII 以外の文字をいれられる, ということですが, 送信側の MUA
がコメントのネストを勝手に展開して "(" と ")" という文字に変換してしま
うと, 当然, 受信側が受け取る構文木は異なるものになります。これは望まし
くありません。そのような実装が存在するかどうかはともかくとして, 少なく
とも規格は許していないと思います。
-- 
[田中 哲][たなか あきら][Tanaka Akira]