数据 URI 中的字符集

Question

多年来，通过阅读不断发展的规范，我一直认为RFC 3986 最终确定了转义八位字节序列的 UTF-8 编码。也就是说，如果我的 URI 有 %XX%YY%ZZ，我可以采用解码后的八位字节序列（对于特定于方案的部分中的任何 URI）并将结果字节解释为 UTF-8，以找出解码后的信息是什么意思。实际上，我可以调用 JavaScript decodeURIComponent()，它会自动为我进行解码。

然后我阅读了data: URI 的规范RFC 2397，其中包括一个charset 参数，它（自然）表示编码数据的字符集。但这是如何工作的？如果我的data: URI 中有一个两个八位字节编码的序列%XX%YY，charset=iso-8859-1 是否表明两个解码的八位字节应该不被解释为 UTF-8 序列，而是作为作为两个单独的拉丁字符（因为 ISO-8859-1 中的每个字节代表一个字符）？ RFC 2397 似乎表明了这一点，因为它给出了“希腊 [原文] 字符”的示例：

data:text/plain;charset=iso-8859-7,%be%fg%be

但这意味着 JavaScript decodeURIComponent()（假定 UTF-8 编码的八位字节）不能用于从数据 URI 中提取字符串，对吗？这是否意味着如果字符集是 UTF-8 以外的字符集，我必须为数据 URI 创建自己的解码？

此外，这是否意味着 RFC 2397 现在与 RFC 3986 发生冲突，这似乎表明假定了 UTF-8？还是 RFC 3986 仅引用“新的 URI 方案[s]”，这意味着 data: URI 方案被继承并拥有自己的技术来指定编码八位位组的含义？

目前我最好的猜测是data: 按自己的规则运行，如果它指示 UTF-8 以外的字符集，我将不得不在 JavaScript 中使用 decodeURIComponent() 以外的字符集。我们也欢迎任何关于替代方法的建议。

Answer 1

请记住，data: URI 方案描述的资源可以被视为由不透明字节流组成的文件，就好像它是 http: URI（相同的字节流，但存储在 HTTP 服务器上）或 ftp: URI（相同的字节流，但存储在 FTP 服务器上）或 file: URI（相同的字节流，但存储在本地文件系统上）。只有附加到文件的元数据才能赋予字节流含义。

RFC 2397 给出了关于如何将此字节流嵌入 URI 本身的明确规范（与其他 URI 方案相反，在其他 URI 方案中，URI 指示从何处获取字节流，而不是它包含的内容）。它可能是 base64，也可能是 RFC 中给出的百分比编码方法。如果字节流包含非 ASCII 字节，Base64 会更紧凑。

data: URI 还描述了它自己的 Content-Type，它给出了字节流的预期解释。在这种情况下，由于您使用了text/plain;charset=iso-8859-7，因此字节必须是正确编码的 ISO-8859-7 文本。字节肯定不会被确定为 UTF-8 或任何其他字符编码。它将使用您指定的字符编码进行明确解码。