Существует ли стандартный формат для описания плоского файла?

Я не знаю, существует ли какой-либо стандартный или открытый формат для описания формата плоского файла. Но одна отрасль сделала это: банковский сектор. Финансовые учреждения действительно общаются, используя стандартизированные сообщения через выделенную сеть, называемую SWIFT . Сообщения SWIFT изначально были позиционными (до версии SWIFTML, XMLified). Я не знаю, хорошее ли это предложение, поскольку оно непонятно, но, возможно, вы могли бы взглянуть на Руководство по форматированию SWIFT , оно может дать вам некоторые идеи.

С учетом сказанного, ознакомьтесь с Flatworm , простой синтаксический анализатор плоских файлов. Я использовал его для анализа позиционного и / или CSV-файла, и мне понравился его формат дескриптора XML. Возможно, это лучший вариант, чем SWIFT :)

Единственное подобное, что я знаю, это Hachoir, который в настоящее время может анализировать 70 форматов файлов:

http://bitbucket.org/haypo/hachoir/wiki/Home

I ' m не уверен, действительно ли он считается декларативным языком, поскольку он основан на синтаксическом анализаторе плагинов, но, похоже, он работает и является расширяемым, что вполне может удовлетворить ваши потребности.

Кроме того, есть интересные стандартизированные, расширяемые плоские -ФОРМАТЫ файлов, такие как IFF (формат файла обмена).

CSV

CSV - это формат данных с разделителями, в котором поля / столбцы разделены символом запятой, а записи / строки разделены символом новой строки. Поля, содержащие специальный символ (запятая, новая строка или двойные кавычки), должны быть заключены в двойные кавычки. Однако, если строка содержит единственную запись, которая является пустой строкой, она может быть заключена в двойные кавычки. Если значение поля содержит символ двойной кавычки, оно экранируется, помещая рядом другой символ двойной кавычки. Формат файла CSV не требует определенной кодировки символов, порядка байтов или формата терминатора строки.

Запись CSV в википедии позволила мне найти сравнение форматов сериализации данных , которое в значительной степени то, что вы просил.

В конце концов, вам, вероятно, придется определить свой собственный стандарт файлов, который удовлетворяет ваши потребности в хранении. Я предлагаю использовать xml, YAML или JSON в качестве внутреннего контейнера для всех типов файлов, которые вы получаете. Вдобавок к этому вам придется реализовать некоторую дополнительную логику проверки для поддержания метаданных, таких как размеры столбцов файлов фиксированной ширины (для импорта и экспорта в фиксированную ширину). В качестве альтернативы вы можете сохранить или связать набор метаданных с каждым файлом, который вы конвертируете во внутренний формат.

Может существовать стандарт, но слишком сложно создать универсальные решения для этих проблем. Существуют инструменты управления отношениями сущностей (Talend и другие), которые упрощают создание этих сопоставлений, но вам все равно придется потратить много времени на поддержание определений и правил форматов файлов.

Что касается принудительной ширины столбца, xml может быть лучшим решением, поскольку вы можете описывать форматы, используя схемы xml (с ограничением длины). Для YAML или JSON вам, возможно, придется написать свою собственную логику для этого, хотя я уверен, что кто-то другой придумал решение.

См. XML и текстовые файлы с разделителями-запятыми для получения дополнительной информации.

О выборе существующих форматов плоских файлов: Существует формат значений, разделенных запятыми, (CSV). Или, в более общем смысле, DSV . Но это не «фиксированная ширина», поскольку есть символ-разделитель (например, запятая), разделяющий отдельные ячейки. Обратите внимание, что хотя CSV стандартизирован , не все соблюдают этот стандарт. Кроме того, CSV может быть слишком простым для ваших целей, поскольку он не позволяет использовать богатую структуру документа.

В этом отношении стандартизированные и лишь немного более сложные (но, следовательно, более полезные) форматы JSON и YAML - лучший выбор. Оба сразу поддерживаются множеством языков.

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

О , описывающем плоский файл форматы: Это может быть очень легко или сложно, в зависимости от формата. Хотя в большинстве случаев существуют более простые решения, один из способов, который будет работать в целом, - это просмотреть формат файла как формальную грамматику и написать лексер / парсер для этого. Но я признаю, что это вполне ^† тяжелая техника.

Если вам повезет, можно использовать несколько продвинутых регулярных выражений . Однако большинство форматов не подходят для этого. ^‡ Если вы планируете написать лексер / парсер самостоятельно, я могу посоветовать PLY (Python Lex-Yacc). Но существует много других решений на многих разных языках, многие из которых более удобны, чем старая школа Lex & Yacc . Для получения дополнительной информации см. Какой генератор парсеров вы рекомендуете?

^† : Да, это может быть преуменьшение.
^‡ : Даже правильное описание формата адреса электронной почты нетривиально.

COBOL (нравится вам это или нет) имеет стандартный формат для описания фиксированной ширины. форматы записи в файлы.

Другие форматы файлов, однако, несколько проще описать. Например, файл CSV - это просто список строк. Часто первая строка файла CSV - это имена столбцов - это описание.

Существуют примеры использования JSON для формулирования метаданных для текстовых файлов. Это может быть применено к файлам JSON, CSV и файлам фиксированного формата.

См. http://www.projectzero.org/sMash/1.1.x/docs/zero.devguide.doc/zero. ресурс / декларация.html

Это IBM ' s sMash (Project Zero) с использованием JSON для кодирования метаданных. Вы можете легко применить это к плоским файлам.