1

Base64 仅使用每个字符 6 位 (2^6 = 64) 从图像文件创建文本数据。这导致效率低下。

根据Base64 上的维基百科条目，这种低效率是为了防止 8 位脏东西，如电子邮件。

Ajax Posting 8 位干净吗？如果是这样，是否有使用 Base64 的替代方法？

php.net（维基百科也是如此）声称base64_encode的效率低 33% 。.

4

2 回答 2

2

有点儿。所有 JavaScript 字符串都是 UTF-16，而不是字节字符串。如果您使用 发送数据send，则在发送之前会将其编码为 UTF-8。因此，您可以将字节转换为 Unicode 代码点，然后将其编码为 UTF-8。当它到达服务器时，您必须对 UTF-8 进行解码，然后将代码点转换回字节。

对于 7 位数据，这根本不会扩大数据的大小。对于始终设置最高有效位的 8 位数据，它将使数据大小加倍。对于最高有效位设置一半时间的 8 位数据，它将使您的数据大小增加 50%，这比 Base64 33.3͞% 的增加要差。

另一方面，使用XMLHttpRequestLevel 2send将允许您通过传递、或来发送二进制数据ArrayBuffer。但是，级别 2 仅在较新的浏览器中受支持。BlobFormDataXMLHttpRequest

于 2012-07-08T23:33:23.570 回答
1

我认为 AJAX 发布在这方面与通用 POST 请求相同；这就是为什么我们需要“multipart/form-data”来发送文件的内容，例如。通常数据会被 url 编码，但 Base64 可能是更好的方法，因为它（通常）更有效。

更新：以另一种方式看待这一点可能会有所帮助。) 您需要一些可能占用所有 8 位的值流来安全地通过 7 位过滤。完美的解决方案是使用“7-to-8”编码，这样每 7 个字节就变成了 8 个“安全”字符。但这不适用，因为其中一些 7 位字符实际上用于指定有关流的一些附加（元）信息......

现在你有一个两难选择：要么使用下一个整数（6 位 - 即 base64） - 要么尝试发明一个带有“非整数”除法器的方案。存在这样的方案（例如检查Ascii85），但它们很少使用。

于 2012-07-08T23:08:02.583 回答