forum.opennet.ru

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

Оглавление

Релиз системы разбора произвольных бинарных файлов Kaitai St..., opennews (??), 09-Авг-16, (0) [смотреть все] +1

А это для чего вообще , Аноним (-), 23:39 , 09-Авг-16, (1) //

Для создания парсеров , A.Stahl (ok), 23:47 , 09-Авг-16, (2) +2
Допустим, Вы столкнулись с исследованием работы какого-то бинарного говна W форм, kai3341 (ok), 09:50 , 10-Авг-16, (5) +4 //

Да, в общем, и дальше, уже после исследования можно не писать - для этого проект, GreyCat (ok), 13:05 , 10-Авг-16, (9)
Ну, для _исследования_ форматов есть WireShark, а эта штука нужна, когда формат , dq0s4y71 (ok), 13:19 , 10-Авг-16, (10) //

Именно что _исследовать_ с помощью WireShark очень и очень неудобно Писать и от, GreyCat (ok), 13:22 , 10-Авг-16, (11) +1

Это супер тема Очень удобно, например, при разборе BLOB-ов проприетарщиков , Аноним (-), 10:18 , 10-Авг-16, (6) +2 //

Тема конечно супер при условии наличия готового описания интересующего формат, Аноним (-), 11:45 , 10-Авг-16, (7) +2 //

Конечно вы правы, но кто ж вам эту инфу даст Поэтому и приходится заниматься рев, Аноним (-), 12:43 , 10-Авг-16, (8) +1

1 Понимает ли эта штука форматы, изменяющиеся в зависимости, например, от идент, dq0s4y71 (ok), 13:25 , 10-Авг-16, (12) +1 //

Конечно Разбирать произвольные существующие бинарные форматы - например, те же g, GreyCat (ok), 13:27 , 10-Авг-16, (13) +1 //

То есть с ним идёт ещё какая-то библиотека существующих форматов , dq0s4y71 (ok), 13:40 , 10-Авг-16, (14) //

Библиотека - в смысле коллекции примеров ksy-описаний форматов - конечно идет -, GreyCat (ok), 13:42 , 10-Авг-16, (15) +3

Ну, protocol buffers, насколько я понимаю, тоже может такие форматы разбирать, м, dq0s4y71 (ok), 14:09 , 10-Авг-16, (16)

В традиционном виде использования - на самом деле скорее _не_ может Protobuf в , GreyCat (ok), 14:18 , 10-Авг-16, (17) +3

ок, спасибо , dq0s4y71 (ok), 14:37 , 10-Авг-16, (18)
Нет, тут немножко в кучу смешалось Формат protobuf - не самоописываемый Формат, nuclight (??), 21:09 , 11-Авг-16, (28)

JSON вида msg foo , 1, 5, 7, -1 5, -0 5 тоже не будет самоописываемым,, GreyCat (ok), 11:03 , 12-Авг-16, (29)

quickbms же есть , anonkz (?), 16:20 , 10-Авг-16, (19) //

Есть Только там не столько описание формата, сколько просто скриптовый язык для, GreyCat (ok), 21:13 , 10-Авг-16, (20) +1 //

Кажется избыточным в описании формата везде писать id и type Вместо какого-, jacob (?), 08:46 , 11-Авг-16, (23) //

Давайте усложним задачу Как тогда предлагаете описывать поля типа таких , GreyCat (ok), 09:14 , 11-Авг-16, (25)

В ваших примерах на гитхабе большинство полей идет именно как id и type Так мож, jacob (?), 09:35 , 11-Авг-16, (26)

Во-первых, вы предлагаете очень странную вещь То есть, представьте, как это буд, GreyCat (ok), 18:09 , 11-Авг-16, (27)

Где картинки визуализатора А то без него на construct смахивает , lk (?), 07:19 , 11-Авг-16, (22) //

Вот у этого товарища в статье картинок было сколько-то - https habrahabr ru po, GreyCat (ok), 09:11 , 11-Авг-16, (24)

Картинка визуализатора там одна Впрочем и её достаточно -- консольный Не пони, lk (?), 14:45 , 12-Авг-16, (30)

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

12. "Релиз системы разбора произвольных бинарных файлов Kaitai St..." +1 +/–

