EUC-JP或GB18030文本文件

Question

我有一個包含以下內容的文本文件： Ã(195) Ü(220) Â(195) ë(235) Ó(211) Ã(195) »(187) §(167) Ã(195) û(251) Ã(195) Ü(220) Â(194) ë(235) Ã(195) û(251) ³(179) Æ(198) Ã(195) û(251) ³(179) Æ(198) 。 為了簡單起見，我在文本中添加了從http://www.fileformat.info/獲得的Unicode值。 按照Unicode字符集，此文件似乎符合此行A character from JIS-X-0208 (code set 1) is represented by two bytes, both in the range 0xA1 – 0xFE. 在https://en.wikipedia.org/wiki/Extended_Unix_Code#EUC-JP中提到，我的渲染引擎似乎顯示日語字符。 但是，這實際上是一個包含密碼用戶名密碼名稱名稱的中文文本文件，該文件被Notepad ++識別為GB2312編碼文件。 由於文件似乎符合Wiki所說的內容，因此確定文件是否用JIS-X-0208（EUC-JP）編碼時還有更多限制嗎？

但是，我的渲染引擎似乎將此文件識別為EUC-JP和中文，但是由於EUC-JP的順序較高，因此我們認為它是日語的，並且顯示了日語字符。

Answer 1

確定文件是否用JIS-X-0208（EUC-JP）編碼時還有更多限制嗎？

略有一點，因為前導字節0xF5-0xF8和0xFD-0xFE是未分配的，並且在整個塊的末尾還散布了一些其他未分配的字符。

不過，這對您無濟於事，因為字節序列C3DCC2EBD3C3BBA7C3FBC3DCC2EBC3FBB3C6C3FBB3C6在GB（密碼用戶名密碼名稱）和EUC-JP（畜鷹喘薩兆牲畜鷹兆各各兆個部分）中均有效。

這就是字符集嗅探的樂趣。 您必須根據輸入中存在字符集的可能性對它們進行修剪和重新排序。 通常，在Windows世界中，EUC-JP很少見（將使用類似Shift-JIS的代碼頁932），因此類似GB的代碼頁936通常會“獲勝”。

Answer 2

沒有完全可靠的方法來識別未知編碼。

分布模式可能可以幫助您確定要查看的是8位還是16位編碼。 雙字節編碼傾向於每隔一個字節都有一個稍微受限的分配模式。 這就是你現在的位置。

在16位編碼中，您還可以輕松確定正在查看的是大端編碼還是小端編碼。 小端將在偶數字節上具有約束模式，而大端將在奇數字節上具有約束模式。 不幸的是，大多數雙字節編碼似乎是大端編碼的，因此這不會有太大幫助。 如果您正在查看低端字節序，則可能是UTF-16LE。

查看您的示例數據，從第一個字節開始，每隔一個字節似乎等於或接近0xC3（但是似乎缺少一些字節了嗎？）

有一些單獨的字節序列在單獨的編碼中無效，但是總的來說，這不太可能幫助您得出結論。 如果您可以采用這種策略刪除一種或多種候選16位編碼，那么對您有好處； 但這可能不足以解決您的問題。

在此空間中，您剩下的只是統計信息。 如果文本足夠長，則可能會找到重復的樣式，或者使用頻率表作為候選編碼來計算每個分數。 因為日語書寫系統與中文有着共同的傳統，所以您會發現它們的發行方式有相似之處，也有差異。 從類型上說，日語與中文有很大的不同，這意味着日語每隔幾個字符就會有一個粒子 ，而漢語卻根本沒有。 因此，您將尋找“ no”の，“ wa”は，“ ka”か，“ ga”が，“ ni”に等，如果存在，則得出結論，您正在看日語（或者相反，推測是也許您正在尋找中文（如果沒有）；但是，例如，如果您正在查看姓名列表，它可能仍然是日語。

在中文（以及日語中的切向語言）中，您可以查看http://www.zein.se/patrick/3000char.html以獲取頻率信息； 但請記住，日語細語在日語運行文本中比這些字形中的任何一種都更為普遍。

例如， U（ 7681）（即列表中的第一項）在UTF-16be中為0x76 0x84，在Big-5中為0xAA 0xBA，在EUC-JP中為0xC5 0xAA，在GB2312中為0xB5 0xC4，依此類推。

從樣本數據中，該列表上的項目139可能又名U + 540D ，在UTF-16be中為0x54 0x0D，在Big-5中為0xA5 0x57，在EUC-JP中為0xCC 0xBE，在GB2312中為0xC3 0xFB。 （看到了嗎？打！）