しらいです。

　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 の濁点付仮名文字が扱えずに苦労した
＃のも記憶に新しいところ。

-- 
                                               しらい たかし