LINUX.ORG.RU

Kaitai Struct 0.6

 , , ,


5

3

Вышла новая версия Kaitai Struct — языка спецификации произвольных бинарных форматов файлов, пакетов, протоколов и т. д.

Основная идея проекта в том, что формат бинарного файла описывается один раз на языке .ksy, после чего файлы такого формата можно рассматривать в визуализаторах, получая представление о том, каким байтам соответствуют какие значения элементов формата, сгенерировать человекочитаемую диаграмму формата, а самое главное — сгенерировать готовую библиотеку парсинга такого формата на одном из 8 поддерживаемых целевых языков: C++, C#, Java, JavaScript, Perl, PHP, Python, Ruby.

В новой версии стоит отметить следующие улучшения:

  • поддержка побитового чтения (в том числе для парсинга битовых полей, битовых потоков и т.д.) - type: bXX теперь позволит прочитать XX бит как число, type: b1 прочитает один бит и представит его как boolean
  • масса возможностей добавить метаинформацию о формате в .ksy: ключ doc на уровне типов, а также ключи title, license, ks-version в meta
  • поддержка нестандартных ключей а ля CSS, с минусом в начале; активно используется в Web IDE для задания опций отображения (-webide-representation) и т. д.
  • массивные изменения движка вывода типов: enum теперь тоже ресолвится по единым правилам, даже в языках, где таковой поддержки нет нативно (Python, PHP, Perl, JavaScript и т. д.)
  • идентификатор id для атрибутов последовательности теперь опционален; если его не задать, будет автоматически присвоен уникальный числовой идентификатор, что удобно для быстрого разбора неизвестных полей в форматах
  • поддержка подключения внешних типов (если задать type: foo и foo не определен в текущем файле, будет сгенерирован корректный import / include в предположении, что тип объявлен во внешнем файле)
  • возможность писать целочисленные литералы с разделителями (123_456_789 или 0b0101_1111), а также преобразовывать числа в строки с помощью метода to_s
  • исправление ошибок, оптимизация генерируемого кода

Релиз приурочен к проходящей в эти выходные конференции FOSDEM 2017. 5 февраля будет представлен доклад о парсинге бинарных media-форматов с помощью Kaitai Struct в рамках Open Media devroom. Для интересующихся, но не имеющих возможности посетить доклад лично, организована онлайн-трансляция видео.

>>> Подробности

★★

Проверено: jollheef ()

А почему си забыли?

Или «нинужна»?

anonymous ()
Ответ на: А почему си забыли? от anonymous

С си они никак не могут определиться с тем, какой лучше генерировать код.

SZT ★★★☆ ()
Ответ на: комментарий от hobbit

Для концептуальной договоренности неплохо бы найти хотя бы один реально заинтересованный проект :) Пока почему-то на C++ я знаю около десятка реальных пользователей, на Java - тоже, а вот про C почему-то пока в основном разговоры.

GreyCat ★★ ()

C++, C#, Java, JavaScript, Perl, PHP, Python, Ruby

Как нет хачкеля??

anonymous ()
Ответ на: комментарий от SZT

Надо просто несколько разных генераторов запилить с разными подходами.

unC0Rr ★★★★★ ()

Очередной велосипед по стандартизации 14 предыдущих стандартов :) JSON им мало - это же NIH!

matumba ★★★★★ ()
Ответ на: комментарий от unC0Rr

Да вот только пилить генераторы в воздух как-то не хочется. Это не так быстро, а от всяких реквестов и так трекер ломится. Лучше делать что-нибудь востребованное, не?

GreyCat ★★ ()
Ответ на: комментарий от matumba

Можно полюбопытствовать, какое отношение имеет JSON к топику?

GreyCat ★★ ()
Ответ на: комментарий от matumba

ты вообще читал о чем этот софт ?

anonymous ()
Ответ на: комментарий от matumba

JSON? Что ты несешь... А, норм, это матумба.

anonymous ()

Насколько оно готово для продакшена. Насколько это можно безопасно использовать. Допустим, мне нужно описать формат транзакций Bitcoin. Какова вероятность отстрелить себе ногу из-за ошибки в самом Kaitai Struct, или что сломают совместимость.

Следует ли его применять, когда нужно описать бинарный формат один раз, и уже наверняка знать, что сможешь его применять неограниченное время в дальнейшем, и что ничего не сломается? Как разработчики позиционируют проект, как экспериментальный, или как готовый к применению?

anonymous ()

А может kaitai обойтись без std::ifstream, допустим указателем на uint8_t и размером данных? Можно ли узнать минимальный размер необходимых данных для желаемого типа?

uint32_t minSize = kaitai::getMinSize(git_t);
// load data in to memory const uint8_t* data; uint32_t minSize;
kaitai::kstream ks(data, minSize);
gif_t g = gif_t(&ks);
if (g.isDataValid())
{
   // bingo!
}
else
{
   // try another format
}

andreyu ★★★★★ ()
Ответ на: комментарий от andreyu

Навороты нехилые, но применимость на практике так себе. При разборе формата, особенно если спека отсутствует, описать формализмрованным языком будет сложно.

Linfan ★★★★★ ()
Ответ на: комментарий от Linfan

Навороты нехилые, но применимость на практике так себе.

Практики бывают разные. Я, прочитав эту новость, сразу подумал о использовании kaitai в своем вьювере.

andreyu ★★★★★ ()

Шо тока не придумают, чтоб бинарные логи в systemd на человекочитаемые не менять.

LittleKawaiiNeko ★★ ()
Ответ на: комментарий от anonymous

Насколько оно готово для продакшена

Несколько десятков проектов используют.

Допустим, мне нужно описать формат транзакций Bitcoin

Он вроде бы совсем примитивный, кто-то вроде уже что-то такое заявлял, что делает...

Какова вероятность отстрелить себе ногу из-за ошибки в самом Kaitai Struct, или что сломают совместимость.

Вероятность всегда и везде есть, вопрос в цене ошибки. Если нужны гарантии и SLA - сами знаете, оформляется договор и вот они - гарантии.

Как разработчики позиционируют проект, как экспериментальный, или как готовый к применению?

До 1.0 может незначительно меняться API и явно будут ужесточаться проверки, которые делает компилятор, но если не делать каких-то совсем странных вещей, вряд ли это будет сильно актуально в обычных проектах.

GreyCat ★★ ()
Ответ на: комментарий от andreyu

А может kaitai обойтись без std::ifstream, допустим указателем на uint8_t и размером данных?

std::ifstream совсем не обязателен, там std::istream. Указатель и размер всегда можно обернуть в какой-нибудь std::istringstream - и вперед.

Можно ли узнать минимальный размер необходимых данных для желаемого типа?

Пока нет и, честно говоря, не очень представляю, зачем это нужно. Через какое-то время будет можно узнать что-то типа sizeof() по отдельным типам - но, опять же, не факт, что это будет выведено на уровень целевого языка, а не останется оператором языка выражений внутри KS.

GreyCat ★★ ()
Ответ на: комментарий от Linfan

При разборе формата, особенно если спека отсутствует, описать формализмрованным языком будет сложно.

Оно, собственно, как раз в основном для разбора неизвестных форматов и писалось. В итоге (особенно наличие инструментов визуализации) сильно быстрее разбирать, чем сначала писать на каком-нибудь скриптовом языке дампер, а потом переписывать еще раз на «взрослых» C++ / Java, попутно придумывая структуры, в которые это в памяти все разложить.

GreyCat ★★ ()
Ответ на: комментарий от GreyCat

Вот даже что, мне важна именно однозначность соответствия бинарного формата, формальному описанию на языке Kaitai Struct. Чтобы соответствие оставалось точно таким-же в будущих релизах. Насколько можно рассчитывать на обратную совместимость такого рода? Стабильность API не критично, в данном случае.

anonymous ()
Ответ на: комментарий от GreyCat

Указатель и размер всегда можно обернуть в какой-нибудь std::istringstream - и вперед.

Лишняя обертка над указателем в памяти и размером.

Можно ли узнать минимальный размер необходимых данных для желаемого типа?

Пока нет и, честно говоря, не очень представляю, зачем это нужно.

Для того, что бы прочитать из файла только минимально необходимый для данного формата набор данных.

andreyu ★★★★★ ()
Ответ на: комментарий от anonymous

Я думаю, что ничего критично уже не сломаем. Я не очень представляю, что должно произойти с проектом, чтобы, скажем, `type: u1` внезапно стало обозначать что-то отличное от «один байт unsigned integer», которое оно обозначает сейчас. В конце концов - у народа, наверное, есть уже несколько сотен .ksy и я не думаю, что ломать что-то в семантике сейчас реально.

Если мы будем делать какие-то глобальные изменения - то скорее всего на границе перехода major версий и в любом случае будут предоставлены какие-то автоматические конвертеры, утилиты, чекеры и т.д. для перехода в новую жизнь.

