Comments 29
Комментарий переводчика: перед вами — перевод документации (README на Гитхабе), описывающей ту самую библиотеку jParser (действующую на основе jDataView того же автора), которая употребляется для чтения BMP во блогозаписи у RReverser.
+2
Когда читал оригинал пропустил важный раздел «предосторожности», теперь понял причину возникших проблем :)
Спасибо за перевод.
Спасибо за перевод.
0
Спасибо за статью! Проэксперементируем.
+1
Использовал для написания парсера node-strtok, рекомендую.
0
А чем это лучше protojs?
-1
Какого protojs?
На свете много продуктов, носящих это имя.
На свете много продуктов, носящих это имя.
0
Случайно тег не закрыл (надавил кнопку «Написать» раньше времени), так что текст стал весь подчёркнутым и читается много хуже.
Повторю суть в двух словах: я не понял, как jParserи https://github.com/sirikata/protojs можно сравнивать по принципу «лучше / хуже» — в чём они аналогичны, разве делают они одну и ту же работу?
Возможно, в моём непонимании свою роль сыграла недостаточная подробность документациик protojs.
Повторю суть в двух словах: я не понял, как jParser
Возможно, в моём непонимании свою роль сыграла недостаточная подробность документации
0
Это реализвция гугловского Protocol Buffers для компактного хранения и передачи структурированных данных с минимумом оверхеда.
Похоже, я не уловил назначения сабжа. Это только парсер, обратной операции не подразумевается?
Похоже, я не уловил назначения сабжа. Это только парсер, обратной операции не подразумевается?
0
Да, только парсер.
Кажется, jParser способен анализировать (парсить) данные более сложной структуры, чем Protocol Buffers, и тем он лучше.
С другой стороны, если речь идёт не о чтении существующих структур, а просто о двоичной передаче данных, то Protocol Buffers попривлекательнее, ибо не только читать умеет.
(Кстати, окромя protojs,ещё и protobuf есть для той же цели под Node, оказывается.)
Кажется, jParser способен анализировать (парсить) данные более сложной структуры, чем Protocol Buffers, и тем он лучше.
С другой стороны, если речь идёт не о чтении существующих структур, а просто о двоичной передаче данных, то Protocol Buffers попривлекательнее, ибо не только читать умеет.
(Кстати, окромя protojs,
0
Он, между прочим, первый в выдаче яндекса и гугла.
0
Спасибо за перевод README
0
Давно мучаюсь проблемой (как только начал писать на node.js) о том, как на node.js распарсить текстовый файл конфигурации с записями типа ключ=«значение». Понимаю что задача тривиальная. Но, видимо, из-за ее тривиальности ее решение нигде не могу найти. Может кто в курсе?
0
Ой, какие мы крутые! Вы думаете что только вы умеете пользоваться гуглем? Естественно я его перерыл насколько мог. Может быть смог плохо, но все что смог сделал. Поэтому и спрашиваю.
-1
Тем не менее, хотя там в результатах и выдается парсинг ini файлов — НЕ то, что мне нужно, спасибо за наводку. Как минимум, могу использовать исходный код парсера ini как пример того, как нужно парсить текстовые файлы.
-1
Вы описали что ищите парсер ini, но вам нужны было другое? Ну что же :)
0
Я написал про «текстовый файл конфигурации с записями типа ключ=«значение»». Насколько я знаю, ini-файл, это немного другое. Там еще и секции есть. У меня нет.
Задачи похожие, поэтому использую iniparser как пример для своего парсера.
Задачи похожие, поэтому использую iniparser как пример для своего парсера.
-1
Позвольте порекомендовать Вам тысяча пятьдесят третий комикс xkcd.
0
Неужели у этой штуки нет ни каких минусов? Кто на практике использовал, и какие подводные камни возникают?
+1
github.com/squaremo/bitsyntax-js — шаг на светлую сторону силы)
Без использования недокументированных возможностей!!!
Без использования недокументированных возможностей!!!
+1
Развлекся — переписал ico-парсер из примеров с JS на Erlang, получилось 57 строк против 69 на JS.
В принципе, можно до 44-х сократить.
И тут не используются внешние библиотеки — все встроенное.
В принципе, можно до 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}.
+1
Ну сравнения нельзя назвать корректным в контексте топика. Маханизм матчинга в эрланг просто создан для работы с двоичными структурами. В JS подобных задач по сути не возникало, поэтому это технологии разных калибров.
+1
Ну, коммент с эрланговским кодом я написал чтобы подтвердить, что библиотека из первого коммента, вероятно, лучше подходит для парсинга бинарных данных и на нее тоже стоит обратить внимание.
В дополнение, совершенно не понятно как библиотека из топика относится к «big-endian vs little-endian».
В дополнение, совершенно не понятно как библиотека из топика относится к «big-endian vs little-endian».
0
Sign up to leave a comment.
jParser: анализ двоичных файлов работает просто