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

существует ли стандартный или открытый формат, который можно использовать для описания формирования плоского файла. Моя компания объединяет множество различных форматов файлов клиента. С XML-файлом легко получить или создать XSD для описания формата XML-файла. Я ищу что-то похожее на описание формата плоского файла (фиксированная ширина, разделители и т. д.). Stylus Studio использует фирменный .формат conv для этого. Что.формат conv может использоваться во время выполнения для преобразования произвольного плоского файла в XML файл. Мне просто интересно, есть ли более открытый или основанный на стандартах метод для того же самого.

Я ищу один метод описания различных форматов плоских файлов, являются ли они фиксированной шириной или разделены, поэтому CSV не является ответом на этот вопрос.

7 ответов


XFlat: http://www.infoloom.com/gcaconfs/WEB/philadelphia99/lyons.HTM#N29 http://www.unidex.com/overview.htm

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


о выбрать плоские форматы файлов: есть значения, разделенные запятыми (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.resource/declaration.html

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


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

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

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

посмотреть XML vs текстовые файлы с разделителями-запятыми для дальнейшего использования.


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

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


CSV-файла

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


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


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

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

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

в стороне, есть интересные стандартизированные, расширяемые форматы плоских файлов ,такие как IFF (файл обмена Формат.)