компактное двоичное представление json

Question

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

ЯВы ищете максимально компактный формат, желательно какой-нибудь открытый стандарт?

Answer 1

Вы можете взглянуть на Универсальную двоичную спецификацию JSON . Он не будет таким компактным, как Smile, потому что он не делает ссылок на имена, но он на 100% совместим с JSON (где BSON и BJSON определяют структуры данных, которые не существуют в JSON, поэтому стандартного преобразования в / нет от).

Также (преднамеренно) преступно просто читать и писать в стандартном формате:

[type, 1-byte char]([length, 4-byte int32])([data])

Таким образом, простые типы данных начинаются с кода маркера ASCII, такого как «I» для 32-разрядного целого, «T» для истинного значения, «Z» для нулевого значения, «S» для строкового значения и т. Д.

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

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

[S][512][this is a really long 512-byte UTF-8 string....]

Вы увидите 'S', включите его для обработки строки, увидите 4-байтовое целое число, следующее за ним, равное "512", и знаете, что вы можете просто захватить в один блок следующие 512 байтов и декодировать их обратно. в строку.

Точно так же числовые значения записываются без значения длины, чтобы быть более компактными, поскольку их тип (byte, int32, int64, double) определяет их длину в байтах (1, 4, 8 и 8. соответственно). Также существует поддержка произвольно длинные числа, которые чрезвычайно портативны, даже на платформах, которые их не поддерживают).

В среднем вы должны увидеть уменьшение размера примерно на 30% с хорошо сбалансированным объектом JSON (много смешанных типов). Если вы хотите точно знать, как определенные структуры сжимаются или не сжимаются, вы можете ознакомиться с разделом Требования к размеру , чтобы получить представление.

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

Я проверил ядро ​​ Реализации Input / OutputStream для чтения / записи формата в GitHub сегодня. Позднее на этой неделе я проверю общее отображение объектов на основе отражения.

Вы можете просто посмотреть на эти два класса, чтобы увидеть, как читать и писать формат, я думаю, что основная логика - это что-то вроде 20 строк кода. Классы длиннее из-за абстракций к методам и некоторой структуризации вокруг проверки байтов маркера, чтобы убедиться, что файл данных является допустимым форматом; такие вещи.

Если у вас есть действительно конкретные вопросы, такие как порядковый номер (Большой) спецификации или числовой формат для двойных чисел (IEEE 754), все это описано в спецификации документа или просто задайте мне вопрос.

Надеюсь, это поможет!

Answer 2

Да: Smile формат данных (см. Запись в Википедии . Он имеет общедоступную реализацию Java, версия C в работах на github (libsmile). Его преимущество в том, что он более компактен, чемJSON (надежно), но он на 100% совместим с логической моделью данных, поэтому его легко и просто конвертировать с текстовым JSON.

Для повышения производительности вы можете увидеть jvm-serializer бенчмарк, где smile хорошо конкурирует с другими двоичными форматами (thrift, avro, protobuf), поэтому он не самый компактный (поскольку он сохраняет имена полей), но гораздо лучше работает с потоками данных, имена которых повторяются.

Он используется в таких проектах, как Elastic Search и Solr (опционально), Protostuff-rpc поддерживает его, хотя и не так широко, как, скажем, Thrift или protobuf. * ​​1011 *

EDIT (декабрь 2011) - естьтеперь также libsmile привязки для PHP, Ruby и Python, поэтому улучшается поддержка языка. Кроме того, есть измерения размера данных, и хотя для одиночной записиальтернативы данных (Avro, protobuf) более компактны для потоков данных Smile часто более компактны благодаря опции обратной ссылки на ключ и строковое значение.

Answer 3

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

Если ваши данные имеют дополнительные ограничения(например, множество избыточных значений полей), вы можете оптимизировать, взглянув на другой протокол сериализации, а не придерживаясь JSON.Пример: сериализация на основе столбцов, такая как предстоящее столбцовое хранилище Avro , может дать вам лучшие коэффициенты (для хранения на диске).Если ваши полезные данные содержат много постоянных значений (например, столбцы, представляющие перечисления), может быть также полезен подход сжатия словаря.

Answer 4

Другой альтернативой, которая должна рассматриваться в наши дни, является CBOR (RFC 7049) , которая имеет явно JSON-совместимую модель с большой гибкостью.Он стабилен и соответствует вашей квалификации открытого стандарта, и, очевидно, в него было вложено много мыслей.

Answer 5

Вы пробовали BJSON ?

Answer 6

Попробуйте использовать js-inflate, чтобы создавать и разбирать капли.

https://github.com/augustl/js-inflate

Это идеально, и я использую много.