Сообщение от dq0s4y71 (ok), 10-Авг-16, 13:25

1) Понимает ли эта штука форматы, изменяющиеся в зависимости, например, от идентификатора в пакете данных?
2) Что оно может, чего не может, например, protocol buffers?

Ответить | Правка | Наверх | Cообщить модератору

13. "Релиз системы разбора произвольных бинарных файлов Kaitai St..." +1 +/–

Сообщение от GreyCat (ok), 10-Авг-16, 13:27

> 1) Понимает ли эта штука форматы, изменяющиеся в зависимости, например, от идентификатора
> в пакете данных?
Конечно.
> 2) Что оно может, чего не может, например, protocol buffers?
Разбирать произвольные существующие бинарные форматы - например, те же gif, png, mp3, ogg, avi, iso9660, fat32, elf, zip и т.д.

Ответить | Правка | Наверх | Cообщить модератору

14. "Релиз системы разбора произвольных бинарных файлов Kaitai St..." +/–

Сообщение от dq0s4y71 (ok), 10-Авг-16, 13:40

То есть с ним идёт ещё какая-то библиотека существующих форматов?

Ответить | Правка | Наверх | Cообщить модератору

15. "Релиз системы разбора произвольных бинарных файлов Kaitai St..." +3 +/–

Сообщение от GreyCat (ok), 10-Авг-16, 13:42

> То есть с ним идёт ещё какая-то библиотека существующих форматов?
Библиотека - в смысле коллекции примеров .ksy-описаний форматов - конечно идет - https://github.com/kaitai-io/kaitai_struct_formats
Но идея, конечно, не в том, что где-то есть какая-то коллекция описаний, а в том что самими средствами языка можно такие форматы разбирать.

Ответить | Правка | Наверх | Cообщить модератору

16. "Релиз системы разбора произвольных бинарных файлов Kaitai St..." +/–

Сообщение от dq0s4y71 (ok), 10-Авг-16, 14:09

Ну, protocol buffers, насколько я понимаю, тоже может такие форматы разбирать, меня интересовало, какие преимущества здесь даёт ваша программа.

Ответить | Правка | Наверх | Cообщить модератору

17. "Релиз системы разбора произвольных бинарных файлов Kaitai St..." +3 +/–

Сообщение от GreyCat (ok), 10-Авг-16, 14:18

> Ну, protocol buffers, насколько я понимаю, тоже может такие форматы разбирать, меня
> интересовало, какие преимущества здесь даёт ваша программа.
В традиционном виде использования - на самом деле скорее _не_ может. Protobuf в норме описывает не формат сериализации, а саму структуру данных - а формат сериализации при этом будет такой, как удобно protobuf'у. В том числе это означает что по умолчанию формат protobuf - самоописываемый, как JSON / BSON / ASN.1 DER/CER - т.е. получателю не надо знать формат, чтобы понять синтаксис. Перед каждым полем все равно будет идти префикс, который указывает тип поля и тем самым определяет, как его читать/писать, сколько оно байт будет занимать в потоке и т.д.
Можно извращаться (как мне тут недавно подсказали) и некими кастомными расширениями для protobuf в какой-то степени менять формат сериализации (и тем самым достигать возможности читать кастомные форматы), но эти расширения, во-первых, сильно зависят от языка (поэтому "описал один раз - скомпилировал под все языки" не выйдет), во-вторых, по сути приходится вносить описание формата сериализации в эти расширения, что несколько убивает весь смысл так делать. Если уж все равно писать код на определенном языке - тогда проще сразу парсер написать вручную, без всяких protobuf.

Ответить | Правка | Наверх | Cообщить модератору

18. "Релиз системы разбора произвольных бинарных файлов Kaitai St..." +/–

Сообщение от dq0s4y71 (ok), 10-Авг-16, 14:37

ок, спасибо.

Ответить | Правка | Наверх | Cообщить модератору

28. "Релиз системы разбора произвольных бинарных файлов Kaitai St..." +/–

Сообщение от nuclight (??), 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), 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].

Ответить | Правка | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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


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


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


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


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


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


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


	28. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."	+/–
	Сообщение от nuclight (??), 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), 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].
	Ответить \| Правка \| Наверх \| Cообщить модератору