Universal Binary Json — Еще Один Двоичный Json.

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

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

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

Для достижения лучших результатов в таких случаях становится полезным использовать двоичный формат. JSON .

Использование внутренних типов данных, уникальных для двоичных форматов и изначально не включенных в стандарт. JSON , делает приведенные выше спецификации непригодными для широкого использования, поскольку в зависимости от реализации каждый такой тип может интерпретироваться по-разному.

Сложность реализации .

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

Что, в свою очередь, замедляет или делает невозможным их распространение и реализацию.

Простота использования – двигатель успеха JSON .

Например, БСОН определяет типы данных для регулярных выражений, блоков кода JavaScript и других конструкций, которые не имеют соответствующего типа данных в JSON .

БЖСОН также определяет свои собственные типы данных, оставляя достаточно места для ошибок, связанных с интерпретацией типов в двух разных реализациях.

Улыбка определяет более сложные типы данных, правила генерации и анализа для эффективного использования пространства.

Все существующие двоичные спецификации JSON страдают от проблем несовместимости и сложности реализации, что, естественно, уничтожает главное преимущество JSON Что сделало его таким популярным, так это его простота.

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

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

Чтение и запись в этом формате тривиальны.

В качестве побочного эффекта пространство, занимаемое данными, сокращается в среднем на 30%.

длина (необязательный) — 1 или 4 байта (целое значение) в зависимости от длины или размера объекта.

Для массива — его длина.

Для объекта количество пар ключ/значение.

Если длина или количество элементов от 0 до 254 включительно, то используется 1 байт. Это поле со значением 255 зарезервировано для объектов и массивов неизвестной длины.

данные (необязательный) — последовательность байтов, которая непосредственно представляет данные объекта.

Поля длина И данные используются или не используются в зависимости от типа данных.

Например, 32-битный целочисленный тип имеет стандартный размер 4 байта.

Для записи значения этого типа понадобится 1 байт для указания типа и 4 байта для самого значения.

В этом случае поле длина не использовался по причине ненадобности.

Благодаря такому подаче информации поставленные цели достигаются.

NET Реализации на других языках программирования будут доступны по мере их появления.

перейдите по этой ссылке .

P.S.: Автор спецификации и реализации на Java, Рияд Калла и я, автор статьи и реализации на C#, буду рад любому вашему участию в процессе работы над спецификацией.