GreyCat ★★ ()
Ответ на: комментарий от andreyu

Лишняя обертка над указателем в памяти и размером.

Весь C++ - это сплошные обертки. В данном случае, как мне кажется, мы поступаем вполне себе C++ way. Я, собственно, не очень представляю, чтобы в современном C++ голые указатели кто-то использовал.

Для того, что бы прочитать из файла только минимально необходимый для данного формата набор данных.

Интересный вопрос, но для того, чтобы на него ответить, нужно этот самый «минимальный» набор как-то определить, а его .ksy про него сейчас обычно ничего не знает. Например, png-файл с точки зрения .ksy - это набор типизированных чанков и все. .ksy ничего не знает о том, что в валидном png эти чанки должны быть в определенном порядке, повторяться какое-то определенное количество раз и т.д.

Можно в целом подумать о чем-то в этом отношении, но задача не так проста, как кажется на первый взгляд. И я бы ее решал, скорее, со стороны KS - т.е. какая-то специальная директива «минималистичного» парсинга, чтобы только провалидировать файл.

GreyCat ★★ ()
Ответ на: комментарий от GreyCat

Я не очень представляю, что должно произойти с проектом, чтобы, скажем, `type: u1` внезапно стало обозначать что-то отличное от «один байт unsigned integer», которое оно обозначает сейчас.

Спасибо, я тоже думаю, что излишнее беспокойство.

anonymous ()
Ответ на: комментарий от unC0Rr

Надо просто несколько разных генераторов запилить с разными подходами.

Т.е. проделать в разы больше работы при полном отсутствии потребности в поддержке C.

anonymous ()
Ответ на: комментарий от andreyu

Я, прочитав эту новость, сразу подумал о использовании kaitai в своем вьювере.

Тащить Java для сборки приложения на плюсах? Или один раз сгенерировать парсер и никогда больше не запускать генератор?

anonymous ()
Ответ на: комментарий от andreyu

IMHO для парсера на плюсах имеет смысл посмотреть на Ragel. Хотя, он не такой функциональный, конечно.

anonymous ()
Ответ на: комментарий от GreyCat

Оно, собственно, как раз в основном для разбора неизвестных форматов и писалось.

Интересно. А планируется ли сделать что-нибудь для поддержки шифрованных форматов?

buddhist ★★★★★ ()
Ответ на: комментарий от anonymous

Какова вероятность отстрелить себе ногу из-за ошибки в самом Kaitai Struct

нулевая,весь код банален донельзя,чтения по адресу/смещению никак не могут «отстрелить» что либо,физически невозможно

vtq34957 ()
Ответ на: комментарий от anonymous

Или один раз сгенерировать парсер и никогда больше не запускать генератор?

Именно так.

andreyu ★★★★★ ()
Ответ на: комментарий от andreyu

Думать - это одно, а реально использовать - совсем другое.

Linfan ★★★★★ ()
Ответ на: комментарий от GreyCat

В итоге (особенно наличие инструментов визуализации) сильно быстрее разбирать, чем сначала писать на каком-нибудь скриптовом языке дампер, а потом переписывать еще раз...

Писание на KSY не считается? :) Ничем не лучше дампера на скриптовом языке. Кроме того, от разбора формата это не освобождает. Даже если KSY файл наваял кто-то, в потрохах формата все-равно нужно разбираться. Иначе не оттранслируешь во внутреннюю модель своей аппликухи.

В целом, если надо разово обращаться к теме разбора и, особенно, если есть готовый KSY файл, сабж имеет смысл применять.

Если есть потребность в разработке импортеров/экспортеров N-го кол-ва - выгоднее в архитектуре аппликухи предусмотреть возможность визуализации и анализа данных и наваять соотв. фронтенд для этого (благо он не сложный). Потому как в таком случае и парсеры пишутся «по живому», сразу в проект, и контролировать работу аппликухи это позволяет и трансляцию из распарсенного в во внутреннюю модель.

Linfan ★★★★★ ()
Ответ на: комментарий от andreyu

Или один раз сгенерировать парсер и никогда больше не запускать генератор?

Именно так.

Это верно в случае простых и кондовых форматов, разбор которых выполнен на все 100%. На практике, даже простейший BMP может поддерживаться не во всех версиях. И возвращаться придется несколько раз на перегенерацию. А более сложные проприетарные форматы (аля PSD), которые меняются с каждой новой версией - с ними ваще неразлучно жить с KSY файлами.

Linfan ★★★★★ ()
Ответ на: комментарий от vtq34957

