NARUSE, Yui
narus****@airem*****
2007年 10月 4日 (木) 13:55:25 JST
成瀬です。 Motoyuki Kasahara wrote: > 修正された nkf.c で、さらに色々と試してみました。 > > 細かい話で恐縮ですが、-g 指定時は他のオプションとの兼ね合いはどうなる > のでしょう? たとえば文字コード変換や改行コード変換オプション、MIME > エンコードは効かないようになっています。 > > $ nkf -g -s -Lw test.txt > EUC-JP (LF) <- Shift_JIS (CRLF) にはならない > $ nkf -g -MB test.txt > EUC-JP (LF) <- ASCII にはならない > > これはこれで正しいと思いますが、一方で MIME のデコードは自動で > 効きます。-m0 の指定で無効にもできます。 > > $ cat test2.txt > =?ISO-2022-JP?Q?=1B=24=42=24=22=1B=28=42=0D=0A?= > $ nkf -g test2.txt > ISO-2022-JP (MIXED NL) > $ nkf -g -m0 test2.txt > ASCII (LF) > > 失礼ながら一貫していない気がするのですが、いかがでしょうか。 改行コードの変換は、先日変更したdiffから推測できる通り、改行コード検出の 直後に存在します。つまり、改行コードの変換は検出に影響しません。一方、 MIME decode は改行コード検出より前に存在しますので、影響します。 これをもってそのような仕様と言うことも可能なのでしょうが、どの処理がどの 段階で行われるかを使う側が把握することは難しいと思うのと、処理の順番が変 わる可能性もあるので、guess オプションと他のオプションを併用した場合の動 作については保証しないというのを公式見解とさせてください。 > さらに、入力文字コードに関するオプションを指定すると、変わった挙動 > を示します。 > > $ nkf -g test3.txt > ISO-2022-JP (LF) > $ nkf -g -J test3.txt > BINARY <- なぜか BINARY > $ nkf -g -S test3.txt > Shift_JIS (LF) <- 入力データからの文字コード判別はしない > > -g 指定時は、これらのオプションを無視するか、競合するオプションと > いうことでエラーにするか、いずれかにした方が良いと思います。 このあたりが保障しない典型的な理由ですかね。nkf.c を grep してみると、 s_iconv や e_iconv、w_iconv はあっても j_iconv が存在しません。EUC-JP と ISO-2022-JP はどちらも ISO 2022 ファミリーであるため、入力は同じ e_iconv で受けているのがその理由です。つまり、-J の時点で EUC-JP とみなしている が、後に ISO-2022-JP と判定され、混在しているので BINARY となる、と。 なお、競合するオプションを無効にするというのは確かに一理あるのですが、 nkf の数あるオプションから矛盾する組み合わせを拾い上げるのは手間に対して 見合わないので消極的です。誤解しやすくかつ結果が致命的なものには対策を入 れますが、あまりそういうものもなさそうですし。 -- NARUSE, Yui <narus****@airem*****> DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA
Fork