it-roy-ru.com

Двоичные данные в строке JSON. Что-то лучше, чем Base64

Формат JSON изначально не поддерживает двоичные данные. Двоичные данные должны быть экранированы, чтобы их можно было поместить в строковый элемент (т. Е. Ноль или более символов Unicode в двойных кавычках с использованием обратной косой черты) в JSON.

Очевидный способ избежать двоичных данных - использовать Base64. Тем не менее, Base64 имеет большие накладные расходы на обработку. Кроме того, он расширяет 3 байта в 4 символа, что приводит к увеличению размера данных примерно на 33%.

Одним из вариантов использования этого является черновой вариант спецификации API облачного хранилища CDMI v0.8 . Вы создаете объекты данных через REST-Webservice, используя JSON, например,.

PUT /MyContainer/BinaryObject HTTP/1.1
Host: cloud.example.com
Accept: application/vnd.org.snia.cdmi.dataobject+json
Content-Type: application/vnd.org.snia.cdmi.dataobject+json
X-CDMI-Specification-Version: 1.0
{
    "mimetype" : "application/octet-stream",
    "metadata" : [ ],
    "value" :   "TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlz
    IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2Yg
    dGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGlu
    dWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRo
    ZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=",
}

Есть ли лучшие способы и стандартные методы для кодирования двоичных данных в строки JSON?

527
dmeister

Существует 94 символа Unicode, которые могут быть представлены одним байтом в соответствии со спецификацией JSON (если ваш JSON передается как UTF-8). Имея это в виду, я думаю, что лучшее, что вы можете сделать в пространстве - это base85 , который представляет четыре байта как пять символов. Тем не менее, это всего лишь 7% улучшение по сравнению с base64, его вычисление обходится дороже, а реализации встречаются реже, чем для base64, поэтому, вероятно, это не победа.

Вы также можете просто сопоставить каждый входной байт с соответствующим символом в U + 0000-U + 00FF, а затем выполнить минимальное кодирование, требуемое стандартом JSON для передачи этих символов; Преимущество здесь в том, что требуемое декодирование равно нулю по сравнению со встроенными функциями, но эффективность пространства плохая - расширение на 105% (если все входные байты одинаково вероятны) против 25% для base85 или 33% для base64.

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

Смотрите также: Base91

406
hobbs

Я знаю, что это почти 6-летний вопрос, но я столкнулся с той же проблемой и подумал, что поделюсь решением: multipart/form-data.

Отправляя многокомпонентную форму, вы отправляете сначала в виде строки свой метаданные JSON, а затем отдельно отправляете в виде необработанного двоичного файла (изображения (изображений), wavs и т.д.), Проиндексированного именем Content-Disposition ,.

Вот хороший учебник о том, как это сделать в obj-c, и вот статья в блоге , в которой объясняется, как разделить строковые данные с границей формы и отделить их от двоичных данных.

Единственное изменение, которое вам действительно нужно сделать, это на стороне сервера; вам нужно будет захватить ваши метаданные, которые должны соответствующим образом ссылаться на двоичные данные POST (используя границу Content-Disposition). 

Конечно, это требует дополнительной работы на стороне сервера, но если вы отправляете много изображений или больших изображений, это того стоит. Объедините это со сжатием gzip, если хотите.

IMHO отправка данных в кодировке base64 - это взлом; RFC multipart/form-data был создан для таких проблем, как: отправка двоичных данных в сочетании с текстом или метаданными.

207
Ælex

BSON (двоичный JSON) может работать на вас . http://en.wikipedia.org/wiki/BSON

Отредактируйте: FYI .NET-библиотека json.net поддерживает чтение и запись bson, если вы ищете какую-нибудь любовь на C # на стороне сервера.

32
DarcyThomas

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

Как следствие, если для кодирования значения байта в диапазоне [0..127] потребуется только один байт в кодировке UTF-8, для кодирования значения байта в диапазоне [128..255] потребуется 2 байта! Хуже этого. В JSON управляющие символы "и \" не допускаются в строке. Поэтому для правильного кодирования двоичных данных требуется некоторое преобразование. 

Давай посмотрим. Если мы примем равномерно распределенные случайные байтовые значения в наших двоичных данных, то в среднем половина байтов будет закодирована одним байтом, а другая половина - двумя байтами. У двоичных данных в кодировке UTF-8 будет 150% от исходного размера. 

