Base64 每个字符仅使用 6 位 （2^6 = 64） 从图像文件创建文本数据。 这会导致效率低下。
根据Base64上的维基百科条目，这种低效率是为了防止像电子邮件这样的8位脏东西。
Ajax 发布 8 位干净吗？ 如果是这样，是否有使用 Base64 的替代方案？
php.net（维基百科也是如此）声称base64_encode效率低下33%。
有点。所有 JavaScript 字符串都是 UTF-16，而不是字节字符串。如果您使用 send 发送数据，则在发送之前，它将被编码为 UTF-8。因此，您可以将字节转换为 Unicode 码位，然后将其编码为 UTF-8。当它到达服务器时，您必须解码 UTF-8，然后将代码点转换回字节。
对于 7 位数据，这根本不会扩展数据的大小。对于始终设置最高有效位的 8 位数据，它将使数据大小加倍。对于设置了一半时间最高有效位的 8 位数据，它将使数据大小增加 50%，这比 Base64 增加 33.3۞% 更差。
另一方面，使用XMLHttpRequest级别 2 将允许您通过传递ArrayBuffer、Blob或FormData send来发送二进制数据。但是，XMLHttpRequest级别 2 仅在较新的浏览器中受支持。
我认为AJAX发布在这方面与通用POST请求相同;这就是为什么我们需要"多部分/表单数据"来发送文件内容的原因。通常数据会被URL编码，但Base64可能是一种更好的方法，因为它（通常）更有效。
更新：以另一种方式看待这个问题可能会有所帮助。您需要一些值流（可能需要所有 8 位）才能安全地通过 7 位筛选。完美的解决方案是使用"7到8"编码，因此每个7个字节变成8个"安全"字符。但这不适用，因为这些 7 位字符中的一些实际上用于指定有关流的一些附加（元）信息......
现在你有一个两难的境地：要么使用下一个整数（6位 - 即base64） - 要么尝试发明一个带有"非整数"除法器的方案。这样的方案是存在的（例如，检查Ascii85），但它们很少使用。