数据URI中的字符集

Question

多年来，通过阅读不断发展的规范，我假设RFC 3986最终确定了转义八位字节序列的UTF-8编码。也就是说，如果我的URI有%XX%YY%ZZ，我可以获取解码八位字节序列（对于方案特定部分中的任何URI）并将生成的字节解释为UTF-8，以找出解码信息的意图。实际上，我可以调用JavaScriptdecdeURIComponent（）来自动为我进行解码。

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

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

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

此外，这是否意味着RFC 2397现在与RFC 3986发生冲突，这似乎表明假设是UTF-8？还是RFC 3986只引用了“新的URI方案[s]”，这意味着data：URI方案得到了保护，并且有自己的技术来指定编码的八位字节的含义？

目前我最好的猜测是data：按照自己的规则运行，如果它指示UTF-8以外的字符集，我将不得不在JavaScript中使用decdeURIComponent（）以外的东西。也欢迎关于替换方法的任何建议。




Answer 1

匿名用户

请记住，URI方案描述的资源可以被认为是由不透明的bytestream组成的文件，就像它是http:URI（相同的bytestream，但存储在http服务器上）或ftp:URI（相同的bytestream，但存储在ftp服务器上）或文件：URI一样（与ByTestStream相同，但存储在本地文件系统中）。只有附加到文件的元数据才具有ByTestStream的含义。

RFC 2397给出了一个关于如何将这个字节流嵌入到URI本身的明确规范（与其他URI方案不同，在其他URI方案中，URI给出了在哪里获取字节流的指令，而不是它包含什么）。它可能是base64，也可能是RFC中给出的百分比编码方法。如果字节流包含人非ASCII字节，Base64将会更加紧凑。

数据URI也描述了它自己的内容类型，它给出了ByTestStream的预期解释。在这种情况下，由于您使用了文本/纯文本；字符集=iso-8859-7，字节必须正确编码为iso-8859-7文本。字节肯定不会被确定为UTF-8或任何其他字符编码。它将使用您指定的字符编码进行明确解码。