Pull to refresh

Comments 29

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

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

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

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

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

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

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

(Кстати, окромя protojs, ещё и protobuf есть для той же цели под Node, оказывается.)
Ну тогда это просто разные инструменты, извиняюсь.
Он, между прочим, первый в выдаче яндекса и гугла.
Верно. Я просто не был уверен, что речь именно об этом продукте.
Давно мучаюсь проблемой (как только начал писать на node.js) о том, как на node.js распарсить текстовый файл конфигурации с записями типа ключ=«значение». Понимаю что задача тривиальная. Но, видимо, из-за ее тривиальности ее решение нигде не могу найти. Может кто в курсе?
Ой, какие мы крутые! Вы думаете что только вы умеете пользоваться гуглем? Естественно я его перерыл насколько мог. Может быть смог плохо, но все что смог сделал. Поэтому и спрашиваю.
Тем не менее, хотя там в результатах и выдается парсинг ini файлов — НЕ то, что мне нужно, спасибо за наводку. Как минимум, могу использовать исходный код парсера ini как пример того, как нужно парсить текстовые файлы.
Вы описали что ищите парсер ini, но вам нужны было другое? Ну что же :)
Я написал про «текстовый файл конфигурации с записями типа ключ=«значение»». Насколько я знаю, ini-файл, это немного другое. Там еще и секции есть. У меня нет.

Задачи похожие, поэтому использую iniparser как пример для своего парсера.
Неужели у этой штуки нет ни каких минусов? Кто на практике использовал, и какие подводные камни возникают?
UFO just landed and posted this here
Развлекся — переписал 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}.
Ну сравнения нельзя назвать корректным в контексте топика. Маханизм матчинга в эрланг просто создан для работы с двоичными структурами. В JS подобных задач по сути не возникало, поэтому это технологии разных калибров.
Ну, коммент с эрланговским кодом я написал чтобы подтвердить, что библиотека из первого коммента, вероятно, лучше подходит для парсинга бинарных данных и на нее тоже стоит обратить внимание.

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

Articles