Алгоритм обнаружения кодировки символов - PullRequest
44 голосов
/ 21 апреля 2009

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

Обнаружение универсальной кодировки

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

JCharDet

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

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

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

CPDetector

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

ICU4J

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

Ответы [ 2 ]

9 голосов
/ 21 апреля 2009

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

Универсальная

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

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

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

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

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

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

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

7 голосов
/ 23 апреля 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...