CBOR — новый бинарный формат представления данных

[zloyreznic]

Есть еще не плохой protobuf от google

[zxcabs]

Протобуф требует схему описания данных, а тут нет. И это было одним из требований.

[seregamorph]

При всех своих достоинствах это достаточно тяжеловесное решение, объем генерированных классов (например, Java) довольно громоздкий + либа весом 666667 байт, в малоресурсных системах вроде j2me практически неприменимо несмотря даже на наличие портов.

[A_J]

Интересно.
Надо было им для сравнения компактности еще добавить ASN.1 PER.

[amarao]

Устранение Фатального Недостатка?

[aleks_raiden]

Очень даже интересно, исследую как раз Google Protocol Buffer, но все преимущества этого мне как раз очень даже. Дело за малым — кроссбарузерная клиентская реализация (как ProtoBuff.js) и библиотеки для РНР и Node.JS

[Holms]

… множество других (правда, бегло поискав на github, я пока не нашёл реализации на JavaScript...).

здесь есть и JavaScript.

[cruxacrux]

О, действительно. Спасибо.
Правда там указано, что

The Java and JavaScript versions are translations from the C# version

Наверняка кто-нибудь решит сделать с нуля в «натуральном» виде.

[mynameco]

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

[bak]

Всё нормально. Если вы хотите хранить кучу строк — вам же всё равно длину строк надо знать. Для мелких строк размер будет кодироваться прямо в том-же байте, что и префикс. Если кучу мелких чисел — они тоже будут влезать в этот 1 байт. Числа покрупнее будут занимать уже чуть больше байт, но всё равно скорее всего лучше чем оригиналы. Конечно не хаффман но тоже неплохо.

[bak]

Хотя если вы храните толпу char-ов в районе ~240 — использовать на это по два байта конечно не прикольно…

[int19h]

Байтовые строки же.

[qw1]

Это общая беда всех кодировщиков. На любую схему кодирования найдётся другая, которая на некоторых данных будет лучше.

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

upd: опередили ))

[cruxacrux]

Более того, уже есть расширение, которое позволят кодировать повторяющиеся строки ссылками. Это позволяет получить ещё более компактное представление, если у вас огромный массив одинаковых объектов:

  [
     {
       "name" : "Cocktail",
       "count" : 417,
       "rank" : 4
     },
     {
       "rank" : 4,
       "count" : 312,
       "name" : "Bath"
     },
     {
       "count" : 691,
       "name" : "Food",
       "rank" : 4
     }
  ]

Начиная со второго объекта, ключи кодируются как ссылки на строки и занимают 3 байта.

[mynameco]

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

[Rulexec]

Дурововский TL не имеет такой проблемы, можно сделать большой массив float'ов.

Будет лишь оверхед в 8 байт (4 байта на тип, 4 байта на кол-во элементов).

[mynameco]

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

[sith]

А если в табличке сравнить [24, [24, 34]]?

[MichaelBorisov]

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

[cruxacrux]

Разные форматы имеют разные цели. Если нужна метаинформация о количестве элементов, то можно создать своё расширение к CBOR: выбрать свободный номер тега и создать простую структуру из базовых типов, в которой описать всю нужную метаинформацию. Кодировщик после прохода по данным сосчитает число элементов и запишет информацию в теге в конец или начало кодированных данных. Т.о. декодировщик сможет затем извлечь нужную информацию о данных не загружая весь объём данных.

[hack2root]

Concise Binary Object Representation (сжатое бинарное представление объекта) — формат данных, который был спроектирован таким образом, чтобы обеспечить максимально простой код реализации, формирования компактных выходных данных и возможность расширения формата без необходимости обмена информацией о версии.

[nnseva]

1. Потоковый парсер позволит не грузить в память ничего, кроме текущего значения. Потоковый парсер для этого формата возможен.
2. Это же не СУБД и не файловая система, чтобы иметь произвольный доступ к элементам. Произвольный доступ — довольно тяжелое в реализации требование, подтверждением служит многообразие упомянутых систем.

