明らかにBig5で間違っています

Question

私は大きな（約1ギガバイトの）フラットファイルデータベースをデコードしています。これは、文字エンコードを無制限に混在させています。 Pythonモジュールchardetは、エンコーディングを特定するの、これまでのところ、良い仕事をしているが、つまずきをヒットした場合...

In [428]: badish[-3] 
Out[428]: '\t\t\t"Kuzey r\xfczgari" (2007) {(#1.2)} [Kaz\xc4\xb1m]\n' 

In [429]: chardet.detect(badish[-3]) 
Out[429]: {'confidence': 0.98999999999999999, 'encoding': 'Big5'} 

In [430]: unicode(badish[-3], 'Big5') 
--------------------------------------------------------------------------- 
UnicodeDecodeError      Traceback (most recent call last) 

~/src/imdb/<ipython console> in <module>() 

UnicodeDecodeError: 'big5' codec can't decode bytes in position 11-12: illegal multibyte sequence 

chardetはそれで非常に高い信頼性がエンコードの選択だ報告しますが、それはdoesnの他の賢明なアプローチはありますか？

Answer 1

強く強調することができない点：短くて、その中に普通の古いASCII文字の割合が高いテキストからは、合理的な符号化の推測を期待するべきではありません。

big5について：CJKエンコーディングをチェックするときにチャードセットが非常に広いネットをキャストします。 big5には未使用スロットがたくさんあり、chardetはそれらを除外しません。その文字列はあなたが知っているように、有効なbig5ではありません。実際にはbig5_hkscs（これはbig5の穴を多く使用していました）は有効ですが、意味がありません。

文字列に適合する膨大な数のシングルバイトエンコーディングがあります。

この段階では、アウトオブバンドヘルプを探す必要があります。グーグル "クージー等"は、トルコのテレビシリーズ "クジール・ルズガリ"を引き上げるようになりました。

つまり、トルコ語の人が入力した場合は、cp1254、iso_8859_3（または_9）、またはmac_turkishになる可能性があります。それらのすべては終わりの近くの[Kaz ?? m]単語のために不器用なものを作り出します。 imdbのウェブサイトによると、これはキャラクターの名前であり、cp1254とiso-8859-9（Kazım）を使ってデコードしたのと同じようにぎこちないものです。あなたの提案されたiso-8859-2でデコードすると、KazÄąmは非常に妥当性がないように見えます。

これを一般化できますか？私はそうは思わない:-)

latin1を使ってデコードして（バイトがマングルされないように）、そのレコードに不明なエンコーディングがあるとフラグを立てることを強くお勧めします。また、最小長さカットオフを使用する必要があります。

更新何が価値があるために、the_two_bytes_in_the_character_name.decode（ 'UTF8'）は、トルコとアゼルバイジャンで使用されているU + 0131 LATIN SMALL LETTER DOTLESS Iを生成します。さらにグーグル・グーグルは、Kazımが一般的なトルコ語の十分な名前であることを示している。