нулевая,весь код банален донельзя,чтения по адресу/смещению никак не могут «отстрелить» что либо,физически невозможно

Более чем возможно. Любые неясности в Kaitai или в разбираемом формате - изменения в адресах/смещениях и огрести сегфолт или эксепшн как два пальца об асфальт :)

Linfan ★★★★★ ()
Ответ на: комментарий от Linfan

и чем страшен сегфолт?

банально можно подменить любой конфиг в линуксе на бинарный мусор-будет сегфолт

вопрос был не про КАК отстрелить/убить программу

а вероятно ли такое-нет,это не вероятно ибо функции банальны и не повреждают файлы,как и не передают неверных данных(а если данные неверные-будет сегфолт,или исключение для нормальных языков)

vtq34957 ()
Ответ на: комментарий от Linfan

А более сложные проприетарные форматы (аля PSD), которые меняются с каждой новой версией - с ними ваще неразлучно жить с KSY файлами.

все верно

вот так-добавляют по полю в начало структуры каждую новую версию PSD(к примеру) и ты просто добавляешь тожесамое в свой шаблон KSY и генериш либу и работаешь сразу с данными,ибо имена(переменных внутри либы твоей) то старых данных не изменились

либо ты имеешь секас со смещениями в Си и каждый раз при обновлении пересчитываешь ручками все смещения переписываешь структуру меняешь кучу банальных циклов чтения по адресу

выбирай

vtq34957 ()
Ответ на: комментарий от Linfan

дытэктор мышкоюзера зашкалил

кто вас пустил писать код?

vtq34957 ()
Ответ на: комментарий от Linfan

Писание на KSY не считается? :) Ничем не лучше дампера на скриптовом языке.

По-моему - лучше. Собственно, весь KS и вырос ровно из того, что мне надоело в пятнадцатый раз писать примерно одно и то же в дампере, еще и зная, что весь этот код придется выкинуть, а после этого еще писать совершенно скучную документацию и рисовать таблички для сотрудников, а потом еще и написать все то же самое на C++.

Там, где на скриптовом языке надо писать по 2-3 длинных строчки, вставляя кучу отладки, на KS достаточно зачастую одной. Отладку и дампинг вставлять тоже не нужно, визуализатор покажет все в разы удобнее, чем может весьма коряво отобразить дампер.

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

А потом в один прекрасный момент все съезжает на один байт и начинается обвешивание этого решения тучей отладки, здесь вывести смещение, здесь подампить сколько-то в hex, здесь еще какие-то условные обозначения придумаем, чтобы в этом потоке на несколько мегабайт что-то глазами можно было найти - и пошло-поехало.

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

GreyCat ★★ ()
Ответ на: А почему си забыли? от anonymous

Таки-нинужна. Сишники описывают структуры сразу на С и на морочат себе голову парсерами.

segfault ★★★★★ ()
Ответ на: комментарий от Linfan

BTW в разборе WMF лучше на MSDN ссылаться:

Спасибо, сошлемся. У нас скоро будет еще специальное поле doc-ref - как раз, чтобы ссылаться.

И имена WMF Records лучше в оригинальном camelcase как в MSDN, ИМХО.

Вот это уже сложно, хотя бы потому, что далеко не во всех языках их можно оставить такими. Поэтому мы стараемся заранее всех запихнуть в весьма строгие рамки, чтобы было проще транслировать в естественные для языка традиции.

GreyCat ★★ ()
Ответ на: комментарий от GreyCat

На самом деле истина где-то посередине. Я вполне понимаю, что когда работаешь с графическими форматами - зачастую что-то (координаты, например) удобно сразу в приложении смотреть.

Как я уже указывал выше, для отладки мы используем отдельное приложение (https://sk1project.net/viewpage.php?page_id=23), которое очень похоже по функционалу на визуализатор KSY. А контроль результата в векторном редакторе - это уже конечная валидация.

Linfan ★★★★★ ()
Ответ на: комментарий от segfault

Таки-нинужна. Сишники описывают структуры сразу на С и на морочат себе голову парсерами.

все врерно,на 1 курсе института так и делают,а что дальше?

они начинают писать на джаваскрипте?

vtq34957 ()
Ответ на: комментарий от segfault

Таки-нинужна. Сишники описывают структуры сразу на С и на морочат себе голову парсерами.

Ога. А потом огребают проблемы с endianness, byte alignment, #pragma pack, сегфолты и непонятно откуда-то взявшиеся тормоза при обращении к структуре.

GreyCat ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.