guess_encoding()の挙動が意味不明

質問

以下のプログラムを作成しました。

　　#! /usr/bin/perl -
　　#
　　#文字コードが分からない文字列を、
　　#文字コードを判別した上で、UTF-8に変換して表示
　　#
　　#

　　#テストを行うファイル
　　my $fh="shift-JIS.txt";

　　use strict;
　　use CGI;
　　use CGI::Carp qw(fatalsToBrowser);
　　use Encode;
　　use Encode::Guess;

　　my @all_encodings=Encode->encodings(":all");　・・・Ａ

　　open IN,$fh;
　　our @data=<IN>;
　　close IN;

　　my $q= new CGI;

　　print $q->header(-charset=>'utf8'),
　　 $q->start_html(-title=>'Encode::Guessの使い方',
　　 -lang=>'ja-JP',
　　 -charset=>'utf8'),
　　 $q->p('Encodeモジュールがサポートしている文字コード形式を対象に、<br>
　　　　　　　テストファイルの文字コードを判別した上で、UTF-8に変換してUTF-8のHTMLファイル中で表示するCGIです。');

　　our ($check,$decoder);

　　foreach my $i (@all_encodings) {　・・・Ｂ
　　 if($i ne "UCS-2BE" and $i ne "UTF-16" and $i ne "UTF-16BE" and $i ne "UTF-32") {　・・・Ｃ
　　　 $check=1;

　　　 foreach my $j (@data) {
　　　 $decoder=guess_encoding($j,$i);　・・・Ｄ
　　　 $check=0 unless ref($decoder);
　　　 }

　　　 print "$check &nbsp; $i<br>\n";

　　　 if($check==1) {
　　　 foreach my $j (@data) {
　 　　 $j=$decoder->decode($j);
　　　 $j=encode('utf-8', $j);
　　　 print "$j<br>\n";
　　　 }
　　　 }
　　　}
　　}

　　print $q->end_html;

Ｄ式の$iを"shiftjis"、"euc-jp"でハードコードしてテストをすると、前者ではファイルの中身が書き出され、後者ではタイトル以外表示されませんでした。意図された通りの動作です。

次に、Ａ式でEncodeがサポートしている文字コードを全て@all_encodingsに格納し、その一つ一つをＢ式のforeach文でＤ式に代入しています。

想定した挙動は
$i="shiftjis"の時のみ
　　　　$check=1で文字列を表示し、
　それ以外では
　　　　$check=0で文字列は表示されない
というものです。

ところが結果は、
　　0 7bit-jis
　　0 AdobeStandardEncoding
　　0 AdobeSymbol
　　0 AdobeZdingbat
　　0 ascii
　　0 ascii-ctrl
　　0 big5-eten
　　0 big5-hkscs
　　0 cp1006
　　1 cp1026
　　b￡b2boE[NAE CnebEnK±ib§b\b§b¨aa
　　0 cp1047
　　1 cp1250
　　b￡b2boE[NAE CnebEnK±ib§b\b§b¨aa
　　0 cp1251
　　0 cp1252
　　1 cp1253
　　b￡b2boE[NAE CnebEnK±ib§b\b§b¨aa
　　（続く）

というように$check=1を取る文字コードが幾つかあり、不思議なことには表示された文字列が全て全く同じ文字化けをおこしています。$i="shiftjis"の時でも同じです。ハードコートしていた時には、"shiftjis"の時には正しい表示が行われていました。

ましてや、Ｃ式ではじいた２種の文字コードに至っては、他の文字コードと同様に処理を行うとエラーが出てプログラムが止まるから、はじかざるを得ませんでした。

ちなみにそのエラーメッセージを表示すると、
UTF-16:Unrecognised BOM 62c2 at O:/usr/lib/Encode/Guess.pm line 139.
といった感じです。

どうしてこうなるのでしょう。

というか、どうすればキチンときどうするようになるでしょう。

お手数をおかけします。

回答No.3

Werner

> 毎回同じ文字化けを起こしてしまうのは何故なのでしょう。
「if($check==1)」の手前あたりにでも
| print ref($decoder) ? $decoder->name : $decoder;
| print "\n";
と書いてみてください。
1つめ以外は全てUTF8であると判定されていることが分かると思います。
（これはUTF8フラグを立てる以外何もしないdecoderです。）
また、判定に失敗しているのは、UTF8かそれ以外のどちらかであるという
推測結果になっているからだと言うことも分かります。

guess_encodingの第2引数には、何も指定しなくても
asciiとutf8をデフォルトで指定したのと同じ事になります。
つまり、1つだけをguessの候補にしたつもりが
実はそうなっていなかったという事です。
なので私がNo.1で触れたように、推定候補は全てまとめて渡すべきでしょう。

> 日本でよく用いられている文字コードは
> 　shift-JIS、EUC-JP、JIS
> です。
中国の事情はさすがに知りませんが、
日本においてもShift-JISとそっくりな
CP932（Microsoftコードページ932、Windows-31Jとも呼ばれる）という文字コードが存在します。

CP932はWindowsで日本語を扱うために使われてきた文字コードですが
これが良くShift_JISと呼ばれているため、
一般にShift_JISと呼ばれている文字コードのほとんどは実際にはCP932だったりします。

Shift_JISとCP932ではUnicodeとのマッピングが異なるため、
両者を混同すると「WAVE DASH - FULLWIDTH TILDE問題」として知られる
文字化けの原因になったりするのですが、
その辺の事情を知らないとどっちを使ったらよいかなんてまず分からないですからね。
なので、日本語の事情でも結構面倒なところはあります。

> なんでHPともCGIとも関係の無い文字コードがCGIに送り込まれてくるのか
私は知らなかったのですが、検索したらこんなのが見つかりました。
（個人的には無視しても良い気もします。
広範なコードポイントを含むUTF8が別の文字コードにされるようなことがもしあれば
情報が欠落してしまうのは防ぎようがないですし。）

予期しない文字コードでPOSTされるケース
http://www.shtml.jp/mojibake/mac_post.html

文字コード判定の話に戻りますが、
判定が確実に出来ないのは元の文字列が何か分からないことが大きいので、
隠しテキストボックスにでも適当な(既知となる)文字列を入れておいて
一緒にPOSTされるようにしておけば、
判定精度を高めることは出来ると思います。
（既知文字列を候補文字コードでencodeした結果とPOSTデータを比較してチェックする。）

補足

>1つめ以外は全てUTF8であると判定されていることが分かると思います。
ものの見事に最初にヒットした文字コード以外皆UTF-8になっていますね。

でもまだよく分からないんです。

>guess_encodingの第2引数には、何も指定しなくても
>asciiとutf8をデフォルトで指定したのと同じ事になります。
>つまり、1つだけをguessの候補にしたつもりが
>実はそうなっていなかったという事です。

元のプログラム中のＤ式
　　$decoder=guess_encoding($j,$i);
は字面的には$iだけを文字コードの候補としていますが、この他にasciiとutf8がデフォルトで候補になっている。

これが本当なら、foreach文で全ての文字コードを検証したのですから、@dataはutf8に書き換えられているのだし、全ての文字コードでutf8がヒットしてしまい、$check=0となることは最初のヒット以降ないはずです。

でも実際には、最初のヒット以降も$check=0となる文字コードは出現していますから、guess_encoding()の第２引数を指定した場合、デフォルトのascii、utf8は候補から外れているのではないかと思えます。

その一方でascii、utf8が候補から外れているなら$decoderをprintした時にutf8が書かれるというのはおかしいです。

なんか釈然としません。

>隠しテキストボックスにでも適当な(既知となる)文字列を入れておいて
>一緒にPOSTされるようにしておけば、
>判定精度を高めることは出来ると思います。

良いアイデアですね。ありがとうございます。