Gar*_*son 9 uri utf-8 rfc character-encoding url-encoding
多年来,我一直在阅读不断发展的规范,我认为RFC 3986最终确定了转义八位字节序列的UTF-8编码.也就是说,如果我的URI已经%XX%YY%ZZ可以采用该序列的解码八位字节(对于特定于方案的部分中的任何URI)并将结果字节解释为UTF-8以找出想要的解码信息.实际上,我可以调用JavaScript decodeURIComponent()来自动解码.
然后我读取了data:URI 的规范,RFC 2397,其中包括一个charset参数,它(自然地)表示编码数据的字符集.但是这有什么作用呢？如果我有两个八位字节编码的序列%XX%YY在我的data:URI,做了charset=iso-8859-1说明,这两个解码octects应该不被解释为UTF-8序列,但作为两个独立的拉丁字符(如ISO-8859-1每个字节代表一个人物)？RFC 2397似乎表明了这一点,因为它给出了一个"希腊[sic]字符"的例子:
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 以外的其他东西.任何有关替代方法的建议也会受到欢迎.
请记住,data:URI方案描述的资源可以被视为一个文件,它由一个不透明的字节流组成,就好像它是一个http:URI(相同的字节流,但存储在HTTP服务器上)或ftp:URI(相同的字节流,但是存储在FTP服务器上)或file:URI(相同的字节流,但存储在本地文件系统中).只有附加到文件的元数据才能赋予字节流含义.
RFC 2397给出了关于如何将这个字节流嵌入URI本身的明确规范(与其他URI方案相反,其中URI提供了获取字节流的位置的指令,而不是它包含的内容).它可能是base64,也可能是RFC中给出的百分比编码方法.如果字节流包含man非ASCII字节,Base64将更紧凑.
该data:URI还介绍了自己的内容类型,这给字节流的预期解释.在这种情况下,由于您已经使用过text/plain;charset=iso-8859-7,所以字节必须正确编码ISO-8859-7文本.绝对不会将字节确定为UTF-8或任何其他字符编码.它将使用您指定的字符编码进行明确解码.