Дизайн инструментария для разбора файлов Java, быстрая проверка работоспособности кодировки файлов

Question

(Отказ от ответственности: я просмотрел несколько постов здесь, прежде чем спросить, я нашел этот особенно полезным, я просто искал от вас, по возможности, немного проверки вменяемости)

Привет всем,

У меня есть встроенный продукт Java, который я создал для обработки файлов данных для загрузки в базу данных (AKA инструмент ETL). У меня есть готовые этапы для преобразования XSLT и выполнения таких операций, как замена шаблонов в исходном файле. Входные файлы могут быть любого формата, они могут быть плоскими файлами данных или файлами данных XML, вы настраиваете этапы, необходимые для конкретной загружаемой подачи данных.

Я до сих пор игнорировал проблему кодировки файлов (я знаю ошибку), потому что все работало нормально (в основном). Тем не менее, сейчас я сталкиваюсь с проблемами кодирования файлов, чтобы вкратце сказать, потому что из-за природы того, как этапы могут быть настроены вместе, мне нужно определить кодировку файла входного файла и создать объект Java Reader с соответствующие аргументы. Я просто хотел провести быструю проверку здравомыслия с вами, прежде чем погрузиться во что-то, чего я не могу себе представить, чтобы полностью понять:

1. Принять стандартную кодировку файлов UTF-16 (я не исключаю загрузки двухбайтовых символов в будущем) для всех файлов, которые выводятся на каждом этапе в моем наборе инструментов
2. Используйте JUniversalChardet или jchardet , чтобы прослушать кодировку входного файла
3. Используйте библиотеку Apache Commons IO для создания стандартного устройства чтения и записи для всех этапов (правильно ли я считаю, что у него нет аналогичного API-интерфейса для кодирования?)

Видите ли вы какие-либо подводные камни / есть ли дополнительная мудрость, чтобы предложить в моем изложенном подходе?

Можно ли быть уверенным в обратной совместимости с любыми загруженными данными, используя мой существующий подход, позволяющий среде выполнения Java определять кодировку windows-1252?

Заранее спасибо,

-Джеймс

Answer 1

Для файлов с плоскими символами любое обнаружение кодирования должно опираться на статистику и эвристику (например, наличие BOM или частоту символов / шаблонов), поскольку существуют последовательности байтов, которые будут допустимы более одной кодировки, но отображаются на разные символы.

XML обнаружение кодирования должно быть более простым, но, безусловно, возможно создать неоднозначно закодированный XML (например, исключив кодировку в заголовке).

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

Когда вы преобразуете данные из byte s в char s в Java, вы транскодируете из кодирования X в UTF-16 (BE). То, что отправляется в вашу базу данных, зависит от вашей базы данных, ее драйвера JDBC и от того, как вы настроили столбец. Это, вероятно, включает в себя перекодирование из UTF-16 во что-то еще. Предполагая, что вы не изменяете базу данных, существующие символьные данные должны быть в безопасности; у вас могут возникнуть проблемы, если вы собираетесь анализировать BLOB-объекты. Если вы уже проанализировали файлы, написанные в разрозненных кодировках, но рассматривали их как другую кодировку, повреждение уже произошло - нет серебряных пуль, чтобы это исправить. Если вам нужно изменить набор символов базы данных с «ANSI» на Unicode, это может привести к болезненному .

Принятие Unicode , где это возможно, хорошая идея. Это может быть невозможным, но предпочитайте форматы файлов, в которых вы можете сделать кодировку однозначной - такие вещи, как XML (что делает его простым) или JSON (который требует UTF-8).

Answer 2

Вариант 1 поражает меня как нарушение обратной совместимости (конечно, в долгосрочной перспективе), хотя «правильный путь» (правильный путь обычно нарушает обратную совместимость), возможно, с дополнительными мыслями о том, будет ли UTF-8хороший выбор.

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

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