| |
| 2.5, kai3341 (ok), 09:50, 10/08/2016 [^] [^^] [^^^] [ответить]
| +4 +/– |
 Допустим, Вы столкнулись с исследованием работы какого-то бинарного говна^W формата. Например, я сталкиваюсь с исследованием бинарного протокола обмена данными. Так вот, собственный парсер на этапе исследования можно не писать, а задействовать этот проект.
| | |
| |
| 3.9, GreyCat (ok), 13:05, 10/08/2016 [^] [^^] [^^^] [ответить]
| +/– |
 Да, в общем, и дальше, уже после исследования можно не писать - для этого проект и делался - просто сгенерировать из описания и использовать как есть.
| | |
| 3.10, dq0s4y71 (ok), 13:19, 10/08/2016 [^] [^^] [^^^] [ответить]
| +/– |
 Ну, для _исследования_ форматов есть WireShark, а эта штука нужна, когда формат уже известен и нужно быстро сделать парсер для него. Приходилось делать нечто подобное для парсинга сообщений CAN, только выхлоп у меня был на Си...
| | |
| |
| 4.11, GreyCat (ok), 13:22, 10/08/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Ну, для _исследования_ форматов есть WireShark, а эта штука нужна, когда формат
> уже известен и нужно быстро сделать парсер для него. Приходилось делать
> нечто подобное для парсинга сообщений CAN, только выхлоп у меня был
> на Си...
Именно что _исследовать_ с помощью WireShark очень и очень неудобно. Писать и отлаживать диссекторы для неизвестных форматов там тяжко (даже если речь о lua). В KS же - проверка любой гипотезы - это единицы секунд. Поправил какой-нибудь типа данных с u4be на u2le, перезагрузил визуализатор - вуаля.
| | |
|
|
|
| 1.6, Аноним (-), 10:18, 10/08/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Это супер тема! Очень удобно, например, при разборе BLOB-ов проприетарщиков.
| | |
| |
| 2.7, Аноним (-), 11:45, 10/08/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
Тема конечно супер... при условии наличия готового описания интересующего формата.
| | |
| |
| 3.8, Аноним (-), 12:43, 10/08/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Конечно вы правы, но кто ж вам эту инфу даст?
Поэтому и приходится заниматься реверс инжинирингом, но в этом же и интерес!
| | |
|
|
| 1.12, dq0s4y71 (ok), 13:25, 10/08/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
1) Понимает ли эта штука форматы, изменяющиеся в зависимости, например, от идентификатора в пакете данных?
2) Что оно может, чего не может, например, protocol buffers?
| | |
| |
| 2.13, GreyCat (ok), 13:27, 10/08/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> 1) Понимает ли эта штука форматы, изменяющиеся в зависимости, например, от идентификатора
> в пакете данных?
Конечно.
> 2) Что оно может, чего не может, например, protocol buffers?
Разбирать произвольные существующие бинарные форматы - например, те же gif, png, mp3, ogg, avi, iso9660, fat32, elf, zip и т.д.
| | |
| |
| |
| 4.15, GreyCat (ok), 13:42, 10/08/2016 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> То есть с ним идёт ещё какая-то библиотека существующих форматов?
Библиотека - в смысле коллекции примеров .ksy-описаний форматов - конечно идет - https://github.com/kaitai-io/kaitai_struct_formats
Но идея, конечно, не в том, что где-то есть какая-то коллекция описаний, а в том что самими средствами языка можно такие форматы разбирать.
| | |
| |
| 5.16, dq0s4y71 (ok), 14:09, 10/08/2016 [^] [^^] [^^^] [ответить]
| +/– |
Ну, protocol buffers, насколько я понимаю, тоже может такие форматы разбирать, меня интересовало, какие преимущества здесь даёт ваша программа.
| | |
| |
| 6.17, GreyCat (ok), 14:18, 10/08/2016 [^] [^^] [^^^] [ответить]
| +3 +/– |
> Ну, protocol buffers, насколько я понимаю, тоже может такие форматы разбирать, меня
> интересовало, какие преимущества здесь даёт ваша программа.
В традиционном виде использования - на самом деле скорее _не_ может. Protobuf в норме описывает не формат сериализации, а саму структуру данных - а формат сериализации при этом будет такой, как удобно protobuf'у. В том числе это означает что по умолчанию формат protobuf - самоописываемый, как JSON / BSON / ASN.1 DER/CER - т.е. получателю не надо знать формат, чтобы понять синтаксис. Перед каждым полем все равно будет идти префикс, который указывает тип поля и тем самым определяет, как его читать/писать, сколько оно байт будет занимать в потоке и т.д.
Можно извращаться (как мне тут недавно подсказали) и некими кастомными расширениями для protobuf в какой-то степени менять формат сериализации (и тем самым достигать возможности читать кастомные форматы), но эти расширения, во-первых, сильно зависят от языка (поэтому "описал один раз - скомпилировал под все языки" не выйдет), во-вторых, по сути приходится вносить описание формата сериализации в эти расширения, что несколько убивает весь смысл так делать. Если уж все равно писать код на определенном языке - тогда проще сразу парсер написать вручную, без всяких protobuf.
| | |
| |
| 7.28, nuclight (??), 21:09, 11/08/2016 [^] [^^] [^^^] [ответить]
| +/– |
 Нет, тут немножко в кучу смешалось. Формат protobuf - не самоописываемый. Формат protobuf из приведенного списка эквивалентен ASN.1 - для того, чтобы полноценно пропарсить бинарное сообщение, получателю необходимо иметь описание формата - несмотря на то, что типы и длины в потоке указаны, имен там нет. Упрощенный пример - пришли в пакете два числа, строка, массив из трех чисел? Что это такое, что куда? Вы заранее не знаете, если не согласовать это в парсере - именно за этим компилятор protobuf-языка
