我正在研究为什么我的查询参数中加上+
符号而不是%20
,以及为什么他们有像%C3%BC
这样的字符串而不是ü(UTF-8)作为编码URL确实。
经过2个小时的思考,我的webapp与URL编码标准不兼容,我发现查询字符串的编码方案与URL的编码方式不同(这里我指的是没有查询字符串的部分)。
示例:
所以有人可以告诉我为什么编码方案不同,因为查询参数是URL的一部分?
请参阅:
答案 0 :(得分:26)
URI源自RFC 1630,百分比编码作为允许表示“不安全”字符的方法。这个原始版本实际上提到了ISO Latin 1字符集作为非ASCII字符的编码。那年晚些时候RFC 1738在定义网址时删除了对Latin-1的引用。
查询字符串格式实际上是一个不同的但相关的编码,application / x-www-form-urlencoded,在RFC 1866中与HTML 2.0一起定义。它基于RFC 1738,但指定空格(不是所有空格,只有ASCII码0x20的字符)被'+'替换,并且换行符将被编码为CRLF(即%0D%0A
)。前者很可能是因为在表单提交中为一个非常常见的字符节省了2个字节,代价是对一个不太常见的字符使用额外的2个字节,而后者是为了避免在使用不同字符串的系统之间进行传输时出现问题行编码。非ASCII字符未被考虑。
URI中的UTF-8编码十多年后在RFC 3986中出现,尽管各个协议可能早先指定了这种或另一种非ASCII字符编码。为了保持向后兼容性,所有UTF-8八位字节必须进行百分比编码。伴随RFC 3987定义了“国际化资源标识符”(IRI),它们基本上是“大多数代码点160及以上的URI允许显示为未编码的”,但许多协议仍然需要URI。请注意,上面的陈述不正确,因为 U RL可能不包含未编码的ü或任何其他非ASCII字符。
application / x-www-form-urlencoded已经以不同的方式进行了国际化。 HTML5 specification of application/x-www-form-urlencoded明确允许任何与ASCII兼容的字符集可用于查询字符串中的字符,实际上不同的字段可能使用不同的字符集,但所有非ASCII字符集仍必须进行百分比编码。当在IRI的查询部分中使用时,如果正确规范化的UTF-8被用作字符集,那么这些字符可能被表示为未编码,因为转换回URI将导致在正确的应用程序/ x-www-form-urlencoded数据。
答案 1 :(得分:1)
它们不一定必须不同,+
是有效的路径字符,而ü
是有效的搜索字符(根据RFC 3987)。你可能会看到浏览器或其他一些先入为主的编码方案做出过时或过于谨慎的假设。
答案 2 :(得分:-2)