Обнаружьте содержание файла UTF-16

Для каждого класса, с которым Вы используете это, Вы оказываетесь перед необходимостью искать Регистратор так или иначе, таким образом, Вы могли бы также просто использовать статический Регистратор в тех классах.

private static final Logger logger = Logger.getLogger(MyClass.class.getName());

Тогда Вы просто ссылка, что регистратор, когда необходимо сделать сообщения журнала. Ваш метод делает то же самое, которое статический Регистратор Log4J уже делает итак, почему перестраивают колесо?

6
задан Peter Mortensen 28 August 2018 в 16:35
поделиться

6 ответов

То же, что сказал Брайан Агнью о чтении метки порядка байтов , специальных двух байтов, которые могут появиться в начале файла.

Вы также можете знать если это ASCII, путем сканирования каждого байта в файле и проверки, все ли они меньше 128. Если все они меньше 128, то это просто файл ASCII. Если некоторые из них больше 128, там есть другая кодировка.

3
ответ дан 8 December 2019 в 12:20
поделиться

Вы можете иметь возможность читать отметку порядка байтов , если она есть в файле.

8
ответ дан 8 December 2019 в 12:20
поделиться

Если файл, для которого вы должны решить эту проблему, каждый раз достаточно длинный, и у вас есть некоторое представление о том, что он должен быть (скажем, английский текст в Юникоде или английский текст в ASCII), вы можете сделать простой частотный анализ символов и посмотреть, похоже ли распределение на ASCII или unicode.

1
ответ дан 8 December 2019 в 12:20
поделиться

Юникод - это алфавит, а не кодировка. Вы, наверное, имели в виду UTF-16. Существует множество библиотек (сразу приходит на ум python-chardet) для автоматического определения кодировки текста, хотя все они используют эвристику.

1
ответ дан 8 December 2019 в 12:20
поделиться

Для вашего конкретного вариант использования, это очень легко сказать. Просто просканируйте файл, если вы найдете какой-либо NULL ("\ 0"), это должен быть UTF-16. JavaScript должен иметь символы ASCII, и они представлены ведущим 0 в UTF-16.

0
ответ дан 8 December 2019 в 12:20
поделиться

Во-первых, ASCII является 7-битным, поэтому, если у какого-либо байта установлен старший бит, вы знаете, что файл не является ASCII.

Различные "общие" наборы символов, такие как ISO-8859-x, Windows- 1252 и т. Д. Являются 8-битными, поэтому, если каждый второй байт равен 0, вы знаете, что имеете дело с Unicode, который использует только символы ISO-8859.

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


Отредактируйте в ответ на комментарий OP:

Я думаю , что будет достаточно проверить наличие в вашем контенте байтов с нулевым значением (ASCII NUL) и сделать выбор на основании этого. Причина в том, что ключевые слова JavaScript - это ASCII, а ASCII - это подмножество Unicode. Поэтому любое представление этих ключевых слов в Юникоде будет состоять из одного байта, содержащего символ ASCII (младший байт), и другого, содержащего 0 (старший байт).

Единственное мое предостережение: вы внимательно прочтите документацию, чтобы убедиться, что они используют слово "Unicode" правильное (я просмотрел эту страницу , чтобы понять функцию, больше не смотрел).

2
ответ дан 8 December 2019 в 12:20
поделиться
Другие вопросы по тегам:

Похожие вопросы: