From m-kasahr ＠ sra.co.jp Mon Oct 1 15:41:28 2007 From: m-kasahr ＠ sra.co.jp (Motoyuki Kasahara) Date: Mon, 01 Oct 2007 15:41:28 +0900 Subject: [Nkf-dev 44] =?iso-2022-jp?b?LWcgGyRCJSolVyU3JWclcyROMn45VCUzITwlSUg9RGobKEI=?= Message-ID: <47009698.9030003@sra.co.jp> 笠原と申します。 nkf -g による文字コード判定で、改行コードの判定結果も出力されますが、 改行コードが CRLF および混在しているときは正しく判定されないようです。 $ nkf -g 改行コードがCRLFのファイル ISO-2022-JP (CR) $ nkf -g 改行コードが混在しているファイル ISO-2022-JP (CR) nkf.c (rev 1.134) へのパッチを作成してみましたので、参考になれば幸い です。 ただし、混在しているときと改行がまったく現れないときで、出力結果が 一緒になってしまっています。(どのように出力すべきか、良いアイデアが なかったので、とりあえずそのままにしてあります。すみません。) -- __________________________________________________________________ 笠原 基之(かさはら もとゆき) Motoyuki Kasahara -------------- next part -------------- 文字コード指定の無い添付文書を保管しました... 名前: nkf.c.diff URL: http://lists.sourceforge.jp/mailman/archives/nkf-dev/attachments/20071001/b200383f/attachment.txt From naruse ＠ airemix.com Tue Oct 2 06:59:24 2007 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Tue, 02 Oct 2007 06:59:24 +0900 Subject: [Nkf-dev 45] Re: =?iso-2022-jp?b?LWcgGyRCJSolVyU3JWclcyROMn45VCUzITwlSUg9GyhC?= =?iso-2022-jp?b?GyRCRGobKEI=?= In-Reply-To: <47009698.9030003@sra.co.jp> References: <47009698.9030003@sra.co.jp> Message-ID: <47016DBC.3050507@airemix.com> 成瀬です。 Motoyuki Kasahara wrote: > nkf -g による文字コード判定で、改行コードの判定結果も出力されますが、 > 改行コードが CRLF および混在しているときは正しく判定されないようです。 確かに CRLF のコードが動いてませんね。 そもそも混在の場合は考えてもいませんでした。 > nkf.c (rev 1.134) へのパッチを作成してみましたので、参考になれば幸い > です。 > > ただし、混在しているときと改行がまったく現れないときで、出力結果が > 一緒になってしまっています。(どのように出力すべきか、良いアイデアが > なかったので、とりあえずそのままにしてあります。すみません。) いじっているうちに、そもそも UTF-16/UTF-32 ではまったく動いてないことに 気づいたので、方針を変えて改行コード変換関数に同居させることにしました。 なにはともあれ、これで動くようになったと思うのですがいかがでしょう。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From m-kasahr ＠ sra.co.jp Tue Oct 2 15:52:42 2007 From: m-kasahr ＠ sra.co.jp (Motoyuki Kasahara) Date: Tue, 02 Oct 2007 15:52:42 +0900 Subject: [Nkf-dev 46] Re: =?iso-2022-jp?b?LWcgGyRCJSolVyU3JWclcyROMn45VCUzITwlSUg9GyhC?= =?iso-2022-jp?b?GyRCRGobKEI=?= In-Reply-To: <47016DBC.3050507@airemix.com> References: <47009698.9030003@sra.co.jp> <47016DBC.3050507@airemix.com> Message-ID: <4701EABA.5050006@sra.co.jp> 笠原です。 > Motoyuki Kasahara wrote: >> nkf -g による文字コード判定で、改行コードの判定結果も出力されますが、 >> 改行コードが CRLF および混在しているときは正しく判定されないようです。 > > 確かに CRLF のコードが動いてませんね。 > そもそも混在の場合は考えてもいませんでした。 : 略 > いじっているうちに、そもそも UTF-16/UTF-32 ではまったく動いてないことに > 気づいたので、方針を変えて改行コード変換関数に同居させることにしました。 > なにはともあれ、これで動くようになったと思うのですがいかがでしょう。 ありがとうございます。 (UTF-16, UTF-32 のことは、私もまったく考えていませんでした。) 修正して頂いた nkf.c (rev 1.139) を試してみました。ファイル単一で 指定したときは、正しく動作しているようですが、複数のファイルを指定 した際の判定で失敗しています。 $ nkf -g *.txt cr.txt: ISO-2022-JP (CR) crlf.txt: ISO-2022-JP (MIXED NL) lf.txt: ISO-2022-JP (MIXED NL) mixed.txt: ISO-2022-JP (MIXED NL) none.txt: ISO-2022-JP (MIXED NL) 前のファイルの判定情報を、引きずってしまっているようです。 ファイルを処理する毎に input_nextline のリセットが必要だと思います。 -- __________________________________________________________________ 笠原 基之(かさはら もとゆき) Motoyuki Kasahara From naruse ＠ airemix.com Tue Oct 2 18:28:57 2007 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Tue, 02 Oct 2007 18:28:57 +0900 Subject: [Nkf-dev 47] Re: =?iso-2022-jp?b?LWcgGyRCJSolVyU3JWclcyROMn45VCUzITwlSUg9GyhC?= =?iso-2022-jp?b?GyRCRGobKEI=?= In-Reply-To: <4701EABA.5050006@sra.co.jp> References: <47009698.9030003@sra.co.jp> <47016DBC.3050507@airemix.com> <4701EABA.5050006@sra.co.jp> Message-ID: <47020F59.2070006@airemix.com> 成瀬です。 Motoyuki Kasahara wrote: > 修正して頂いた nkf.c (rev 1.139) を試してみました。ファイル単一で > 指定したときは、正しく動作しているようですが、複数のファイルを指定 > した際の判定で失敗しています。 > > $ nkf -g *.txt > cr.txt: ISO-2022-JP (CR) > crlf.txt: ISO-2022-JP (MIXED NL) > lf.txt: ISO-2022-JP (MIXED NL) > mixed.txt: ISO-2022-JP (MIXED NL) > none.txt: ISO-2022-JP (MIXED NL) > > 前のファイルの判定情報を、引きずってしまっているようです。 > ファイルを処理する毎に input_nextline のリセットが必要だと思います。 む、モジュール用の部分は初期化追加したんですが複数ファイルの方忘れてます ね。修正しました。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From m-kasahr ＠ sra.co.jp Wed Oct 3 12:05:54 2007 From: m-kasahr ＠ sra.co.jp (Motoyuki Kasahara) Date: Wed, 03 Oct 2007 12:05:54 +0900 Subject: [Nkf-dev 48] Re: =?iso-2022-jp?b?LWcgGyRCJSolVyU3JWclcyROMn45VCUzITwlSUg9GyhC?= =?iso-2022-jp?b?GyRCRGobKEI=?= In-Reply-To: <47020F59.2070006@airemix.com> References: <47009698.9030003@sra.co.jp> <47016DBC.3050507@airemix.com> <4701EABA.5050006@sra.co.jp> <47020F59.2070006@airemix.com> Message-ID: <47030712.5070803@sra.co.jp> 笠原です。 >> 修正して頂いた nkf.c (rev 1.139) を試してみました。ファイル単一で >> 指定したときは、正しく動作しているようですが、複数のファイルを指定 >> した際の判定で失敗しています。 >> >> $ nkf -g *.txt >> cr.txt: ISO-2022-JP (CR) >> crlf.txt: ISO-2022-JP (MIXED NL) >> lf.txt: ISO-2022-JP (MIXED NL) >> mixed.txt: ISO-2022-JP (MIXED NL) >> none.txt: ISO-2022-JP (MIXED NL) : 略 > む、モジュール用の部分は初期化追加したんですが複数ファイルの方忘れてます > ね。修正しました。 修正された 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) 失礼ながら一貫していない気がするのですが、いかがでしょうか。 さらに、入力文字コードに関するオプションを指定すると、変わった挙動 を示します。 $ nkf -g test3.txt ISO-2022-JP (LF) $ nkf -g -J test3.txt BINARY <- なぜか BINARY $ nkf -g -S test3.txt Shift_JIS (LF) <- 入力データからの文字コード判別はしない -g 指定時は、これらのオプションを無視するか、競合するオプションと いうことでエラーにするか、いずれかにした方が良いと思います。 -- __________________________________________________________________ 笠原 基之(かさはら もとゆき) Motoyuki Kasahara From naruse ＠ airemix.com Thu Oct 4 13:55:25 2007 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Thu, 04 Oct 2007 13:55:25 +0900 Subject: [Nkf-dev 49] Re: =?iso-2022-jp?b?LWcgGyRCJSolVyU3JWclcyROMn45VCUzITwlSUg9GyhC?= =?iso-2022-jp?b?GyRCRGobKEI=?= In-Reply-To: <47030712.5070803@sra.co.jp> References: <47009698.9030003@sra.co.jp> <47016DBC.3050507@airemix.com> <4701EABA.5050006@sra.co.jp> <47020F59.2070006@airemix.com> <47030712.5070803@sra.co.jp> Message-ID: <4704723D.909@airemix.com> 成瀬です。 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 DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From yw3t-trns ＠ asahi-net.or.jp Fri Oct 5 06:22:05 2007 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 05 Oct 2007 06:22:05 +0900 Subject: [Nkf-dev 50] Re: =?iso-2022-jp?b?LWcgGyRCJSolVyU3JWclcyROMn45VCUzITwlSUg9GyhC?= =?iso-2022-jp?b?GyRCRGobKEI=?= References: <47009698.9030003@sra.co.jp> <47016DBC.3050507@airemix.com> <4701EABA.5050006@sra.co.jp> <47020F59.2070006@airemix.com> <47030712.5070803@sra.co.jp> <4704723D.909@airemix.com> Message-ID: <4705597D.797421A7@asahi-net.or.jp> 寺西です。 "NARUSE, Yui" wrote: > > > -g 指定時は、これらのオプションを無視するか、競合するオプションと > > いうことでエラーにするか、いずれかにした方が良いと思います。 ... > なお、競合するオプションを無効にするというのは確かに一理あるのですが、 > nkf の数あるオプションから矛盾する組み合わせを拾い上げるのは手間に対して > 見合わないので消極的です。誤解しやすくかつ結果が致命的なものには対策を入 > れますが、あまりそういうものもなさそうですし。 他のオプションと大きく動作や意味が異なる -g オプションだけ、特別扱い するのは妥当ではないかと思います。 kcc の -c オプションでも、-x, -z 以外のオプションは無視されますから、 nkf も -g オプションの場合は、他のオプションは無視するか、エラーを 出すようにする程度で良いと思います。(併用可能なオプションもあるかも しれないが、併用できるようにまでする必要はないでしょう。) この程度なら、 オプションを解析する部分に手を加えるだけなので、さほど手間がかかる ようにも思いませんし。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From naruse ＠ airemix.com Fri Oct 5 20:09:23 2007 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Fri, 05 Oct 2007 20:09:23 +0900 Subject: [Nkf-dev 51] Re: =?iso-2022-jp?b?LWcgGyRCJSolVyU3JWclcyROMn45VCUzITwlSUg9GyhC?= =?iso-2022-jp?b?GyRCRGobKEI=?= In-Reply-To: <4705597D.797421A7@asahi-net.or.jp> References: <47009698.9030003@sra.co.jp> <47016DBC.3050507@airemix.com> <4701EABA.5050006@sra.co.jp> <47020F59.2070006@airemix.com> <47030712.5070803@sra.co.jp> <4704723D.909@airemix.com> <4705597D.797421A7@asahi-net.or.jp> Message-ID: <47061B63.10306@airemix.com> 成瀬です。 Tadamasa Teranishi wrote: > 他のオプションと大きく動作や意味が異なる -g オプションだけ、特別扱い > するのは妥当ではないかと思います。 > > kcc の -c オプションでも、-x, -z 以外のオプションは無視されますから、 > nkf も -g オプションの場合は、他のオプションは無視するか、エラーを > 出すようにする程度で良いと思います。(併用可能なオプションもあるかも > しれないが、併用できるようにまでする必要はないでしょう。) > > この程度なら、 > オプションを解析する部分に手を加えるだけなので、さほど手間がかかる > ようにも思いませんし。 併用できるようにする必要があるオプションが存在することが念頭にあったので すが、併用できるようにする必要があるオプションは常時ONにするようにしてし まいました。 http://sourceforge.jp/forum/forum.php?thread_id=15735&forum_id=1007 ついでに、実験的にある種の機種依存文字が入力にある場合、文字コードの後に + をつけるようにしてみたのですが、こういうのってどうなんでしょう。 % ruby -e'print ["82a082a282a4"].pack("H*")'| ./nkf --guess Shift_JIS % ruby -e'print ["82a082a282a4f89f"].pack("H*")'| ./nkf --guess Shift_JIS+ Shift_JIS+でなくCP932と表示し、また、変換時にはCP932とみなすっていう派手 な変更もありっちゃありなんですが。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From yw3t-trns ＠ asahi-net.or.jp Fri Oct 5 22:30:27 2007 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 05 Oct 2007 22:30:27 +0900 Subject: [Nkf-dev 52] Re: =?iso-2022-jp?b?LWcgGyRCJSolVyU3JWclcyROMn45VCUzITwlSUg9GyhC?= =?iso-2022-jp?b?GyRCRGobKEI=?= References: <47009698.9030003@sra.co.jp> <47016DBC.3050507@airemix.com> <4701EABA.5050006@sra.co.jp> <47020F59.2070006@airemix.com> <47030712.5070803@sra.co.jp> <4704723D.909@airemix.com> <4705597D.797421A7@asahi-net.or.jp> <47061B63.10306@airemix.com> Message-ID: <47063C73.AF9C9DAB@asahi-net.or.jp> 寺西です。 "NARUSE, Yui" wrote: > > ついでに、実験的にある種の機種依存文字が入力にある場合、文字コードの後に > + をつけるようにしてみたのですが、こういうのってどうなんでしょう。 > > % ruby -e'print ["82a082a282a4"].pack("H*")'| ./nkf --guess > Shift_JIS > % ruby -e'print ["82a082a282a4f89f"].pack("H*")'| ./nkf --guess > Shift_JIS+ 返ってきた文字列を完全一致で比較している場合があるので、1文字でも違う なら、CP932 の方が良いように思います。 # Shift_JIS+ って独自の文字列だと、何かとトラブルの元のような。 しかし、そうやって拡張するなら EUC-JP-MS とか、拡張していかないといけ ないような気もするので、Shift_JIS のままでも良い気もします。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From m-kasahr ＠ sra.co.jp Sat Oct 6 01:19:09 2007 From: m-kasahr ＠ sra.co.jp (Motoyuki Kasahara) Date: Sat, 06 Oct 2007 01:19:09 +0900 Subject: [Nkf-dev 53] Re: =?iso-2022-jp?b?LWcgGyRCJSolVyU3JWclcyROMn45VCUzITwlSUg9GyhC?= =?iso-2022-jp?b?GyRCRGobKEI=?= In-Reply-To: <4704723D.909@airemix.com> References: <47009698.9030003@sra.co.jp> <47016DBC.3050507@airemix.com> <4701EABA.5050006@sra.co.jp> <47020F59.2070006@airemix.com> <47030712.5070803@sra.co.jp> <4704723D.909@airemix.com> Message-ID: <470663FD.1040109@sra.co.jp> 笠原です。 > 改行コードの変換は、先日変更したdiffから推測できる通り、改行コード検出の > 直後に存在します。つまり、改行コードの変換は検出に影響しません。一方、 > MIME decode は改行コード検出より前に存在しますので、影響します。 > > これをもってそのような仕様と言うことも可能なのでしょうが、どの処理がどの > 段階で行われるかを使う側が把握することは難しいと思うのと、処理の順番が変 > わる可能性もあるので、guess オプションと他のオプションを併用した場合の動 > 作については保証しないというのを公式見解とさせてください。 (すでに寺西さんとの間で、議論は進んでいますが、) なるほど、分かりました。 他には、特に私のほうで guess オプションについて気付いた点は ないです。修正、どうもありがとうございました。 -- _______________________________________________________________ 笠原 基之 (かさはら もとゆき) From naruse ＠ airemix.com Sat Oct 6 17:31:58 2007 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Sat, 06 Oct 2007 17:31:58 +0900 Subject: [Nkf-dev 54] Re: =?iso-2022-jp?b?LWcgGyRCJSolVyU3JWclcyROMn45VCUzITwlSUg9GyhC?= =?iso-2022-jp?b?GyRCRGobKEI=?= In-Reply-To: <47063C73.AF9C9DAB@asahi-net.or.jp> References: <47009698.9030003@sra.co.jp> <47016DBC.3050507@airemix.com> <4701EABA.5050006@sra.co.jp> <47020F59.2070006@airemix.com> <47030712.5070803@sra.co.jp> <4704723D.909@airemix.com> <4705597D.797421A7@asahi-net.or.jp> <47061B63.10306@airemix.com> <47063C73.AF9C9DAB@asahi-net.or.jp> Message-ID: <470747FE.3040602@airemix.com> 成瀬です。 Tadamasa Teranishi wrote: > 返ってきた文字列を完全一致で比較している場合があるので、1文字でも違う > なら、CP932 の方が良いように思います。 > # Shift_JIS+ って独自の文字列だと、何かとトラブルの元のような。 あー、そういえば改行コード検出追加したせいで、この辺でトラブルでるかもし れませんね。まぁ、文字コード自体に「+」を含むものはないだろうから /[-_ A-Za-z]+/ あたりで・・・って、IANA Character Sets を見るとちらほらありま すね。少なくともそこは直します。 > しかし、そうやって拡張するなら EUC-JP-MS とか、拡張していかないといけ > ないような気もするので、Shift_JIS のままでも良い気もします。 EUC-JP-MS と CP51932 の区別とかも難しいですしねぇ。機種依存文字の含まれ ない Shift_JIS と 含まれている Shift_JIS が区別できるとうれしいかなぁと 思ったのですがそういうニーズは思ったよりないのですかね。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From yw3t-trns ＠ asahi-net.or.jp Mon Oct 8 02:57:12 2007 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Mon, 08 Oct 2007 02:57:12 +0900 Subject: [Nkf-dev 55] Re: =?iso-2022-jp?b?LWcgGyRCJSolVyU3JWclcyROMn45VCUzITwlSUg9GyhC?= =?iso-2022-jp?b?GyRCRGobKEI=?= References: <47009698.9030003@sra.co.jp> <47016DBC.3050507@airemix.com> <4701EABA.5050006@sra.co.jp> <47020F59.2070006@airemix.com> <47030712.5070803@sra.co.jp> <4704723D.909@airemix.com> <4705597D.797421A7@asahi-net.or.jp> <47061B63.10306@airemix.com> <47063C73.AF9C9DAB@asahi-net.or.jp> <470747FE.3040602@airemix.com> Message-ID: <47091DF8.EF13819C@asahi-net.or.jp> 寺西です。 "NARUSE, Yui" wrote: > > > しかし、そうやって拡張するなら EUC-JP-MS とか、拡張していかないといけ > > ないような気もするので、Shift_JIS のままでも良い気もします。 > > EUC-JP-MS と CP51932 の区別とかも難しいですしねぇ。機種依存文字の含まれ > ない Shift_JIS と 含まれている Shift_JIS が区別できるとうれしいかなぁと > 思ったのですがそういうニーズは思ったよりないのですかね。 ニーズがないわけではないと思います。 ただ、EUC なのか JIS なのか Shift_JIS なのかが分かれば十分なことも 多いです。多くの場合、Shift_JIS と CP932 を区別している(できる)人も 少ないですし。 これは面倒かもしれませんが、-Z オプションのように -g オプションの後に パラメータを付けて、切り替えるというのもアリかもしれません。 -g Shift_JIS -g0 -g と同じ -g1 Shift_JIS と CP932 を区別するなど、より厳密に という感じですかね。 UNICODE に関しては厳密に区別できる(はずな)ので、どのオプションでも UTF-8, UTF-16 とか出せば良いのではないかと思います。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From naruse ＠ airemix.com Thu Oct 11 04:42:07 2007 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Thu, 11 Oct 2007 04:42:07 +0900 Subject: [Nkf-dev 56] Re: =?iso-2022-jp?b?LWcgGyRCJSolVyU3JWclcyROMn45VCUzITwlSUg9GyhC?= =?iso-2022-jp?b?GyRCRGobKEI=?= In-Reply-To: <47091DF8.EF13819C@asahi-net.or.jp> References: <47009698.9030003@sra.co.jp> <47016DBC.3050507@airemix.com> <4701EABA.5050006@sra.co.jp> <47020F59.2070006@airemix.com> <47030712.5070803@sra.co.jp> <4704723D.909@airemix.com> <4705597D.797421A7@asahi-net.or.jp> <47061B63.10306@airemix.com> <47063C73.AF9C9DAB@asahi-net.or.jp> <470747FE.3040602@airemix.com> <47091DF8.EF13819C@asahi-net.or.jp> Message-ID: <470D2B0F.9060801@airemix.com> 成瀬です。 Tadamasa Teranishi wrote: > -g Shift_JIS > -g0 -g と同じ > -g1 Shift_JIS と CP932 を区別するなど、より厳密に -g0 からは改行情報を削除した上で以上を採用してみました。 % ruby -e'print"\x8f\xf5\xfe\n"'|./nkf --guess EUC-JP % ruby -e'print"\x8f\xf5\xfe\n"'|./nkf --guess=1 EUCJP-MS (LF) % ruby -e'print"\xAD\xFE\n"'|./nkf --guess=1 CP51932 (LF) % ruby -e'print"\xA8\xFE\n"'|./nkf --guess=1 EUC-JP (LF) CP932, CP51932, EUCJP-MS, CP51220, CP51221 あたりまで判定可能です。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA