LINUX.ORG.RU

Запущен сайт-каталог формальных спецификаций форматов файлов и сетевых протоколов

 , ,


11

3

На базе проекта Kaitai Struct запущен сайт-каталог, собирающий информацию о всевозможных форматах файлов и сетевых протоколах.

В отличие от других подобных сайтов (например, fileformat.info, wiki.osdev.org и т. п.), в основе сайта лежит репозиторий формальных спецификаций, описываемых форматов на языке Kaitai Struct. Такое описание, в отличие от описания простым текстом или диаграммами, позволяет сразу автоматически генерировать:

  • таблицы и диаграммы для облегчения понимания сути форматов разработчиком;
  • единообразный API для описываемых структур данных;
  • готовые парсеры форматов на многих языках программирования (на данный момент поддерживается C++, C#, Java, JavaScript, Perl, PHP, Python, Ruby, на начальном уровне реализована поддержка Go).

На момент запуска в репозитории описаны 79 форматов, включая популярные форматы изображений (gif, png, jpeg и т. п.), видео (avi, mp4), исполняемых файлов (DOS MZ, Windows PE, ELF, Mach-0), баз данных, файловых систем (VFAT, ext2, iso9660, cramfs и т. д.).

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

★★

Проверено: anonymous_incognito ()
Последнее исправление: sudopacman (всего исправлений: 3)

Ответ на: комментарий от frob

Ну, тут вопрос совершенно утилитарный: можно ли там чего-то еще разобрать или нет. Если бы там был, скажем, BSON или EBML - то нет. Если там RIFF или CFB - то да, и смысл делать поддержку всяких бинарных структур которые еще будут встречаться внутри - есть.

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

Что-то я запутался, может из-за несоответствия комментария комментируемому =)

CFB — это файловая система в файле. С некоторым «стандартным» вариантом хранения метаданных типа автора, даты создания документа, превьюшки и тому подобного. В принципе в MS вполне могли бы вместо CFB использовать ZIP, что в общем-то и произошло при переходе на MOOX.

Внутри бинарных форматов MS, помимо внедрённых внешних «ресурсов» (картинки всякие и прочее), нет ничего полезного с точки зрения повторного использования добавленной поддержки. Не-MS-овские форматы внешних ресурсов имеет смысл добавлять сами по себе, а не в контексте «встроен в файл MSO». Некоторые из встраиваемых MS-овских «вспомогательных» форматов как-то используются вне MSO, например WMF/EMF. Какие-то вроде вообще за пределы MSO не выходят (Escher).

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

Наверняка авторам либры и опенофиса. Они же до сих пор не могут сделать корректный разбор и генерацию формата.

Xintrea ★★★★★
()

Ой как хорошо, красота, всегда мечтал что бы где то централизоанно и удобно что-то описывалось, красота, молодцы!

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

Наверняка авторам либры и опенофиса. Они же до сих пор не могут сделать корректный разбор и генерацию формата.

Опенофис мёртв. ЛО не будет завязываться на Кайтай. Переписывать свой разбор в транслятор из кайтая в своё внутреннее представление никто не будет. В том числе потому, что разбор формата в какие-либо структуры — это О-малое от того, что с файлом надо сделать. Аналогично с Калигрой и Скрибусом.

frob ★★★★★
()

Добавьте OBJ формат (да, вместе с MTL файлами, которые как правило, используются вместе с ним) - студенты (да и некоторые начинающие разработчики) будут рады. И вообще не нашел форматов 3d графики. Описаний этого формата в сети - куча, как и вариаций, но хватит базовой. И да, формальное описание хорошо, но какого-нибудь вики по формату не хватает для некоторых форматов.

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от atsym

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

И да, прибалдел, что оно в мультимедии. Для 3D графики (тем более статичной) отдельная категория нужна.

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 2)
Ответ на: комментарий от peregrine

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