[nuclight]

Откуда на constrained-устройстве, например датчике температуры из IoT, файлы? Вообще абсолютно другая задача. Еще от JSON потребуйте свойств базы данных (а HDF5 как бы не посложнее SQLite'а был, как минимум в собственно форматной части так уж точно, спека огромная)

[NeoCode]

Хорошо. Про текстовые форматы (типа xml и json) знают все, а бинарные к сожалению не так широко известны (я например знал лишь то что они существуют, но ни разу с ними не сталкивался ни как программист, ни как пользователь).

[hack2root]

Во всех играх используются повсеместно, DOOM, Quake, половина форматов хранения 3D массива данных, практически все ГИС используют свой кастомный внутренний бинарный фрпмат хранения данных, треки GPS так же могут записываться в бинарном формате, фактически зесь описан именно codec — формат хранения данных для передачи, с последующим его получением и декодированием.

[NeoCode]

В том-то и дело, что «свой кастомный внутренний бинарный формат хранения данных». Я тоже такой могу придумать и придумывал неоднократно.
А хочется, чтобы был некий универсальный и повсеместно распространенный формат, библиотеки для работы с ним в большинстве языков программирования, софт для просмотра и редактирования этих данных и т.д. Как с XML.

[nuclight]

Ну, в общем-то, теперь CBOR действительно именно таков.

[palexisru]

были у меня идеи, когда положительная и отрицательная бесконечность кодируется 0x7F и 0x81, а NAN — 0x80. Но, видимо, до этого еще далеко. Хоть логика учтена.

[int19h]

А зачем? Разве они так часто встречаются, чтобы кодировать их одним байтом?

[speakingfish]

В NaN есть еще целочисленная диагностическая информация (payload). Изредка она используется.

[nuclight]

Это как у https://sqlite.org/src4/doc/trunk/www/key_encoding.wiki что ли?

[antarx]

Чем это принципиально лучше msgpack'а, помимо фатального недостатка?

[cruxacrux]

Msgpack изначально не делал различия между байтовыми строками и текстовыми. Можно вспомнить жаркую дискуссию по этому поводу. С проблемой столкнулись ещё в 2011 году. Основная проблема с изменением была связана с тем, что модификация формата приведёт к потере обратной совместимости, т.е. спецификация затрудняла дальнейшие развитие формата. CBOR предусматривает возможность для развития без потери обратной совместимости.
Второе менее значимое отличие — это поддержка массивов/строк неопределённой длины.

[Vapaamies]

На саму концепцию строк неопределенной длины у меня нет слов. Цензурных.

Ну, JSON, ну ладно. Но двоичный-то формат всегда программа пишет! Уж программе-то размер должен быть известен, раз она память под него выделила! Не понимаю.

[roman_kashitsyn]

программе-то размер должен быть известен, раз она память под него выделила!

Если она из сокета данные читает, откуда ей размер знать? Даже в http Content-Length не всегда указан.
Заранее известный размер всегда предпочтительнее, но он, к сожалению, далеко не всегда доступен энкодеру.

[Vapaamies]

Ну да, ну да. Сначала не делаем Content-length обязательным, а потом жалуемся, что размер неизвестен. А потом и в двоичных форматах.

[qw1]

Посмотрим на тот же хабр: имя юзера сверху, новостные блоки, реклама, комментарии. Длина страницы заранее неизвестна.
Разве что не сразу в сокет её посылать, а сначала в буфер. Но так пользователю дольше ждать. Сейчас статья видна до загрузки комментариев.

[Vapaamies]

Речь про длину строки, а не всего содержимого. Длина имени пользователя, заголовка новости и текста комментария уже известны серверу на момент отправки.

Страницу целиком вполне можно рассматривать как набор кадров потокового вещания, тут я не спорю.

[qw1]

Речь о Content-Length в HTTP

[nuclight]

Любой стриминг же, ну. Генерация... Длина заранее неизвестна. Для буферизации может не быть места, особенно в constrained-системах (IoT), для которых и создавался CBOR.