根据JSON规范，有94个Unicode字符可以表示为一个字节(如果您的JSON以UTF-8传输)。考虑到这一点，我认为最好的空格方式是base85，它将四个字节表示为五个字符。然而，这只比base64提高了7%，它的计算成本更高，实现也不像base64那么常见，所以它可能不是一个胜利。

您还可以简单地将每个输入字节映射到U+0000-U+00FF中的相应字符，然后执行JSON标准所需的最小编码来传递这些字符;这里的优点是，除了内置函数之外，所需的解码为nil，但空间效率很差——105%的扩展(如果所有输入字节的可能性相等)，而base85为25%，base64为33%。

最终结论:在我看来，base64胜出，因为它是常见的、简单的，而且还没有坏到需要替换的地步。

参见:Base91和Base122

yEnc可能适合你:

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

"yEnc is a binary-to-text encoding scheme for transferring binary files in [text]. It reduces the overhead over previous US-ASCII-based encoding methods by using an 8-bit Extended ASCII encoding method. yEnc's overhead is often (if each byte value appears approximately with the same frequency on average) as little as 1–2%, compared to 33%–40% overhead for 6-bit encoding methods like uuencode and Base64. ... By 2003 yEnc became the de facto standard encoding system for binary files on Usenet."

然而，yEnc是一种8位编码，因此将其存储在JSON字符串中与存储原始二进制数据有相同的问题-使用naïve方式意味着大约100%的展开，这比base64更糟糕。

(7年后编辑:谷歌Gears消失了。忽略这个答案。)

谷歌Gears团队遇到了缺少二进制数据类型的问题，并试图解决它:

Blob API JavaScript为文本字符串提供了内置的数据类型，但没有用于二进制数据的数据类型。Blob对象试图解决这个限制。

也许你可以想办法编进去。

只是添加另一个选项，我们低级的恐龙程序员使用……

一种老式的方法是Intel HEX格式，这种方法已经存在了三年了。它建立于1973年，UNIX时代开始于1970年1月1日。

它的效率更高吗?不。 这是一个公认的标准吗?是的。 它是否像JSON那样适合人类阅读?是的，而且比大多数二进制解决方案更具可读性。

json看起来像这样:

{
    "data": [
    ":10010000214601360121470136007EFE09D2190140",
    ":100110002146017E17C20001FF5F16002148011928",
    ":10012000194E79234623965778239EDA3F01B2CAA7",
    ":100130003F0156702B5E712B722B732146013421C7",
    ":00000001FF"
    ]
}

UTF-8的问题在于它不是空间利用率最高的编码。另外，一些随机二进制字节序列是无效的UTF-8编码。因此，您不能将随机二进制字节序列解释为一些UTF-8数据，因为它将是无效的UTF-8编码。这种约束对UTF-8编码的好处是，它使其健壮，并且可以定位我们开始查看的任何字节的开始和结束的多字节字符。

因此，如果在[0..]范围内对字节值进行编码。127]在UTF-8编码中只需要一个字节，编码范围为[128..]255]需要2个字节! 比这更糟。在JSON中，控制字符“和\不允许出现在字符串中。因此二进制数据需要进行一些转换才能正确编码。

我们看到的。如果我们假设在二进制数据中均匀分布随机字节值，那么平均而言，一半字节将被编码为一个字节，另一半字节将被编码为两个字节。UTF-8编码的二进制数据将是初始大小的150%。

Base64编码只增长到初始大小的133%。所以Base64编码更有效。

What about using another Base encoding ? In UTF-8, encoding the 128 ASCII values is the most space efficient. In 8 bits you can store 7 bits. So if we cut the binary data in 7 bit chunks to store them in each byte of an UTF-8 encoded string, the encoded data would grow only to 114% of the initial size. Better than Base64. Unfortunately we can't use this easy trick because JSON doesn't allow some ASCII chars. The 33 control characters of ASCII ( [0..31] and 127) and the " and \ must be excluded. This leaves us only 128-35 = 93 chars.

因此，理论上我们可以定义Base93编码，将编码的大小增加到8/log2(93) = 8*log10(2)/log10(93) = 122%。但是Base93编码不像Base64编码那么方便。Base64需要将输入字节序列切割成6位块，因此简单的逐位操作就可以很好地工作。133%比122%高不了多少。

这就是为什么我独立地得出了一个共同的结论，即Base64确实是在JSON中编码二进制数据的最佳选择。我的回答为它提供了一个理由。我同意从性能的角度来看，它不是很吸引人，但也考虑到使用JSON的好处，它的人类可读的字符串表示在所有编程语言中都很容易操作。

如果性能比较关键，则应该考虑使用纯二进制编码来替代JSON。但是对于JSON，我的结论是Base64是最好的。

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

它描述了一种使用“CDMI内容类型”操作在CDMI客户机和服务器之间传输二进制数据的方法，而不需要对二进制数据进行base64转换。

如果您可以使用“非cdmi内容类型”操作，那么理想的情况是将“数据”传输到对象或从对象传输到对象。然后，元数据可以作为后续的“CDMI内容类型”操作添加/从对象中检索。