当 base64 null 后跟 =? 时，HTML5 数据 URI 失败

Question

我正在用 JavaScript 做一些非常糟糕的事情，但我遇到了一个奇怪的问题。

我正在创建填充静态大小缓冲区的二进制数据。如果内容没有填满缓冲区，则剩余部分用空字符填充。

下一步是转换为base64。

大小（字节）并不总是 3 的倍数，所以我可能需要在末尾添加填充。缓冲区中的最后一个字节始终为空（实际上，它大约是一 kb 的空值）。

当我在 Firefox 和 Chrome 上将此转换为 base64 时，如果我有一个尾随的“=”，我会得到一个 ERR_INVALID_URL，但如果我没有，它可以正常下载。

例如：

var url = "data:application/octet-stream;base64,";

window.open(url + "AAAA"); // works
window.open(url + "AAAA="); // doesn't work
window.open(url + "icw="); // works

我的文件有效，但不符合规范。

这是无效的 base64 有什么原因吗？更重要的是，这是一个错误还是规范的一部分？

编辑：

我发布了一个答案，给出了 Firefox 和 Chrome 之间的一些奇怪之处。有谁知道标准规定了什么？或者它是那些导致碎片化的松散规范之一？如果可能的话，我想要一些确定的东西。

Answer 1

填充字符= 用于填充最多四个代码字符的倍数。由于每三个字节的输入映射到四个字节的输出，所以不是三的倍数的输入字节数需要填充（一个字节的余数需要==，两个字节的余数需要=）。

在你的情况下，AAAA 已经是一个有效的代码字并且不需要填充。

Answer 2

您为什么认为在字符串末尾添加“=”字符会起作用？这不是 base64 中的有效字符。

字符集为大小写字母；数字；和“+”和“/”。因此，其他任何内容在 base64 字符串中均无效。

edit — 对于 URL，似乎您使用“-”和“_”而不是“+”和“/”（对于字符集中的位置 62 和 63）。

编辑更多——这是一个非常令人困惑的话题，因为存在不同的、表面上权威但相互矛盾的信息来源。例如，the Mozilla description of the data URL scheme 没有提及使用“文件名友好”替代编码。 IETF 数据 url RFC 也是如此。但是，其他 IETF 文档清楚地讨论并指定了用“-”和“_”替换有问题的（对于文件名）“+”和“/”的变体。

因此，我宣布自己无知 :-) Gumbo 可能是对的，您收到的抱怨是关于不正确的填充（即，实际上不需要填充时的填充）。

Answer 3

关于不同浏览器的注意事项：

• 铬
  • datalength % 4 === 1- 需要一个等号
  • datalength % 4 === 2- 需要两个等号
• Firefox- 等号是可选的，但遵循与 Chrome 中相同的约定

这是我用来测试的那一行（我每次都用不同的字符串替换了 AAAAAA==）：

var url = "data:application/octet-stream;base64,AAAAAA=="; window.open(url);

此外，Firefox 和 Chrome 都使用 + 和 /，而不是 - 和 _。

来源：

我在 Ubuntu 11.04 上使用 Chrome 11 和 Firefox 4 进行的测试。

编辑：

我需要的代码是tar utility for Javascript。我的代码按原样工作，但我希望尽可能符合标准，而且我认为缺少一个字节。没什么大不了的，因为 Linux 中的 tar 可以识别它。