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

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

Я также нашел Java-реализацию этого метода jCharDet:

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

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

ОБНОВЛЕНИЕ:. Я провел кучу исследований в этой области и в итоге нашел структуру под названием cpdetector, которая использует подключаемый подход к обнаружению символов, см.:

CPDetector

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

ICU4J

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

Ответ 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, и наоборот, поэтому иногда вы могли бы получить хорошее соответствие.

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

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

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

Ответ 1

Ответ 2