Кодировка Base64 увеличивается только до 133% от исходного размера. Таким образом, кодирование Base64 более эффективно.

Как насчет использования другой базовой кодировки? В UTF-8 кодирование 128 значений ASCII является наиболее экономичным. В 8 битах вы можете хранить 7 бит. Поэтому, если мы разрежем двоичные данные на 7-битные порции, чтобы сохранить их в каждом байте строки в кодировке UTF-8, кодированные данные вырастут только до 114% от исходного размера. Лучше, чем Base64. К сожалению, мы не можем использовать этот простой трюк, потому что JSON не допускает некоторые ASCII символы. 33 управляющих символа ASCII ([0..31] и 127) и "и \" должны быть исключены. Это оставляет нам только 128-35 = 93 символа. 

Таким образом, теоретически мы можем определить кодировку Base93, которая увеличит кодированный размер до 8/log2 (93) = 8 * log10 (2)/log10 (93) = 122%. Но кодировка Base93 будет не такой удобной, как кодировка Base64. Base64 требует разрезать последовательность входных байтов на 6-битные порции, для которых хорошо работает простая побитовая операция. При этом 133% - это не намного больше, чем 122%. 

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

Если производительность критична, то чистая двоичная кодировка должна рассматриваться как замена JSON. Но с JSON я пришел к выводу, что Base64 - лучший.

26
chmike

Если вы имеете дело с проблемами пропускной способности, попробуйте сначала сжать данные на стороне клиента, а затем base64-it.

Хорошим примером такой магии является http://jszip.stuartk.co.uk/ и дальнейшее обсуждение этой темы на реализация JavaScript в Gzip

18
andrej

yEnc может работать на вас:

http://en.wikipedia.org/wiki/Yenc

18
richardtallent

формат улыбки

Это очень быстро кодировать, декодировать и компактировать

Сравнение скорости (на основе Java, но, тем не менее, имеет смысл): https://github.com/eishay/jvm-serializers/wiki/

Также это расширение JSON, которое позволяет пропустить кодировку base64 для байтовых массивов.

Smile-закодированные строки могут быть сжаты, когда пространство критично

9
Stefano Fratini

Несмотря на то, что base64 имеет степень расширения ~ 33%, это не обязательно так, что накладные расходы обработки значительно больше, чем это: это действительно зависит от используемой вами библиотеки/инструментария JSON. Кодирование и декодирование - это простые прямые операции, и они даже могут быть оптимизированы по кодированию символов (поскольку JSON поддерживает только UTF-8/16/32) - символы base64 всегда являются однобайтовыми для записей строки JSON. Например, на платформе Java есть библиотеки, которые могут выполнять эту работу довольно эффективно, так что накладные расходы в основном связаны с расширенным размером.

Я согласен с двумя более ранними ответами:

  • base64 - это простой, широко используемый стандарт, поэтому вряд ли найдется что-то более конкретное для использования с JSON (base-85 используется postscript и т. д .; но преимущества в лучшем случае незначительны, когда вы об этом думаете)
  • сжатие перед кодированием (и после декодирования) может иметь много смысла, в зависимости от данных, которые вы используете
7
StaxMan

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

2
jsoverson

(Изменить 7 лет спустя: Google Gears больше нет. Игнорируйте этот ответ.)

Команда Google Gears столкнулась с проблемой отсутствия типов двоичных данных и попыталась решить ее:

Blob API

В JavaScript есть встроенный тип данных для текстовых строк, но ничего для двоичных данных. Объект Blob пытается устранить это ограничение.

Может быть, вы можете сплести это как-нибудь.

2
a paid nerd

Просто чтобы добавить ресурс и сложность с точки зрения обсуждения. Поскольку выполняются операции PUT/POST и PATCH для хранения новых ресурсов и их изменения, следует помнить, что передача контента является точным представлением контента, который хранится и который получен путем выполнения операции GET.

Сообщение, состоящее из нескольких частей, часто используется как спаситель, но по причине простоты и для более сложных задач я предпочитаю выдавать контент целиком. Это самоочевидно и просто. 

И да, JSON - это что-то серьезное, но, в конце концов, сам JSON многословен. А накладные расходы на сопоставление с BASE64 - это путь к малым.

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

Также нравится подход BSON, это не так широко и легко поддерживается, как хотелось бы. 

