🚀 go-pugleaf

最初だけ話を戻すと、ルール(2)の"("に関する言及について。

   In <rsq4swo1su0.fsf@is27e1s03.jaist.ac.jp>, Tanaka Akira wrote:
   > In article <96g7o6.kv5.ln@sou.nerv.org>,
   >   Kazushi Jam Marukawa <jam@pobox.com> writes:
   >> あるんですが、'comment'中の"("と")"と"は、"Q"エンコードしちゃ
   >> いけないんだそうです。5.のルール2参照。

   > ってことに関する解釈の相違, ってやつですね。
   > 私はこれをエンコードされた US-ASCII の文字列内に "(", ")", "\" が含ま
   > れないと解釈しました。

もう一遍眺めた所、田中さんの解釈以外不可能ですね。ありー？
なんか、解釈の相違っていうか、僕の誤解です。"Q"-encoded
'encode-word'って具合に、明確に、エンコード後の文字の話だと
書いてあるのに、なんか勘違いしてました。失礼しました。


では、話を続けます。

   Tanaka Akira <akr@jaist.ac.jp> wrote:
   > う。うまく伝わらなかったような気がする。

   > 私は構造を持ったデータ(構文木)を RFC822 の文法に従った US-ASCII の文字
   > 列(メッセージのネットワーク表現)に変換することを考えています。

了解してると思ってます。

田中さんは、既に構造があるから、それ以外の部分の"("をどう
エンコードするかってな話をしたいというスタンスなんだと、
そう理解してます。「後で判断する」ってな具合に書いたのは、
そういう構造については構造エディタとか、なにかに他に任せ
てると、そういった意味合いでした。

で、構造以外の部分の"("をどうエンコードするかについては、
上述の通り僕の勘違いでした。同意します。

で、一方僕は、構造自体をテキストに埋め込むにはどういうのが
楽かという話をしたがってると、そんな感じです。以下、そんな
話を続けてみます。

   >> ちょっと分かり難いので、例でも。例えば、(ab\(cd)となって
   >> 欲しいcommentを作りたいとします。どうやってデータを
   >> エンコーダに渡し、どんな物が出てくると便利でしょう。

   > 1. 構文エディタを使う。
   > 2. Emacs で (ab(cd) と入力して真中の "(" には適当に quoted-pair で
   >   encode されるべきであるというプロパティを張り付けておく。
   > 3. "(ab" と "cd)" は ASCII で記述し "(" は JIS X 0201 で記述する(笑)

最初に注意を。以下では、実際の文字列を"で囲って書きます。
"\("は"\"と"("というわけです。一方"で囲まず(や\(と書いた
場合は、構造に関係ある"("と関係ない"("を意味します。実際
にどういう文字列になるかは、実装次第だというわけです。

田中さんの方法だと、(ab\(cd)の構造を作った上でエンコード
する必要がありますよね。"("と"ab(cd"と")"に分け、内部の
"ab(cd"をエンコードするということを再帰で繰り返すコード
になると思います。

一方で、この真中の"("を、何時も"\("というquoted-pairで
保持するようユーザに強制しちゃえばどうでしょう。要は
印をつけているわけですが。

(ab\(cd)を"(ab\(cd)"として保持し、エンコード時には、
単にASCIIの"("と")"と"\"に触らないようコードを書く
というわけです。楽チンじゃないかと。

これで、あとencode方法が透過的(とにかくユーザが指定した
charset名を付けて"b"エンコードして好きな所で改行できる)
なら、エンコーダ実装はかなり楽だろうと思うのですが、、、
いかんせん改行の所の制限が大変過ぎますね。


逆にデコードの時も、(ab\(cd)を(=?US-ASCII?Q?ab=28cd?=)
なんてエンコードしてあったら、デコードした"ab(cd"から、
"("を見付け出して印を付けとかないといけませんよね。
それってかなり大変じゃないかと。

でも、規約上は、デコードした文字列にASCIIの"("が入って
る可能性があるわけなので、印付け無しにデコードして
エンコードするプログラムは作れないような気がする。
まあ、デコードしてエンコードするためには、全部の
charsetを知らないといけないみたいなので、そもそも
不可能という話もあると思うけど。


   >> ただ、Non-ASCIIの文字を入れれるんだから、ASCIIの"("も
   >> 入れれるっていう論理には無理があると思います。

   > なるほど。では「encoded-word には指定した charset に含まれる文字はすべ
   > て入れられる」とでもいえばいいでしょうか?

   > # たとえば, ISO-2022-JP の encoded-word を考えると, JIS X 0201 の "("
   > # や JIS X 0208 1983 の "（" は encoded-word にいれてもいいでしょうか?

指定したcharsetが"("という文字をASCIIとして扱ってるかどうか
次第じゃないでしょうか。'comment'で特別の意味を持つ文字"("、
")"、"\"ってのは、すべてASCIIです。ですから、"("と等しいか
じゃなくて、ASCIIの"("かどうかで判断されるべきだろうと。

例えば、以下のようなエンコーダを念頭に置いています。

 - 入力がASCIIの"("か")"か"\"か？
    - そうならそのまま出力。繰り返し。
 - 入力がASCIIかISO-*か？
    - ASCIIかISO-*なら"Q"エンコードする。
       - "("か")"か"\"という文字を見付けたら"Q"エンコードを
         終え、最初から。
 - 入力がそれ以外か？
    - それ以外なら"B"エンコードする。違う入力になったら最初から。

で、構造に関係ないASCIIの"("は、必ず"\("として保持すると
決めちゃえば、上述のように色々楽チンだなと。でも、結局は
各charsetにおける一文字単位での切り分けとか出てくるんで、
透過的にはならないし、簡単にもなりそうになくて、あんまり
意味がないような気もしてきましたが。

-- かずし