improving eword-decode.el
守岡知彦 / MORIOKA Tomohiko
tomo @ m17n.org
2005年 10月 18日 (火) 15:05:51 JST
幽霊メインテナー(^_^;;の守岡です。
>>>>> In [emacs-mime-ja : No.01990]
>>>>> Katsumi Yamaoka <yamaoka @ jpl.org> wrote:
> FLIM のデコーダはどうしましょうか? 分割された encoded words の
> 境界がテキストの文字単位になっていないものを他には見た記憶が無い
> ので、現在のままでもたぶん問題は無いと思うのですが、いちおう書い
> てみました。ただし、ご要望が無ければ CVS commit しないつもりです。
ちょっと今とっても疲れてて、判断できません。
また、できれば、小林さんと akr さんの見解を聞きたいです。
;; 私の個人的偏見を述べれば、この手の件での半田さんや RMS 先生の御見解
;; はあんまり信用できないです。(^_^;
そういう訳で、私からの提案ですが、commit するにせよしないにせよ、まず、
commit 前の状態で一旦 FLIM を release してはどうかと思います。そうすれ
ば、tag も付きますし、branch もしやすいでしょう。
もし、3日以内に反対がなければ、そこから1週間以内に FLIM 1.14.8 を
release したいと思います。また、その release まで commit は凍結という
ことで行きたいと思います。
> 先週 emacs-pretest-bug メーリングリストに、以下のような subject
> が Gnus で正しくデコードされないという報告があり、半田さんが巧妙
> なやり方で解決して下さいました。
>
> Subject: =?UTF-8?B?W2lwdC5ydSAjMTYzXSDQkNCy0YLQvtCe0YLQstC10YI6INCc0KHQmjog0KHQ?= =?UTF-8?B?nyDRgtC10YHRgg==?=
>
> これは、テキストを utf-8 でエンコードしたデータを、文字の境界で
> はない場所で分割し、それぞれを B エンコードしたものです。Gnus の
> rfc2047.el だけでなく、FLIM の eword-decode.el も、このようなも
> のを扱うことができません。RFC2047 には次のような記述があります。
>
> 5. Use of encoded-words in message headers
>
> [...]
>
> The 'encoded-text' in an 'encoded-word' must be self-contained;
> 'encoded-text' MUST NOT be continued from one 'encoded-word' to
> another. This implies that the 'encoded-text' portion of a "B"
> 'encoded-word' will be a multiple of 4 characters long; for a "Q"
> 'encoded-word', any "=" character that appears in the 'encoded-text'
> portion will be followed by two hexadecimal characters.
>
> ぼくは最初、上記のようなものはこの「MUST NOT」に該当するのではな
> いかと思ったのですが、半田さんからは以下の見解をいただきました。
>
> This example doesn't violate the above restriction. Each
> 'encoded-word' is surely "multiple of 4 characters long".
>
> Please note that the above restriction is for
> 'encoded-text', not for the underlining coded character set.
> So, I think the above document doesn't prohibit diviging
> UTF-8 byte sequence at non-character boundary.
私としては、encoded-text の適格性ではなく、各 encoded-word で charset
が指定されていることを根拠に、encoded-text が指し示すものが任意のバイ
ト列ではなく、符号化文字データ要素といいたいです。
Some character sets use code-switching techniques to switch between
"ASCII mode" and other modes. If unencoded text in an 'encoded-word'
contains a sequence which causes the charset interpreter to switch
out of ASCII mode, it MUST contain additional control codes such that
ASCII mode is again selected at the end of the 'encoded-word'. (This
rule applies separately to each 'encoded-word', including adjacent
'encoded-word's within a single header field.)
は、UTF-8 の場合だと、制御文字で切替える訳ではないから微妙ですが、初期
状態(STD 11 の世界)は US-ASCII 文字列で、encoded-word 内は
encoded-word の charset で解釈され、encoded-word が終ると US-ASCII
文字列の世界に戻るという前提から導かれる規定だと思います。
文字の境界でぶった切るということができると思う人は、charset が文字列と
(符号化文字データ要素である)バイト列の変換であることを理解してないの
かなと思います。
> 加えて、半田さんのコードの効率が良いこと、Gnus には何がなんでも
> 対応してしまう傾向があること、それに RMS からの命があることをもっ
> て、ぼくは同意したのでした。:)
;; 機会があれば、是非一度、RMS 先生の命に従って、夕方、17:30 で玄関が
;; 施錠されるオフィースビルのドアを、椅子を置くことでブロックすること
;; に同意してみてください。:-) セキュリティーがあって、警備員が来るシ
;; チュエーションだとなお良し。(^_^;;;
> FLIM のデコーダはどうしましょうか? 分割された encoded words の
> 境界がテキストの文字単位になっていないものを他には見た記憶が無い
> ので、現在のままでもたぶん問題は無いと思うのですが、いちおう書い
> てみました。ただし、ご要望が無ければ CVS commit しないつもりです。
一般論からいえば、encode は厳格に decode は寛容にというのが良いといえ
ますが、encoded-word 単位に文字列と解釈することは、初期状態を常に
US-ASCII に reset するということで、変な encoded-word から端末を守ると
いう効果があると思います。そういう訳で、文字がぶった切られた
encoded-word 列のサポートが良いことなのかちょっと判んないです。実際の
用例や頻度にも関係しますし。
迷うなら、オプションで選択できるようにするのが良いのかも知れませんが。
--
守岡 知彦 (MORIOKA Tomohiko) <tomo @ kanji.zinbun.kyoto-u.ac.jp>
More information about the Emacs-mime-ja
mailing list