Текстовый файл EUC-JP или GB18030
У меня есть текстовый файл со следующим содержанием:Ã(195) Ü(220) Â(195) ë(235) Ó(211) Ã(195) »(187) §(167) Ã(195) û(251) Ã(195) Ü(220) Â(194) ë(235) Ã(195) û(251) ³(179) Æ(198) Ã(195) û(251) ³(179) Æ(198), Для простоты наряду с текстом я добавил значения Unicode, которые я получил с http://www.fileformat.info/. Исходя из набора символов 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 и мой механизм рендеринга, кажется, отображает японские символы. Тем не менее, это на самом деле текстовый файл на китайском языке, содержащий 密码用户名密码名称名称 который распознается как зашифрованный GB2312 файлом Notepad++. Существуют ли еще какие-то ограничения для определения того, закодирован ли файл в кодировке JIS-X-0208(EUC-JP), поскольку он, кажется, соответствует тому, что говорит Вики?
Однако мой движок рендеринга, похоже, распознает этот файл как EUC-JP и китайский, но, поскольку EUC-JP имеет более высокий порядок, мы думаем, что отображаются японские и японские символы.
2 ответа
Не существует абсолютно надежного способа идентифицировать неизвестную кодировку.
Шаблоны распределения, вероятно, могут помочь вам определить, смотрите ли вы на 8-битную или 16-битную кодировку. Двухбайтовые кодировки имеют тенденцию иметь слегка ограниченную схему распределения для каждого другого байта. Вот где ты сейчас.
Среди 16-битных кодировок вы также можете легко определить, смотрите ли вы на кодирование с прямым или обратным порядком байтов. Little-endian будет иметь ограниченный шаблон на четных байтах, в то время как big-endian будет иметь его на нечетных байтах. К сожалению, большинство двухбайтовых кодировок, похоже, имеют порядок байтов, так что это не сильно поможет. Если вы смотрите на little-endian, это скорее всего UTF-16LE.
Глядя на данные вашего примера, каждый второй байт кажется равным или близким к 0xC3, начиная с первого байта (но, возможно, некоторые байты отсутствуют, возможно?)
Существуют отдельные последовательности байтов, которые недопустимы в отдельных кодировках, но в целом это вряд ли поможет вам прийти к заключению. Если вы можете удалить одну или несколько возможных 16-битных кодировок с помощью этой тактики, это хорошо для вас; но, вероятно, этого будет недостаточно для решения вашей проблемы.
В этом пространстве все, что у вас осталось, это статистика. Если текст достаточно длинный, вы можете найти повторяющиеся шаблоны или использовать таблицу частот для ваших кодировок-кандидатов, чтобы рассчитать оценку для каждого. Поскольку японская система письменности разделяет общее наследие с китайцами, в их распространении вы найдете как сходства, так и различия. Типологически японский язык довольно сильно отличается от китайского, что означает, что в японском языке частицы будут встречаться каждые несколько символов, в то время как в китайском языке их вообще нет. Поэтому вы должны искать "нет" "," ва " は, " ка " か, " га " が, " ни " に и т. Д. И, если они присутствуют, сделать вывод, что вы смотрите на японский (или, наоборот, предположить, что возможно, вы смотрите на китайский, если они отсутствуют, но если вы, например, просматриваете списки имен, это все же может быть японский).
В китайском (а также в тангенциальном для японского) вы можете найти информацию о частоте на http://www.zein.se/patrick/3000char.html; но имейте в виду, что японские частицы будут гораздо чаще встречаться в японском бегущем тексте, чем любой из этих глифов.
Например, 的 (первый элемент в списке), иначе U+7684, будет 0x76 0x84 в UTF-16be, 0xAA 0xBA в Big-5, 0xC5 0xAA в EUC-JP, 0xB5 0xC4 в GB2312 и т. Д.
Исходя из ваших выборочных данных, вы, вероятно, имеете в этом списке элемент 139, то есть U+540D, который равен 0x54 0x0D в UTF-16be, 0xA5 0x57 в Big-5, 0xCC 0xBE в EUC-JP и 0xC3 0xFB в GB2312. (Вы видите? Хит!)
Существуют ли еще некоторые ограничения для определения того, закодирован ли файл в формате JIS-X-0208(EUC-JP)
Немного, в том, что ведущие байты 0xF5–0xF8 и 0xFD–0xFE не назначены, и есть также некоторые другие неназначенные символы, разбросанные в конце блоков повсюду.
Это вам здесь не поможет, поскольку последовательность байтов C3DCC2EBD3C3BBA7C3FBC3DCC2EBC3FBB3C6C3FBB3C6 одинаково действительна в ГБ (密码用户名密码名称名称) и EUC-JP (畜鷹喘薩兆 兆 鷹兆各 各.).
Такова радость, когда нюхает кодировку. Вам нужно будет обрезать и изменить порядок кодировок, которые у вас есть, исходя из вероятности их наличия в ваших входных данных. Обычно в мире Windows EUC-JP встречается редко (вместо этого будет использоваться кодовая страница 932, аналогичная Shift-JIS), поэтому кодовая страница 936, похожая на GB, обычно "выигрывает".