JSON格式本身不支持二进制数据。二进制数据必须转义，以便可以将其放在JSON中的字符串元素中(即使用反斜杠转义的双引号中的零或多个Unicode字符)。
转义二进制数据的一个明显方法是使用Base64。然而，Base64有很高的处理开销。此外，它将3个字节扩展为4个字符，导致数据大小增加约33%。
其中一个用例是CDMI云存储API规范的0.8版草案。您可以使用JSON通过REST-Webservice创建数据对象，例如:
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字符串?
While it is true that base64 has ~33% expansion rate, it is not necessarily true that processing overhead is significantly more than this: it really depends on JSON library/toolkit you are using. Encoding and decoding are simple straight-forward operations, and they can even be optimized wrt character encoding (as JSON only supports UTF-8/16/32) -- base64 characters are always single-byte for JSON String entries.
For example on Java platform there are libraries that can do the job rather efficiently, so that overhead is mostly due to expanded size.
我同意之前的两个答案:
base64是简单的，常用的标准，所以不太可能找到更好的标准来与JSON一起使用(base-85用于postscript等;但仔细想想，这些好处充其量只是边际的)
编码前压缩(解码后压缩)可能很有意义，这取决于您使用的数据
在深度上
I dig a little bit more (during implementation of base128), and expose that when we send characters which ascii codes are bigger than 128 then browser (chrome) in fact send TWO characters (bytes) instead one :(. The reason is that JSON by defaul use utf8 characters for which characters with ascii codes above 127 are coded by two bytes what was mention by chmike answer. I made test in this way: type in chrome url bar chrome://net-export/ , select "Include raw bytes", start capturing, send POST requests (using snippet at the bottom), stop capturing and save json file with raw requests data. Then we look inside that json file:
We can find our base64 request by finding string 4142434445464748494a4b4c4d4e this is hex coding of ABCDEFGHIJKLMN and we will see that "byte_count": 639 for it.
We can find our above127 request by finding string C2BCC2BDC380C381C382C383C384C385C386C387C388C389C38AC38B this are request-hex utf8 codes of characters ¼½ÀÁÂÃÄÅÆÇÈÉÊË (however the ascii hex codes of this characters are c1c2c3c4c5c6c7c8c9cacbcccdce). The "byte_count": 703 so it is 64bytes longer than base64 request because characters with ascii codes above 127 are code by 2 bytes in request :(
所以事实上，发送带有代码>127的字符并没有什么好处。对于base64字符串，我们没有观察到这样的负面行为(可能对于base85也是如此-我不检查它)-然而，这个问题的一些解决方案将以POST multipart/form-data的二进制部分发送数据，在Ælex回答中描述(然而通常在这种情况下，我们根本不需要使用任何基本编码…)
另一种方法可能依赖于通过使用base65280 / base65k之类的代码将两个字节的数据部分映射到一个有效的utf8字符，但由于utf8规范，它可能不如base64有效……
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>
只是添加另一个选项，我们低级的恐龙程序员使用……
一种老式的方法是Intel HEX格式，这种方法已经存在了三年了。它建立于1973年，UNIX时代开始于1970年1月1日。
它的效率更高吗?不。
这是一个公认的标准吗?是的。
它是否像JSON那样适合人类阅读?是的，而且比大多数二进制解决方案更具可读性。
json看起来像这样:
{
"data": [
":10010000214601360121470136007EFE09D2190140",
":100110002146017E17C20001FF5F16002148011928",
":10012000194E79234623965778239EDA3F01B2CAA7",
":100130003F0156702B5E712B722B732146013421C7",
":00000001FF"
]
}
