🚀 go-pugleaf

In article <c1bho6.he2.ln@sou.nerv.org>,
  Kazushi Jam Marukawa <jam@pobox.com> writes:

>    > まぁ, comment はそれで済みますが, phrase のほうを完璧にやるには構文解
>    > 析しなきゃいけないので, どっちにしろ再帰することになるような気がします。
> 
> phraseで問題になるのは、quoted-stringだけだと思うのですよ。
> このquoted-stringはcommentみたいに再帰しないので、フラグだけ
> で済むかななどと思ってます。他にも問題がありましたっけ。

phrase をエンコードする前に, まず phrase を検出しないといけないんで構
文解析が必要です。

たとえば, 
  To: あ <akr@jaist.ac.jp>
  To: akr@jaist.ac.jp, あ <akr@jaist.ac.jp>
  To: akr@jaist.ac.jp, あ :;
とかは"あ"という部分が phrase です。これは構文解析しないとわからないと
思います。

あと, もちろん quoted-string が問題になるのも確かです。
私の書いた non-ascii 拡張 RFC822 ではそのようなものはそもそも文法違反
なので知ったことではないのですが, まぁ, 入れる奴は入れるわけで, そのよ
うなものも許す文法にした方がいいかも知れません。

その場合は, それをどのように表現するかを考えなきゃいけないわけですが...
私は quoted-string の内容(両端の " と中身の quoted-pair の \ を外した
もの)をエンコードするのがいいような気がします。

逆に, encoded-word をデコードして atom には入れられない文字が出てきた
ら quoted-string にしてしまうのもいいかもしれません。

> どんなcharsetでエンコードされてるか分かりませんよね。
> ってことは、どんなcharsetで入力されても、それをデコード
> した中からASCIIの"("を見付けて印を付けないといけない
> わけなので、大変かなと。
> 
> まあ、分かんないcharsetだと無視しちゃうとかすればいいん
> だろうし、ちょっと僕の上の例は屁理屈じみてますね。

まぁ, 内部コードにデコードするんです(よね?)から, 内部コードの上で
ASCII の "(" が判別できれば良いのではないかと。

> おっしゃる通りです。foldingってつくづく面倒ですね。
> ただ、挙げた例ではfoldingについては何も考えていません。
> バッファリングして2 passでfoldingを後からやるとか、、、。^^;

fold の結果, encoded-word の開始カラムが変わりますんで, encoded-word
の分割の場所が変わる可能性があります... いやぁ, まったく厄介な話ですね。

>    > 2. ASCII だけの部分もエンコードするんですか?
> 
> どちらでもいいんじゃないかと思います。
> 普通はしないでしょうね。例では、「入力が～」と書いてますが、
> 多分実装ではatom単位でcharsetの判別とかやるんでしょう。

atom じゃないという話は後で書きますのが, それはともかく。

そのような単位で charset の判別をやると, その途中で fold せざるを得な
くなった時に泣きを見るはめになります。

例えば, "aあ" というのを一つの encoded-word にするなら
=?ISO-2022-JP?Q?a=1B$B$"=1B=28B?= となりますが, 2つの encoded-word に
分けるなら =?US-ASCII?Q?a?= と =?ISO-2022-JP?Q?=1B$B$"=1B=28B?= となり
ます。

# B でなく, Q を使っているのは ISO-2022-JP を生で見て構造を理解できる
# 人のわかりやすさのためです。他意はありません。
## さすがに B にしてしまうと見ただけでは中身がわからない... わかる人が
## いたら尊敬します。

しかし, 最初に charset を決定してしまうと =?ISO-2022-JP?Q?a?= などと
いう encoded-word を生成してしまいます。これはなるべく小さな charset
を使うという制約に反します。

ちなみに, 私の普段使っている Semi-gnus (の使っているライブラリであると
ころの FLIM)もたしかそーゆー癖を持っていて、US-ASCII ですむところを
ISO-8859-4 にしてしまうことがときおりあります。

>    > 3. "\" を見つけるとなぜ "Q" エンコードを終えるのでしょう?
> 
> quoted-pairはそのままquoted-pairにするというポリシーを、
> 僕が持ってるのでああいったコードを考えてました。
> "\("の"\"を見付けたら"Q"エンコードを終え先頭へ、
> そして"\"を出力し続けて"("を出力するというわけです。
> 
> 違うポリシーであれば、quoteを解いてencoded-wordに
> 入れるとかするだろうと。

なるほど。

私としては, 少なくとも encoded-word に隣接する quoted-pair は
encoded-word に入れるほうがいいことが多いのではないか, と思っています。
encoded-word も quoted-pair も直接入れられない文字を入れるためのやり方
ですからどっちを選んでもいいのですが encoded-word をデコードした時に
quoted-pair が出てくるんなら, エンコードの時には逆のことをしたほうがい
いのではないか, というわけです。

# "\~" の隣に Shift_JIS な encoded-word があると困るけど...

>    > 4. "(ab)" というような文字列で, 次のような状況になったらどうするんでしょ
>    > う?
>    >   ISO-8859-1 で a は表現できるが b は表現できない。
>    >   ISO-8859-2 で b は表現できるが a は表現できない。
> 
> エンコードをやめ最初から動作するのがいいかと。
> ルールの中に「違う入力になったら最初から。」と
> 加えといて下さい。

うぅむ。これは簡単過ぎたか。では次のようなケースは?

ISO-8859-7 で a は表現できるが b は表現できない。
ISO-2022-JP-2 では a と b の両方が表現できる。

私としては, 可能な限り長い入力を一つの encoded-word にしてしまうのが無
難かな, と思っています。
(もちろん, charset と encoding によって encoded-word の長さは変わって
くるので, encoded-word の開始カラムにも依存します。)

> あれ、でも、ISO-8859-1とISO-8859-2とか複数のcharset
> によるエンコードって出来たんでしたっけ？

できないという記述を見た覚えはありません。まぁ, 毎回 encoded-word ごと
に宣言できるんですから, できると考えておくのが無難かと。

>    >   d. encoded-word に見える word 中の文字はエンコードしなければならない。
> 
> wordじゃなくてatomのほうが適当じゃないでしょうか。

ここでいう word は RFC822 の非終端記号の word のことではありません。後
ろの注に書いてあるようなものです。もっと他の名前にしたほうが良かったで
すね。

でも, これを atom と呼ぶのも同様にまずいです。phrase 中はともかく,
comment や *text には atom はありませんので。

> 所で、atom単位でエンコードするというのはよく見掛ける
> 実装なんですが、これって規則なんですか？

まぁ, わかち書きをする言語ではそうすると単語単位にエンコードすることに
なって, エンコードした状態でも読みやすいような気もしないでもない, とい
うことはあるでしょうが, 規則というほどのものではないと思います。

うぅむ。なんかとりとめのない記事になってしまったので, 最後に現時点での
私の考えをまとめておきます。

* comment 中の encoded-word は *(ctext / quoted-pair) と対応させる。
* phrase 中の(atom の) encoded-word は atom か quoted-string (の部分)
  に対応させる。
* *text 中の encoded-word は *text に対応させる。
* 知らない charset がついている encoded-word にはデコード時に先頭に
  "\" をつけてその印とする。
* phrase 中でどうしても encoded-word と special が隣接せざるを得ない時
  --- "あ(あ)" とか --- に空白を入れるか入れないかをユーザに選ばせる。
-- 
[田中 哲][たなか あきら][Tanaka Akira]