河野真治 @ 琉球大学情報工学です。

In article <bls0pf$8bn$1@nsvn01.zaq.ne.jp>, shirai@unixusers.net (Takashi SHIRAI) writes
> 　そもそも「Network Kanji Filter」に漢字以外のものの decode
> を期待する方がおかしいんじゃないでしょうか？MIME は MIME で
> decode した上で、その後 nkf に渡すのが正解なんじゃないかと。

ま、便利さ優先なので。

> 　一方、nkf302 の source も見ましたが、nkf は nkf で MIME の
> 評価がおかしくて、charset を見ない実装なのに「=?...?」の値を
> 見ているようです。

見ないのは「間違っていることが多い」からです。

> 　charset を見ないんだったら、どんな charset 文字列にも対応
> すればいい訳だし、見るなら見るで自動判別より charset を優先
> させるべきだし。

そうかもね。そういうモードがあってもいいかな。

> 　あと、「=?Shift_JIS?Q?」や「=?EUC-JP?Q?」が decode 出来な
> い仕様も良く判りません。これってどこかの RFC で禁止されてい
> るんでしたっけ？

確かbase64が推奨されているはずです。なんか当時は、変なMIMEは
はじくというような方針だったみたい。その名残でしょう。

> 　nkf は知名度ばかり先行したばかりに過度に期待されてしまって
> 大変でしょうけど、ニーズにのみ応じて後付けで機能を実装するの
> ではなく、規格に沿って実装すべきなんじゃないでしょうか。

僕はあんまりそう考えてはいなかったみたいですね。規格にそった
ものが欲しいなら iconv とかがあるし。

> ＃　source 全部追えてる訳じゃないけど、UTF-8 対応も対象とな
> ＃る Unicode の version が不明なので、新しめの Unicode rule
> ＃に対応出来ているのかどうか疑問です。
> ＃　Windows は実質 Unicode 2.x のようですが Mac OS X 辺りだ
> ＃と Unicode 3.x なので色々とややこしい rule が追加されてい
> ＃ますよね。
> ＃　Samba-ja で Mac OS X の濁点付仮名文字が扱えずに苦労した
> ＃のも記憶に新しいところ。

けっこう問題ありありですね。(おぉ、他人事だ ...)

---
Shinji KONO @ Information Engineering, University of the Ryukyus, 
河野真治 @ 琉球大学工学部情報工学科,