11

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

然后我阅读了data:URI规范RFC 2397，其中包含一个charset参数，该参数（自然）指示编码数据的字符集。但这是如何工作的？%XX%YY如果我的data:URI 中有两个八位字节编码的序列，是否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 以外的字符集，我将不得不使用decodeURIComponent()JavaScript 以外的其他字符集。任何关于替换方法的建议也将受到欢迎。

4

1 回答 1

7

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

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

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

于 2013-05-25T19:02:11.370 回答