jParser: анализ двоичных файлов работает просто

[Mithgol]

Комментарий переводчика:  перед вами — перевод документации (README на Гитхабе), описывающей ту самую библиотеку jParser (действующую на основе jDataView того же автора), которая употребляется для чтения BMP во блогозаписи у RReverser.

[jrip]

Когда читал оригинал пропустил важный раздел «предосторожности», теперь понял причину возникших проблем :)
Спасибо за перевод.

[vmuha]

Спасибо за статью! Проэксперементируем.

[Sannis]

Использовал для написания парсера node-strtok, рекомендую.

[Oblitus]

А чем это лучше protojs?

[Mithgol]

Какого protojs?

На свете много продуктов, носящих это имя.

[Oblitus]

Этого, который реализация protocol buffer.

[Mithgol]

Читал и пытался понять, способна ли эта штука читать произвольные структуры двоичных данных.

Честно говоря, не понял.

Может быть, Вы расскажете поподробнее?

[Mithgol]

Случайно тег не закрыл (надавил кнопку «Написать» раньше времени), так что текст стал весь подчёркнутым и читается много хуже.

Повторю суть в двух словах: я не понял, как jParser и https://github.com/sirikata/protojs можно сравнивать по принципу «лучше / хуже» — в чём они аналогичны, разве делают они одну и ту же работу?

Возможно, в моём непонимании свою роль сыграла недостаточная подробность документации к protojs.

[Oblitus]

Это реализвция гугловского Protocol Buffers для компактного хранения и передачи структурированных данных с минимумом оверхеда.

Похоже, я не уловил назначения сабжа. Это только парсер, обратной операции не подразумевается?

[Mithgol]

Да, только парсер.

Кажется, jParser способен анализировать (парсить) данные более сложной структуры, чем Protocol Buffers, и тем он лучше.

С другой стороны, если речь идёт не о чтении существующих структур, а просто о двоичной передаче данных, то Protocol Buffers попривлекательнее, ибо не только читать умеет.

(Кстати, окромя protojs, ещё и protobuf есть для той же цели под Node, оказывается.)

[Oblitus]

Ну тогда это просто разные инструменты, извиняюсь.

[Oblitus]

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

[Mithgol]

Верно. Я просто не был уверен, что речь именно об этом продукте.

[donnerjack13589]

Спасибо за перевод README

[UncleAndy]

Давно мучаюсь проблемой (как только начал писать на node.js) о том, как на node.js распарсить текстовый файл конфигурации с записями типа ключ=«значение». Понимаю что задача тривиальная. Но, видимо, из-за ее тривиальности ее решение нигде не могу найти. Может кто в курсе?

[Sannis]

В курсе.

[UncleAndy]

Ой, какие мы крутые! Вы думаете что только вы умеете пользоваться гуглем? Естественно я его перерыл насколько мог. Может быть смог плохо, но все что смог сделал. Поэтому и спрашиваю.

[UncleAndy]

Тем не менее, хотя там в результатах и выдается парсинг ini файлов — НЕ то, что мне нужно, спасибо за наводку. Как минимум, могу использовать исходный код парсера ini как пример того, как нужно парсить текстовые файлы.

[Sannis]

Вы описали что ищите парсер ini, но вам нужны было другое? Ну что же :)

[UncleAndy]

Я написал про «текстовый файл конфигурации с записями типа ключ=«значение»». Насколько я знаю, ini-файл, это немного другое. Там еще и секции есть. У меня нет.

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

[Mithgol]

Позвольте порекомендовать Вам тысяча пятьдесят третий комикс xkcd.

[alekciy]

Неужели у этой штуки нет ни каких минусов? Кто на практике использовал, и какие подводные камни возникают?

[Mithgol]

Я использовал, вон там изложил итоги.

[seriyPS]

github.com/squaremo/bitsyntax-js — шаг на светлую сторону силы)
Без использования недокументированных возможностей!!!

[seriyPS]

Развлекся — переписал ico-парсер из примеров с JS на Erlang, получилось 57 строк против 69 на JS.
В принципе, можно до 44-х сократить.
И тут не используются внешние библиотеки — все встроенное.

-module(parse_ico).
-export([parse_ico/1]).

parse_ico(FileName) ->
	{ok, File} = file:read_file(FileName),
	<<Reserved:16/unsigned-integer-little,
	Type:16/unsigned-integer-little,
	ImageCount:16/unsigned-integer-little,
	Images/binary>> = File,
	{{header,
	  {reserved, Reserved},
	  {type, Type},
	  {image_count, ImageCount}},
	 {images, parse_images(Images, ImageCount, [])}}.

parse_images(_, 0, Result) ->
	Result;
parse_images(ImagesBin, ImageCount, Result) ->
	<<Width,
	Height,
	PaletteCount,
	Reserved,
	ColorPlanes:16/unsigned-integer-little,
	BitsPerPixel:16/unsigned-integer-little,
	Size:32/unsigned-integer-little,
	Offset:32/unsigned-integer-little,
	Content/binary>> = ImagesBin,
	{ok, Palette, PixelsBin} = parse_palette(Content, PaletteCount, []),
	{ok, Pixels, NextImgBin} = parse_pixels(PixelsBin, BitsPerPixel, Width, Height),
	Image = {
	  {width, Width},
	  {height, Height},
	  {palette_count, PaletteCount},
	  {reserved, Reserved},
	  {color_planes, ColorPlanes},
	  {bits_per_pixel, BitsPerPixel},
	  {size, Size},
	  {offset, Offset},
	  {content, {
		{palette, Palette},
		{pixels, Pixels}}}},
	parse_images(NextImgBin, ImageCount -1, [Image | Result]).


parse_palette(Binary, 0, Result) ->
    {ok, lists:reverse(Result), Binary};
parse_palette(<<R, G, B, A, Rest/binary>>, Count, Result) ->
    parse_palette(Rest, Count - 1, [{R, G, B, A} | Result]).

parse_pixels(PixelsBin, BitsPerPixel, Width, Height) ->
	CurImageSize = trunc(BitsPerPixel * Width * Height / 8),
	CurRowSize = trunc(BitsPerPixel * Width / 8),
	<<MyPixels:CurImageSize/binary, NextImgBin/binary>> = PixelsBin,
	Pixels = [lists:flatten([[Px2, Px1]
							 || <<Px1:BitsPerPixel, Px2:BitsPerPixel>> <= Row])
			  || <<Row:CurRowSize/binary>> <= MyPixels],
	{ok, Pixels, NextImgBin}.

[alekciy]

Ну сравнения нельзя назвать корректным в контексте топика. Маханизм матчинга в эрланг просто создан для работы с двоичными структурами. В JS подобных задач по сути не возникало, поэтому это технологии разных калибров.

[seriyPS]

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

В дополнение, совершенно не понятно как библиотека из топика относится к «big-endian vs little-endian».