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

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

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

Одним из вариантов использования является проект v0.8 спецификации API облачных хранилищ CDMI . Вы создаете объекты данных через 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?

15 Solutions collect form web for “Двоичные данные в строке JSON. Что-то лучше, чем Base64”

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

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

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

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

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

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

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

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

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

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

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

Проблема с 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 является лучшим.

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

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

yEnc может работать для вас:

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

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

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

Сравнение скорости (на основе java, но все же значимое): https://github.com/eishay/jvm-serializers/wiki/

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

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

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

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

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

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

( Редактировать 7 лет спустя: Google Gears исчез. Игнорируйте этот ответ.)

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

API Blob

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

Может быть, ты сможешь что-то переплетать.

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

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

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

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

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

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

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

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

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

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

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

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

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

 Buffer.from(s, 'utf16le'); 

Теперь мое решение XHR2 использует ArrayBuffer. ArrayBuffer как двоичная последовательность содержит многостраничный контент, видео, аудио, графику, текст и т. Д. С несколькими типами контента. Все в одном ответе.

В современном браузере есть DataView, StringView и Blob для разных компонентов. См. Также: http://rolfrost.de/video.html для получения более подробной информации.

  • Http 415 Ошибка неподдерживаемого типа носителя с помощью JSON
  • Каков наилучший способ разобрать ответ JSON из библиотеки запросов?
  • Как разбирать объект JSON в iPhone SDK (XCode) с помощью JSON-Framework
  • Могу ли я загрузить JSON в OrderedDict?
  • Как отправить объект JSON через Request с Android?
  • Regex для проверки JSON
  • Загрузка json-файла в Power Query
  • JSON и экранирующие символы
  • Правильный способ возврата JSON с помощью узла или Express
  • EF 4.1 - Code First - Ошибка серийной ссылки JSON
  • Сериализация списка JSON
  • Interesting Posts
    Давайте будем гением компьютера.