Ответ 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, и наоборот, поэтому иногда вы могли бы получить хорошее соответствие.
Такая же процедура использовалась для китайских кодировок и других регионов.
Выбор пользователя
Если они не дали удовлетворительных результатов, пользователь должен вручную выбрать кодировку.