当前位置:  开发笔记 > 运维 > 正文

我应该假设URL中的编码字符是什么字符集?

如何解决《我应该假设URL中的编码字符是什么字符集?》经验,为你挑选了1个好方法。

RFC 1738指定了URL的语法,并提到了这一点

URL仅使用
US-ASCII编码字符集的图形可打印字符编写.八位字节80-FF十六进制不
用于US-ASCII,八位字节00-1F和7F十六进制表示
控制字符; 这些必须编码.

但是,它并没有说明这些八位字节代表什么代码.

RFC 2396似乎试图改善这种情况,但是:

但是,对于包含非ASCII字符的原始字符序列,情况更加困难.如果可能存在多个[RFC2277],那么传输用于表示字符序列的八位字节序列的因特网协议有望提供一些识别所用字符集的方法.但是,通用URI语法中目前没有提供完成此标识的规定.单个URI方案可能需要单个字符集,定义默认字符集,或提供指示所使用的字符集的方法.

期望对URI内的字符编码进行系统处理,作为本说明书的未来修改.

是否有任何明确的方式,客户端可以确定在哪个字符集中解释编码的八位字节,或者服务器可以确定客户端用于编码的内容?

在我看来,大多数服务器都默认使用UTF-8,但这似乎是一个事实上的选择而不是指定的服务器.



1> Javier..:

根据您的引用,URL是ASCII.就这样.

URI OTOH,允许更大的字符集; 通常是你自己说的UTF-8.

需要记住的是URL是URI的子集.因此,真正的问题是,您在浏览器中编写的是哪一个?

我猜你可以写一个URI,浏览器应该尽力转换为URL(这是HTTP/1.1支持,AFAICR).对于非ASCII字符,这意味着十六进制代码,通常编码为UTF-8.


URL是不具有字符编码的不透明标识符,可以将不透明标识符视为仅对目标主机有意义的二进制字符串。如果目标主机愿意,它可以对URL数据应用字符集解释。这意味着客户端无法控制含义或字符集,也无法表达选择,因为对服务器而言,URL的解释是100%。因此,要回答原始问题,您不能假设任何字符集是服务器实现特定的,请咨询服务器管理员。
推荐阅读
Gbom2402851125
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有