2

私は大規模な（約ギガバイトの）フラットファイルデータベースをデコードしています。このデータベースは、文字エンコードを巧みに組み合わせています。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は、エンコーディングの選択について非常に高い信頼性を報告していますが、デコードしません...他に賢明なアプローチはありますか？

4

1 に答える 1

4

あまり強調できない点：非常に短く、プレーンな古いASCII文字の割合が非常に高いテキストから妥当なエンコーディングの推測を期待するべきではありません。

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

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

この段階では、帯域外の支援を求める必要があります。「Kuzeyなど」をグーグルで検索すると、トルコのテレビシリーズ「Kuzeyrüzgari」がドラッグされ、言語がわかります。

つまり、トルコ語に精通している人が入力した場合は、cp1254、iso_8859_3（または_9）、またはmac_turkishにある可能性があります。それらのすべては、終わり近くの[Kaz??m]単語のためにぎこちないものを生み出します。imdbのWebサイトによると、これはキャラクターの名前であり、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 LETTERDOTLESSIを生成します。さらにグーグルすると、Kazımは一般的なトルコ語の名前であることがわかります。

于 2011-01-19T06:13:29.113 に答える