По сути, мы просто что-то здесь упускаем, но встраивание двоичных данных в базу base64 хорошо известно, и есть путь, если вы действительно не определили необходимость выполнения реальной двоичной передачи (что вряд ли имеет место).

1
Martin Kersten

Тип данных действительно касается. Я проверил различные сценарии отправки полезных данных из ресурса RESTful. Для кодирования я использовал Base64 (Apache) и для сжатия GZIP (Java.utils.Zip. *). Полезная нагрузка содержит информацию о фильме, изображении и аудиофайле. Я сжал и закодировал изображения и аудиофайлы, что резко ухудшило производительность. Кодирование до сжатия получилось хорошо. Изображение и аудиоконтент были отправлены в виде закодированных и сжатых байтов []. 

0
Koushik

Я копаю немного больше (во время реализации base128 ) и раскрываю, что когда мы отправляем символы с кодами ascii больше 128, тогда браузер (chrome) фактически отправляет ДВА символа (байта) вместо одного :(. Причина в том, что JSON по умолчанию использует символы utf8, для которых символы с кодами ascii выше 127 кодируются двумя байтами, что было упомянуто в chmike answer. Я сделал тест следующим образом: введите chrome url bar chrome: // net-export /, выберите «Включить необработанные байты», начните захват, отправьте запросы POST (используя фрагмент внизу), прекратите захват и сохраните файл json с данными необработанных запросов. Затем мы смотрим в этот файл JSON:

  • Мы можем найти наш запрос base64, найдя строку 4142434445464748494a4b4c4d4e, это шестнадцатеричное кодирование ABCDEFGHIJKLMN, и мы увидим, что "byte_count": 639 для него.
  • Мы можем найти наш запрос выше 127, найдя строку C2BCC2BDC380C381C382C383C384C385C386C387C388C389C38AC38B. Это - коды шестнадцатеричных символов utf8 запроса ¼½ÀÁÂÃÄÅÆÇÈÉÊË (однако шестнадцатеричные коды ascii этих символов - c1c2c3c4c5c6c7c8c9cacbcccdce). "byte_count": 703, поэтому он на 64 байта длиннее, чем запрос base64, потому что символы с кодами ascii выше 127 кодируются на 2 байта в запросе :(

Так что на самом деле у нас нет прибыли с посылкой символов с кодами> 127 :(. Для строк base64 мы не наблюдаем такого негативного поведения (вероятно, и для base85 - я не проверю это) - однако может быть какое-то решение этой проблемы будет отправка данных в двоичной части POST multipart/form-data, описанных в exLex answer (однако обычно в этом случае нам вообще не нужно использовать какое-либо базовое кодирование ...). 

Альтернативный подход может основываться на отображении двухбайтовой части данных в один действительный символ utf8 с помощью кода, использующего что-то вроде base65280/base65k, но, вероятно, он будет менее эффективным, чем base64, из-за спецификации utf8 ...

function postBase64() {
  let formData = new FormData();
  let req = new XMLHttpRequest();

  formData.append("base64ch", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/");
  req.open("POST", '/testBase64ch');
  req.send(formData);
}


function postAbove127() {
  let formData = new FormData();
  let req = new XMLHttpRequest();

  formData.append("above127", "¼½ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüý");
  req.open("POST", '/testAbove127');
  req.send(formData);
}
<button onclick=postBase64()>POST base64 chars</button>
<button onclick=postAbove127()>POST chars with codes>127</button>

0
Kamil Kiełczewski

См. http://snia.org/sites/default/files/Multi-part%20MIME%20Extension%20v1.0g.pdf

Он описывает способ передачи двоичных данных между клиентом и сервером CDMI с помощью операций «тип содержимого CDMI», не требуя преобразования двоичных данных в base64.

Если вы можете использовать операцию «Тип содержимого не-CDMI», то идеально подходит для передачи «данных» в/из объекта. Затем метаданные могут быть впоследствии добавлены/извлечены в/из объекта как последующая операция «тип содержимого CDMI».

0
Dheeraj Sangamkar

Если вы используете Node, я думаю, что самый эффективный и простой способ - это конвертировать в UTF16 с помощью:

Buffer.from(data).toString('utf16le');

Вы можете получить свои данные:

Buffer.from(s, 'utf16le');
0
Sharcoux