Re: MIME usascii?B を解読するnkf について
しらいです。
fj.kanji を追加します。
In article <m27k3i8qpq.fsf_-_@qed.decode.waseda.ac.jp>,
TATSUMI Takeo <tttt@cc.tuat.ac.jp> wrote:
>東京農工大学・神戸大学の辰己です。
> =?us-ascii?B?MyBNZWRzIHlvdSBuZWVkIGZvciBncmVhdCBkZWFsIHR4Zml=?=
>
>今日、こんな↑メールが来てました。くやしー。これも nkf で decode でき
>ないものでしょうか?
そもそも「Network Kanji Filter」に漢字以外のものの decode
を期待する方がおかしいんじゃないでしょうか?MIME は MIME で
decode した上で、その後 nkf に渡すのが正解なんじゃないかと。
単一機能の filter を組み合わせて用いるというのが UNIX 流で
もありますからね。MIME だけの decode なんて簡単なので誰か作
ってるんじゃないかしらん。
一方、nkf302 の source も見ましたが、nkf は nkf で MIME の
評価がおかしくて、charset を見ない実装なのに「=?...?」の値を
見ているようです。
例えば「=?EUC-JP?」であっても、MIME decode の結果を EUC-JP
として見なしてはいないんじゃないでしょうか。nkf 独自の自動判
別の結果を charset 指定より優先しているような気がします。
charset を見ないんだったら、どんな charset 文字列にも対応
すればいい訳だし、見るなら見るで自動判別より charset を優先
させるべきだし。
少なくとも、「ISO-8859-1」や「US-ASCII」を漢字用の filter
に廻してはいけませんよね。US-ASCII はまだしも ISO-8859-1 は
「¨」や「´」等を用いた合字を含むので、その辺りの code が含
まれていると nkf 独自の自動判別では漢字と見なされてしまう可
能性があります。
あと、「=?Shift_JIS?Q?」や「=?EUC-JP?Q?」が decode 出来な
い仕様も良く判りません。これってどこかの RFC で禁止されてい
るんでしたっけ?
nkf は知名度ばかり先行したばかりに過度に期待されてしまって
大変でしょうけど、ニーズにのみ応じて後付けで機能を実装するの
ではなく、規格に沿って実装すべきなんじゃないでしょうか。
# source 全部追えてる訳じゃないけど、UTF-8 対応も対象とな
#る Unicode の version が不明なので、新しめの Unicode rule
#に対応出来ているのかどうか疑問です。
# Windows は実質 Unicode 2.x のようですが Mac OS X 辺りだ
#と Unicode 3.x なので色々とややこしい rule が追加されてい
#ますよね。
# Samba-ja で Mac OS X の濁点付仮名文字が扱えずに苦労した
#のも記憶に新しいところ。
--
しらい たかし
Fnews-brouse 1.9(20180406) -- by Mizuno, MWE <mwe@ccsf.jp>
GnuPG Key ID = ECC8A735
GnuPG Key fingerprint = 9BE6 B9E9 55A5 A499 CD51 946E 9BDC 7870 ECC8 A735