chardet在Big5上顯然是錯誤的

我正在解碼一個大的（大約一個千兆字節）平面文件數據庫，它將字符編碼混合在一起。在Python模塊chardet是做得很好，到目前爲止，標識編碼，但如果打了一個絆腳石......chardet在Big5上顯然是錯誤的

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的報告非常高的信心，這是編碼的選擇，但它不」 t解碼...還有其他明智的方法嗎？

來源

2011-01-19 SingleNegationElimination

有點黑客攻擊，特別是在引用部分嘗試檢測，返回一個編碼（它恰好是ISO-8859-2），具有非常低的置信度，實際上可以解碼整行。我在尋找一個泛化，但我可以適用於整個數據庫。 – SingleNegationElimination 2011-01-19 04:29:22

一個不能過於強調的觀點：你不應該期望從一段很短的文本中得到任何合理的編碼猜測，並且在它中有很高比例的普通舊ASCII字符。

關於big5：檢查CJK編碼時，chardet施放了非常寬的網絡。 big5中有很多未使用的插槽，chardet不排除它們。正如你發現的那樣，該字符串不是有效的big5。它實際上是有效的（但毫無意義）big5_hkscs（它在big5中使用了很多漏洞）。

有大量適合字符串的單字節編碼。

在這個階段，有必要尋求帶外幫助。谷歌搜索「Kuzey等」拖動土耳其電視連續劇「Kuzeyrüzgari」，所以我們現在有語言。

這意味着如果它是由土耳其人熟悉的人輸入的，它可能在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拉丁小寫字母無點我這是在土耳其和阿塞拜疆使用。進一步的谷歌搜索表明，Kazım是一個足夠普通的土耳其名稱。

來源

2011-01-19 06:13:29

編碼以比線更快的速率變化非常令人沮喪。這些數據實際上來自IMDB ... – SingleNegationElimination 2011-01-19 14:28:53

chardet在Big5上顯然是錯誤的

回答

相關問題