отказоустойчивый парсер на основе Python для кабелей WikiLeaks

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

Кабина состоит из трех частей. Заголовок имеет формат в стиле RFC2822. Этот разбор обычно правильный. Текстовая часть имеет более неформальную спецификацию. Например, есть строка REF. Это должно начинаться с REF:, но я нашел разные версии. Следующее регулярное выражение улавливает большинство случаев: ^\s*[Rr][Ee][Ff][Ss: ]. Итак, впереди пробелы, разные корпуса и так далее. Текстовая часть представляет собой в основном обычный текст с некоторыми специально отформатированными заголовками.

Мы хотим распознавать каждое поле (дата, ссылка и т. д.) и помещать его в базу данных. Мы выбрали Pythons SimpleParse. На данный момент синтаксический анализ останавливается на каждом поле, которое он не распознает. Сейчас мы ищем более отказоустойчивое решение. Все поля имеют какой-то порядок. Когда синтаксический анализатор не распознает поле, он должен добавить к текущему полю некоторый «не распознанный» блок и продолжить. (Или, может быть, у вас есть лучший подход здесь).

Какой парсер или другое решение вы бы предложили? Вокруг что-то лучше?


person qbi    schedule 15.05.2011    source источник
comment
Вы уверены, что вам нужен парсер? То, что вы описали о структуре кабелей, звучит как язык типа 3 (в классификации Хомского), что подразумевает, что лексер (например, flex) или регулярные выражения являются средствами для анализа кабелей.   -  person phynfo    schedule 15.05.2011
comment
Почему бы просто не добавить / not_recognized к каждому токену заголовка?   -  person Daniel Kluev    schedule 15.05.2011
comment
Я не уверен, что мне действительно нужен парсер. По моему мнению, ввод парсера более удобочитаем, чем регулярное выражение. Вот почему я склонялся к этому. Флекс посмотрю.   -  person qbi    schedule 15.05.2011


Ответы (2)


Cablemap, кажется, делает то, что вы ищете: http://pypi.python.org/pypi/cablemap.core/

person michk    schedule 20.07.2011

Я не смотрел кабели, но давайте возьмем аналогичную проблему и рассмотрим варианты: Допустим, вы хотите написать синтаксический анализатор для RFC, есть RFC для форматирования RFC, но не все RFC следуют ему.

Если вы написали строгий синтаксический анализатор, вы столкнетесь с ситуацией, с которой вы столкнулись - выбросы остановят ваш прогресс - в этом случае у вас есть два варианта:

  1. Разделите их на две группы: те, которые строго отформатированы, и те, которые нет. Напишите свой строгий синтаксический анализатор, чтобы он получал низко висящие плоды, и выясняйте на основе числовых выбросов, какие варианты являются лучшими (ручная обработка, анализатор выбросов и т. д.).

  2. Если две группы одинакового размера или выбросов больше, чем стандартных форматов — напишите гибкий синтаксический анализатор. В этом случае регулярные выражения будут более полезными для вас, поскольку вы можете обработать весь файл в поисках серии гибких регулярных выражений, и если одно из регулярных выражений не работает, вы можете легко создать список выбросов. Но, поскольку вы можете выполнять поиск по ряду регулярных выражений, вы можете построить матрицу прохождения/непрохождения для каждого регулярного выражения.

Для «нечетких» данных, где некоторые следуют формату, а некоторые нет, я предпочитаю использовать подход регулярных выражений. Это только я, хотя. (Да, это медленнее, но необходимость создавать отношения между каждым сегментом совпадения, чтобы у вас был один запрос (или синтаксический анализатор), который подходит для каждого крайнего случая, — это кошмар при работе с вводом, созданным человеком.

person synthesizerpatel    schedule 05.07.2011