数据URI中的字符集

Question

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

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

charset=iso-8859-1

但这意味着JavaScript data:text/plain;charset=iso-8859-7,%be%fg%be （假定UTF-8编码的八位字节）不能用于从数据URI中提取字符串，对吗？这是否意味着如果字符集不是UTF-8，我必须为数据URI创建自己的解码？

此外，这是否意味着RFC 2397现在与RFC 3986冲突，这似乎表明UTF-8被假设？或者RFC 3986仅引用“新的URI方案[s]”，这意味着decodeURIComponent() URI方案已经被广泛使用并且有自己的技术来指定编码的八位字节的含义？

我现在最好的猜测是data:按照自己的规则播放，如果它表示UTF-8以外的字符集，我将不得不在JavaScript中使用data:之外的其他内容。任何有关替代方法的建议也会受到欢迎。

Answer 1

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

RFC 2397清楚地说明了如何将这个字节流嵌入到URI本身中（与其他URI方案相反，其中URI提供了获取字节流的位置的指令，而不是它包含的内容）。它可能是base64，也可能是RFC中给出的百分比编码方法。如果字节流包含man非ASCII字节，Base64将更加紧凑。

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