форумы  помощь  поиск  регистрация  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+1 +/–
Сообщение от opennews (??) on 09-Авг-16, 23:39
Поле четырёх месяцев разработки доступен релиз инструментария х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/ Новость: http://www.opennet.me/opennews/art.shtml?num=44937
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+/–
Сообщение от Аноним (??) on 09-Авг-16, 23:39
А это для чего вообще?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+2 +/–
	Сообщение от A.Stahl (ok) on 09-Авг-16, 23:47
	Для создания парсеров.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	5. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+4 +/–
	Сообщение от kai3341 (ok) on 10-Авг-16, 09:50
	Допустим, Вы столкнулись с исследованием работы какого-то бинарного говна^W формата. Например, я сталкиваюсь с исследованием бинарного протокола обмена данными. Так вот, собственный парсер на этапе исследования можно не писать, а задействовать этот проект.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	9. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+/–
	Сообщение от GreyCat (ok) on 10-Авг-16, 13:05
	Да, в общем, и дальше, уже после исследования можно не писать - для этого проект и делался - просто сгенерировать из описания и использовать как есть.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	10. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+/–
	Сообщение от dq0s4y71 (ok) on 10-Авг-16, 13:19
	Ну, для _исследования_ форматов есть WireShark, а эта штука нужна, когда формат уже известен и нужно быстро сделать парсер для него. Приходилось делать нечто подобное для парсинга сообщений CAN, только выхлоп у меня был на Си...
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	11. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+1 +/–
	Сообщение от GreyCat (ok) on 10-Авг-16, 13:22
	> Ну, для _исследования_ форматов есть WireShark, а эта штука нужна, когда формат > уже известен и нужно быстро сделать парсер для него. Приходилось делать > нечто подобное для парсинга сообщений CAN, только выхлоп у меня был > на Си... Именно что _исследовать_ с помощью WireShark очень и очень неудобно. Писать и отлаживать диссекторы для неизвестных форматов там тяжко (даже если речь о lua). В KS же - проверка любой гипотезы - это единицы секунд. Поправил какой-нибудь типа данных с u4be на u2le, перезагрузил визуализатор - вуаля.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

6. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+2 +/–
Сообщение от Аноним (??) on 10-Авг-16, 10:18
Это супер тема! Очень удобно, например, при разборе BLOB-ов проприетарщиков.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+2 +/–
	Сообщение от Аноним (??) on 10-Авг-16, 11:45
	Тема конечно супер... при условии наличия готового описания интересующего формата.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	8. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+1 +/–
	Сообщение от Аноним (??) on 10-Авг-16, 12:43
	Конечно вы правы, но кто ж вам эту инфу даст? Поэтому и приходится заниматься реверс инжинирингом, но в этом же и интерес!
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

12. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+1 +/–
Сообщение от dq0s4y71 (ok) on 10-Авг-16, 13:25
1) Понимает ли эта штука форматы, изменяющиеся в зависимости, например, от идентификатора в пакете данных? 2) Что оно может, чего не может, например, protocol buffers?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+1 +/–
	Сообщение от GreyCat (ok) on 10-Авг-16, 13:27
	> 1) Понимает ли эта штука форматы, изменяющиеся в зависимости, например, от идентификатора > в пакете данных? Конечно. > 2) Что оно может, чего не может, например, protocol buffers? Разбирать произвольные существующие бинарные форматы - например, те же gif, png, mp3, ogg, avi, iso9660, fat32, elf, zip и т.д.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	14. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+/–
	Сообщение от dq0s4y71 (ok) on 10-Авг-16, 13:40
	То есть с ним идёт ещё какая-то библиотека существующих форматов?
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	15. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+3 +/–
	Сообщение от GreyCat (ok) on 10-Авг-16, 13:42
	> То есть с ним идёт ещё какая-то библиотека существующих форматов? Библиотека - в смысле коллекции примеров .ksy-описаний форматов - конечно идет - https://github.com/kaitai-io/kaitai_struct_formats Но идея, конечно, не в том, что где-то есть какая-то коллекция описаний, а в том что самими средствами языка можно такие форматы разбирать.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	16. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+/–
	Сообщение от dq0s4y71 (ok) on 10-Авг-16, 14:09
	Ну, protocol buffers, насколько я понимаю, тоже может такие форматы разбирать, меня интересовало, какие преимущества здесь даёт ваша программа.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	17. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+3 +/–
	Сообщение от GreyCat (ok) on 10-Авг-16, 14:18
	> Ну, protocol buffers, насколько я понимаю, тоже может такие форматы разбирать, меня > интересовало, какие преимущества здесь даёт ваша программа. В традиционном виде использования - на самом деле скорее _не_ может. Protobuf в норме описывает не формат сериализации, а саму структуру данных - а формат сериализации при этом будет такой, как удобно protobuf'у. В том числе это означает что по умолчанию формат protobuf - самоописываемый, как JSON / BSON / ASN.1 DER/CER - т.е. получателю не надо знать формат, чтобы понять синтаксис. Перед каждым полем все равно будет идти префикс, который указывает тип поля и тем самым определяет, как его читать/писать, сколько оно байт будет занимать в потоке и т.д. Можно извращаться (как мне тут недавно подсказали) и некими кастомными расширениями для protobuf в какой-то степени менять формат сериализации (и тем самым достигать возможности читать кастомные форматы), но эти расширения, во-первых, сильно зависят от языка (поэтому  "описал один раз - скомпилировал под все языки" не выйдет), во-вторых, по сути приходится вносить описание формата сериализации в эти расширения, что несколько убивает весь смысл так делать. Если уж все равно писать код на определенном языке - тогда проще сразу парсер написать вручную, без всяких protobuf.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	18. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+/–
	Сообщение от dq0s4y71 (ok) on 10-Авг-16, 14:37
	ок, спасибо.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	28. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+/–
	Сообщение от nuclight (??) on 11-Авг-16, 21:09
	Нет, тут немножко в кучу смешалось. Формат protobuf - не самоописываемый. Формат protobuf из приведенного списка эквивалентен ASN.1 - для того, чтобы полноценно пропарсить бинарное сообщение, получателю необходимо иметь описание формата - несмотря на то, что типы и длины в потоке указаны, имен там нет. Упрощенный пример - пришли в пакете два числа, строка, массив из трех чисел? Что это такое, что куда? Вы заранее не знаете, если не согласовать это в парсере - именно за этим компилятор protobuf-языка Действительно полностью самоописываемым будет JSON (и, например, какая-нибудь вариация XML-схемы, где договорились об указании имен, но это таки согласовать придется опять) - в нем имеются не только типы данных, но и названия этих переменных. Вот такие данные получатель уже сможет пропарсить, не имея заранее описания синтаксиса/схемы (зачем? подумайте, например, о проблеме апгрейда между версияи - убирание старых полей, добавление новых). Но если нужен бинарный эквивалент JSON, в наше время следует смотреть не на BSON, а на (исправление допущенных ошибок проектирования в) CBOR - он стандартизирован в RFC 7049, очень прост и для парсеров на Си, полностью совместим по модели данных с JSON, расширяем - стандартизирован уже и ряд расширений к нему (например компрессия повторяющихся имен), и кучу имплементаций под все  языки на http://cbor.io/ уже наклепали.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	29. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+/–
	Сообщение от GreyCat (ok) on 12-Авг-16, 11:03
	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].
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

19. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+/–
Сообщение от anonkz on 10-Авг-16, 16:20
quickbms же есть.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	20. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+1 +/–
	Сообщение от GreyCat (ok) on 10-Авг-16, 21:13
	Есть. Только там не столько описание формата, сколько просто скриптовый язык для выполнения конкретной задачи (как правило - извлечения контента из архива). Скомпилировать это самое описание для BMS в какой-нибудь другой язык и использовать из своей программы - малореально.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	23. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+/–
	Сообщение от jacob on 11-Авг-16, 08:46
	Кажется избыточным в описании формата везде писать "id" и "type". Вместо какого-нибудь seq:   - id: src_port     type: u2   - id: dst_port     type: u2 Можно было бы писать просто: seq:   - src_port: u2   - dst_port: u2
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	25. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+/–
	Сообщение от GreyCat (ok) on 11-Авг-16, 09:14
	> Кажется избыточным в описании формата везде писать "id" и "type". Давайте усложним задачу :) Как тогда предлагаете описывать поля типа таких:       - id: frame_times         type: f4         repeat: expr         repeat-expr: num_frames         if: group != 0
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	26. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+/–
	Сообщение от jacob on 11-Авг-16, 09:35
	>> Кажется избыточным в описании формата везде писать "id" и "type". > Давайте усложним задачу :) Как тогда предлагаете описывать поля типа таких: >       - id: frame_times >         type: f4 >         repeat: expr >         repeat-expr: num_frames >         if: group != 0 В ваших примерах на гитхабе большинство полей идет именно как id и type. Так может, добавить частный случай, чтобы сократить писанину?
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	27. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+/–
	Сообщение от GreyCat (ok) on 11-Авг-16, 18:09
	Во-первых, вы предлагаете очень странную вещь. То есть, представьте, как это будет читаться хотя бы человеческим глазом: - 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, который людям придется еще надо отдельно изучать. "Много способов сделать одно и то же" не хочется поощрять. Это здорово упрощает создание дополнительных инструментов - визуализаторов, визуальных редакторов, отладчиков и т.д. Мне сделать исключения в компиляторе, разумеется, несложно - но это же исключение придется делать всем и везде. Оно того стоит?
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

22. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+/–
Сообщение от lk on 11-Авг-16, 07:19
Где картинки визуализатора? А то без него на construct смахивает.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+/–
	Сообщение от GreyCat (ok) on 11-Авг-16, 09:11
	Вот у этого товарища в статье картинок было сколько-то - https://habrahabr.ru/post/281595/ Construct, безусловно, близок, но он сильно проще и сильно более императивный. Там чуть что - seek или вычисление выражения надо делать вручную из python.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

30. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+/–
Сообщение от lk on 12-Авг-16, 14:45
Картинка визуализатора там одна. Впрочем и её достаточно -- "консольный". Не понимаю разницу с конструктом.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема