Поле четырёх месяцев разработки доступен релиз инструментария хKaitai Struct 0.4 (http://kaitai.io/) - языка для описания форматов сериализации произвольных бинарных структур данных. Идея Kaitai Struct заключается в том, что формат данных описывается с помощью простого декларативного языка на основе YAML, а затем это описание можно скомпилировать в готовый код парсера на любом из поддерживаемых языков. Для облегчения отладки предлагается визуализатор, в котором можно наблюдать, как сериализованная в файле структура раскладывается в дерево взаимосвязанных объектов в соответствии с описанием.
Основные новшества (https://github.com/kaitai-io/kaitai_struct_compiler/blob/6fd...):- Поддержка новых целевых языков: полностью поддерживается C#, предварительно поддерживается C++ (на основе стандартной библиотеки STL).
- Поддержка новых типов данных: типы с плавающей точкой IEEE 754 (одинарной и двойной точности) и выделенный тип для массивов байт
- Новые возможности языка выражений: методы для обращения к первому и последнему элементам массива, методы преобразования строк в числа, возможность обращения к объекту-потоку (например, для получения размера потока и позиционирования относительно конца структуры)
- Новые возможности препроцессинга обрабатываемых буферов: XOR с ключом переменной длины
- Стандартизация API всех runtime-библиотек и приведение их к единому виду (насколько это можно, с соблюдением традиций каждого из целевых языков)
- Полная реализация API runtime-библиотеки JavaScript (в том числе поддержка 64-битных целых через аппроксимацию в double)
На сайте проекта также доступен компилятор (http://kaitai.io/repl/), работающий в браузере (в комплекте с несколькими примерами описаний форматов) - а также растущая библиотека (https://github.com/kaitai-io/kaitai_struct_formats) примеров описаний распространенных форматов.URL: http://kaitai.io/
Новость: https://www.opennet.ru/opennews/art.shtml?num=44937
А это для чего вообще?
Для создания парсеров.
Допустим, Вы столкнулись с исследованием работы какого-то бинарного говна^W формата. Например, я сталкиваюсь с исследованием бинарного протокола обмена данными. Так вот, собственный парсер на этапе исследования можно не писать, а задействовать этот проект.
Да, в общем, и дальше, уже после исследования можно не писать - для этого проект и делался - просто сгенерировать из описания и использовать как есть.
Ну, для _исследования_ форматов есть WireShark, а эта штука нужна, когда формат уже известен и нужно быстро сделать парсер для него. Приходилось делать нечто подобное для парсинга сообщений CAN, только выхлоп у меня был на Си...
> Ну, для _исследования_ форматов есть WireShark, а эта штука нужна, когда формат
> уже известен и нужно быстро сделать парсер для него. Приходилось делать
> нечто подобное для парсинга сообщений CAN, только выхлоп у меня был
> на Си...Именно что _исследовать_ с помощью WireShark очень и очень неудобно. Писать и отлаживать диссекторы для неизвестных форматов там тяжко (даже если речь о lua). В KS же - проверка любой гипотезы - это единицы секунд. Поправил какой-нибудь типа данных с u4be на u2le, перезагрузил визуализатор - вуаля.
Это супер тема! Очень удобно, например, при разборе BLOB-ов проприетарщиков.
Тема конечно супер... при условии наличия готового описания интересующего формата.
Конечно вы правы, но кто ж вам эту инфу даст?
Поэтому и приходится заниматься реверс инжинирингом, но в этом же и интерес!
1) Понимает ли эта штука форматы, изменяющиеся в зависимости, например, от идентификатора в пакете данных?2) Что оно может, чего не может, например, protocol buffers?
> 1) Понимает ли эта штука форматы, изменяющиеся в зависимости, например, от идентификатора
> в пакете данных?Конечно.
> 2) Что оно может, чего не может, например, protocol buffers?
Разбирать произвольные существующие бинарные форматы - например, те же gif, png, mp3, ogg, avi, iso9660, fat32, elf, zip и т.д.
То есть с ним идёт ещё какая-то библиотека существующих форматов?
> То есть с ним идёт ещё какая-то библиотека существующих форматов?Библиотека - в смысле коллекции примеров .ksy-описаний форматов - конечно идет - https://github.com/kaitai-io/kaitai_struct_formats
Но идея, конечно, не в том, что где-то есть какая-то коллекция описаний, а в том что самими средствами языка можно такие форматы разбирать.
Ну, protocol buffers, насколько я понимаю, тоже может такие форматы разбирать, меня интересовало, какие преимущества здесь даёт ваша программа.
> Ну, protocol buffers, насколько я понимаю, тоже может такие форматы разбирать, меня
> интересовало, какие преимущества здесь даёт ваша программа.В традиционном виде использования - на самом деле скорее _не_ может. Protobuf в норме описывает не формат сериализации, а саму структуру данных - а формат сериализации при этом будет такой, как удобно protobuf'у. В том числе это означает что по умолчанию формат protobuf - самоописываемый, как JSON / BSON / ASN.1 DER/CER - т.е. получателю не надо знать формат, чтобы понять синтаксис. Перед каждым полем все равно будет идти префикс, который указывает тип поля и тем самым определяет, как его читать/писать, сколько оно байт будет занимать в потоке и т.д.
Можно извращаться (как мне тут недавно подсказали) и некими кастомными расширениями для protobuf в какой-то степени менять формат сериализации (и тем самым достигать возможности читать кастомные форматы), но эти расширения, во-первых, сильно зависят от языка (поэтому "описал один раз - скомпилировал под все языки" не выйдет), во-вторых, по сути приходится вносить описание формата сериализации в эти расширения, что несколько убивает весь смысл так делать. Если уж все равно писать код на определенном языке - тогда проще сразу парсер написать вручную, без всяких protobuf.
ок, спасибо.
Нет, тут немножко в кучу смешалось. Формат protobuf - не самоописываемый. Формат protobuf из приведенного списка эквивалентен ASN.1 - для того, чтобы полноценно пропарсить бинарное сообщение, получателю необходимо иметь описание формата - несмотря на то, что типы и длины в потоке указаны, имен там нет. Упрощенный пример - пришли в пакете два числа, строка, массив из трех чисел? Что это такое, что куда? Вы заранее не знаете, если не согласовать это в парсере - именно за этим компилятор protobuf-языкаДействительно полностью самоописываемым будет JSON (и, например, какая-нибудь вариация XML-схемы, где договорились об указании имен, но это таки согласовать придется опять) - в нем имеются не только типы данных, но и названия этих переменных. Вот такие данные получатель уже сможет пропарсить, не имея заранее описания синтаксиса/схемы (зачем? подумайте, например, о проблеме апгрейда между версияи - убирание старых полей, добавление новых).
Но если нужен бинарный эквивалент JSON, в наше время следует смотреть не на BSON, а на (исправление допущенных ошибок проектирования в) CBOR - он стандартизирован в RFC 7049, очень прост и для парсеров на Си, полностью совместим по модели данных с JSON, расширяем - стандартизирован уже и ряд расширений к нему (например компрессия повторяющихся имен), и кучу имплементаций под все языки на http://cbor.io/ уже наклепали.
JSON вида {"msg": ["foo", 1, 5, 7, [-1.5, -0.5]]} тоже не будет самоописываемым, если работа с msg проводится с помощью массива констант типа такого:const ENTITY_NAME = 0
const ENTITY_COORDS = 4и, соответственно, обращение через json.msg[ENTITY_COORDS] = [-1.5, -0.5].
quickbms же есть.
Есть. Только там не столько описание формата, сколько просто скриптовый язык для выполнения конкретной задачи (как правило - извлечения контента из архива). Скомпилировать это самое описание для BMS в какой-нибудь другой язык и использовать из своей программы - малореально.
Кажется избыточным в описании формата везде писать "id" и "type". Вместо какого-нибудь
seq:
- id: src_port
type: u2
- id: dst_port
type: u2Можно было бы писать просто:
seq:
- src_port: u2
- dst_port: u2
> Кажется избыточным в описании формата везде писать "id" и "type".Давайте усложним задачу :) Как тогда предлагаете описывать поля типа таких:
- id: frame_times
type: f4
repeat: expr
repeat-expr: num_frames
if: group != 0
>> Кажется избыточным в описании формата везде писать "id" и "type".
> Давайте усложним задачу :) Как тогда предлагаете описывать поля типа таких:
> - id: frame_times
> type: f4
> repeat: expr
> repeat-expr: num_frames
> if: group != 0В ваших примерах на гитхабе большинство полей идет именно как id и type. Так может, добавить частный случай, чтобы сократить писанину?
Во-первых, вы предлагаете очень странную вещь. То есть, представьте, как это будет читаться хотя бы человеческим глазом:- id: u2
- id: blah
type: strz
terminator: 0xd
- terminator: u4Сравните это с текущей, куда более однородной, на мой взгляд, записью:
- id: id
type: u2
- id: blah
type: strz
terminator: 0xd
- id: terminator
type: u4На самом деле тут задано три атрибута с идентификаторами "id", "blah" и "terminator". В описание поля всего одна key-value пара, то мы считаем идентификатором - key, а типом - value. Если больше одной - то, внезапно, все по-другому - они обрабатываются как полноценные key-value пары описания атрибута.
Вообще, предполагалось, что это формат разметки, а не полноценный язык программирования с кучей syntactic sugar, который людям придется еще надо отдельно изучать. "Много способов сделать одно и то же" не хочется поощрять. Это здорово упрощает создание дополнительных инструментов - визуализаторов, визуальных редакторов, отладчиков и т.д. Мне сделать исключения в компиляторе, разумеется, несложно - но это же исключение придется делать всем и везде. Оно того стоит?
Где картинки визуализатора?А то без него на construct смахивает.
Вот у этого товарища в статье картинок было сколько-то - https://habrahabr.ru/post/281595/Construct, безусловно, близок, но он сильно проще и сильно более императивный. Там чуть что - seek или вычисление выражения надо делать вручную из python.
Картинка визуализатора там одна. Впрочем и её достаточно -- "консольный".Не понимаю разницу с конструктом.