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字符串?
我也遇到了同样的问题，我想分享一个解决方案:multipart/form-data。
通过发送一个多部分的表单，你首先将你的JSON元数据作为字符串发送，然后分别以原始二进制(图像，波浪等)以Content-Disposition名称为索引发送。
这里有一个很好的教程，教你如何在obj-c中做到这一点，这里有一篇博客文章，解释了如何用表单边界划分字符串数据，并将其与二进制数据分开。
你真正需要做的唯一改变是在服务器端;你必须捕获你的元数据，它应该适当地引用POST的二进制数据(通过使用Content-Disposition边界)。
尽管这需要在服务器端进行额外的工作，但如果您要发送许多图像或大型图像，这是值得的。如果需要，可以将其与gzip压缩结合使用。
在我看来，发送base64编码的数据是一种黑客行为;RFC multipart/form-data是针对以下问题创建的:将二进制数据与文本或元数据结合发送。
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等;但仔细想想，这些好处充其量只是边际的)
编码前压缩(解码后压缩)可能很有意义，这取决于您使用的数据
在讨论中加入资源和复杂性的观点。由于使用PUT/POST和PATCH来存储和修改新资源，所以应该记住，内容传输是通过发出GET操作来存储和接收的内容的精确表示。
多部分信息通常被用作救星，但出于简单的原因和更复杂的任务，我更喜欢将内容作为一个整体来提供。它是不言自明的，而且很简单。
JSON确实很麻烦，但最终JSON本身也很冗长。而且映射到BASE64的开销也很小。
正确使用Multi-Part消息，必须拆除要发送的对象，使用属性路径作为自动组合的参数名称，或者需要创建另一种协议/格式来表达有效负载。
同样喜欢BSON方法，这并不像人们所希望的那样被广泛和容易支持。
基本上，我们在这里漏掉了一些东西，但是将二进制数据嵌入为base64是很好的方法，除非您确实确定需要进行真正的二进制传输(这很少是这样的情况)。
