Алгоритм обнаружения кодирования символов

Question

Я ищу способ обнаружения наборов символов в документах. Я читал реализацию обнаружения набора символов Mozilla здесь:

Universal Charset Detection

Я также нашел реализацию Java этого называется jCharDet:

JCharDet

Оба они основаны на исследование, проведенное с использованием набора статических данных. Мне интересно, кто-нибудь успешно использовал любую другую реализацию, и если да, то что? Вы применили свой собственный подход, и если да, то какой алгоритм вы использовали для обнаружения набора символов?

Любая помощь будет оценена по достоинству. Я не ищу список существующих подходов через Google, ни я ищу ссылку на статью Джоэл Спольский - просто уточнить:)

UPDATE: Я сделал кучу исследований в этом и закончился что нашли основу под названием cpdetector, который использует подключаемый подход к обнаружению символов см:

CPDetector

Это обеспечивает BOM, chardet (Mozilla подход) и плагины обнаружения ASCII. Также очень легко написать свой собственный. Там же еще одна структура, которая обеспечивает намного лучшее обнаружение характер, что подход Mozilla/jchardet и т.д ...

ICU4J

Это довольно легко написать свой собственный плагин для cpdetector, который использует эту структуру, чтобы обеспечить более точный характер алгоритм обнаружения кодирования. Он работает лучше, чем подход Mozilla.

Answer 1

Несколько лет назад у нас было обнаружение набора символов для почтового приложения, и мы сделали свой собственный. Почтовое приложение было фактически WAP-приложением, и телефон ожидал UTF-8. Были несколько шагов:

Универсальных

Мы могли бы легко обнаружить, если текст был UTF-8, так как существует определенный битовый шаблон в верхних битах байта 2/3/и т.д.. Как только вы обнаружили, что шаблон повторяется определенное количество раз, вы можете быть уверены, что это UTF-8.

Если файл начинается с отметки порядка байтов UTF-16, вы, вероятно, можете предположить, что остальная часть текста - это кодировка. В противном случае обнаружение UTF-16 не так просто, как UTF-8, если вы не можете обнаружить шаблон суррогатных пар: но использование суррогатных пар встречается редко, так что обычно это не работает. UTF-32 аналогичен, за исключением того, что суррогатные пары не обнаруживаются.

Региональные обнаружения

Далее мы будем предполагать, что читатель был в определенном регионе. Например, если пользователь увидит пользовательский интерфейс, локализованный на японском языке, мы могли бы попытаться обнаружить три основных японских кодировки. ISO-2022-JP снова на восток для обнаружения с помощью управляющих последовательностей. Если это не удастся, определение разницы между EUC-JP и Shift-JIS не так просто. Скорее всего, пользователь получит текст Shift-JIS, но в EUC-JP были символы, которых не было в Shift-JIS, и наоборот, поэтому иногда вы могли бы получить хорошее совпадение.

Такая же процедура использовалась для китайских кодировок и других регионов.

выбор пользователя

Если это не дает удовлетворительных результатов, пользователь должен вручную выбрать кодировку.

Answer 2

Не совсем то, что вы просили, но я заметил, что ICU project включает класс CharsetDetector.