Действительно полностью самоописываемым будет JSON (и, например, какая-нибудь вариация XML-схемы, где договорились об указании имен, но это таки согласовать придется опять) - в нем имеются не только типы данных, но и названия этих переменных. Вот такие данные получатель уже сможет пропарсить, не имея заранее описания синтаксиса/схемы (зачем? подумайте, например, о проблеме апгрейда между версияи - убирание старых полей, добавление новых).
Но если нужен бинарный эквивалент JSON, в наше время следует смотреть не на BSON, а на (исправление допущенных ошибок проектирования в) CBOR - он стандартизирован в RFC 7049, очень прост и для парсеров на Си, полностью совместим по модели данных с JSON, расширяем - стандартизирован уже и ряд расширений к нему (например компрессия повторяющихся имен), и кучу имплементаций под все языки на http://cbor.io/ уже наклепали.
| | |
| |
| 8.29, GreyCat (ok), 11:03, 12/08/2016 [^] [^^] [^^^] [ответить] | +/– | JSON вида msg foo , 1, 5, 7, -1 5, -0 5 тоже не будет самоописываемым,... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| |
| 2.20, GreyCat (ok), 21:13, 10/08/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Есть. Только там не столько описание формата, сколько просто скриптовый язык для выполнения конкретной задачи (как правило - извлечения контента из архива). Скомпилировать это самое описание для BMS в какой-нибудь другой язык и использовать из своей программы - малореально.
| | |
| |
| 3.23, jacob (?), 08:46, 11/08/2016 [^] [^^] [^^^] [ответить]
| +/– |
Кажется избыточным в описании формата везде писать "id" и "type". Вместо какого-нибудь
seq:
- id: src_port
type: u2
- id: dst_port
type: u2
Можно было бы писать просто:
seq:
- src_port: u2
- dst_port: u2
| | |
| |
| 4.25, GreyCat (ok), 09:14, 11/08/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> Кажется избыточным в описании формата везде писать "id" и "type".
Давайте усложним задачу :) Как тогда предлагаете описывать поля типа таких:
- id: frame_times
type: f4
repeat: expr
repeat-expr: num_frames
if: group != 0
| | |
| |
| 5.26, jacob (?), 09:35, 11/08/2016 [^] [^^] [^^^] [ответить]
| +/– |
>> Кажется избыточным в описании формата везде писать "id" и "type".
> Давайте усложним задачу :) Как тогда предлагаете описывать поля типа таких:
> - id: frame_times
> type: f4
> repeat: expr
> repeat-expr: num_frames
> if: group != 0
В ваших примерах на гитхабе большинство полей идет именно как id и type. Так может, добавить частный случай, чтобы сократить писанину?
| | |
| |
| 6.27, GreyCat (ok), 18:09, 11/08/2016 [^] [^^] [^^^] [ответить]
| +/– | |
Во-первых, вы предлагаете очень странную вещь. То есть, представьте, как это будет читаться хотя бы человеческим глазом:
- 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, который людям придется еще надо отдельно изучать. "Много способов сделать одно и то же" не хочется поощрять. Это здорово упрощает создание дополнительных инструментов - визуализаторов, визуальных редакторов, отладчиков и т.д. Мне сделать исключения в компиляторе, разумеется, несложно - но это же исключение придется делать всем и везде. Оно того стоит?
| | |
|
|
|
|
|
| 1.22, lk (?), 07:19, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Где картинки визуализатора?
А то без него на construct смахивает.
| | |
| |
| 2.24, GreyCat (ok), 09:11, 11/08/2016 [^] [^^] [^^^] [ответить]
| +/– | |
Вот у этого товарища в статье картинок было сколько-то - https://habrahabr.ru/post/281595/
Construct, безусловно, близок, но он сильно проще и сильно более императивный. Там чуть что - seek или вычисление выражения надо делать вручную из python.
| | |
|
| 1.30, lk (?), 14:45, 12/08/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Картинка визуализатора там одна. Впрочем и её достаточно -- "консольный".
Не понимаю разницу с конструктом.
| | |
|