Если кто-нибудь сделает и пришлет - добавим. Из того, что я пока поверхностно увидел .obj - он вообще текстовый, поэтому я не очень понимаю, чем там поможет KS.

И вообще не нашел форматов 3d графики.

Есть STL, есть 3DS, в игрушках есть туча форматов специфичных для игровых движков (движков Quake / Quake 2 / GTA).

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

Не очень понял, о чем речь?

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

Текстовые форматы парсить KS можно, но почти бессмысленно (не говоря о том, что скорее всего весьма неэффективно). Собственно, весь KS как раз и посвящен тому, чтобы отлаживать работу с бинарными форматами было удобно и везде было видно, что и где в файле.

Для 3D графики (тем более статичной) отдельная категория нужна.

Наверное, да, хорошо бы...

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

Не очень понял, о чем речь?

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

.obj - он вообще текстовый

Он как и STL бывает текстовый, а бывает бинарный. Бинарный обычно имеет .mod расширение.

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

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

В теории для этого есть `doc` и возможность написать пояснения на человекочитаемом языке. Она же автоматом будет доступна в IDE любого языка (т.к. сконвертируется в docstrings). Возможно, в png.ksy ее просто не написали :(

Так что неплохо иметь ссылку на вики или на саму текстовую спеку, где это описывается.

Это тоже есть (ну или по крайней мере должно быть) - ссылки на документ-оригинал, из которого взято то или иное тайное знание - это doc-ref.

Он как и STL бывает текстовый, а бывает бинарный.

Честно говоря, ни разу не встречал, хотя я, конечно, не показатель. В общем, посмотрим - будет желание - кто-нибудь сделает ;)

GreyCat ★★
() автор топика

Жаль ASN.1 практически ничего нет, но начинание безусловно хорошее. Ещё бы запилили автоматичнское сравнение с теми же fileformat.info, wiki.osdev.org - чтобы было видно какой процент покрыт и всё такое в качестве дополнительной мотивации сообщдеству «догнать и перегнать».

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

Ещё бы запилили автоматичнское сравнение с теми же fileformat.info, wiki.osdev.org

С ними тяжело сравниваться по ряду причин.

fileformat.info - в первую очередь новостной сайт, во вторую - энциклопедия форматов. В их подборке сейчас якобы 573 формата, но большой вопрос, что именно называть форматом и что они хранят. Если начинаешь копать - оказывается, что они выкладывают примерно любые тексты, которые когда-либо где-либо нашли, без особой оглядки на лицензии. Если есть возможность залинковать официальную спецификацию - линкуют. Большинство описаний из тех, что хранятся именно на сайте, взяты из небезызвестной книги O'Reilly «Encyclopedia of Graphics File Formats» - но она, соответственно, выходила в 1996 году и, понятно, что дико устарела.

wiki.osdev.org - это именно wiki и именно посвященная разработке ядер операционных систем; это означает, что там будет много информации о глубокосистемных вещах типа форматов загрузчиков, executables, всевозможных библиотек и объектных файлов, много информации о сетевых протоколах, файловых системах и всяких аппаратных штуках (memory maps и т.п.). А вот, например, банально о GIF-файле или о каком-нибудь .zip там уже не прочитаешь: им это не нужно. По этой же причине посчитать количество форматов на wiki.osdev.org не представляется возможным: даже если опираться на категории вроде Executable Formats, довольно быстро окажется, что у них в эти категории кроме собственно форматов, попадают еще и описания ABI и calling conventions.

Тем не менее, мы хотим сделать всяческую интероперабельность, начав с механизма а ля interwiki. Скорее всего в ksy-файле будут появляться ссылки на всевозможные места, где этот формат еще описан.

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

Мерси за подробный ответ. Прикольно, кстати - не знал что Kismet вас использует.

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

Не ожидал, что я буду на HTTPS жаловаться? А я буду!

На самом деле, поэтому, в том числе, strace.io с гитхабного хостинга съехал.

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