本题涉及URL查询字符串部分的字符,出现在?
标记字符之后。
根据 Wikipedia ,某些字符保留原样,而其他字符则进行编码(通常使用 %
转义序列)。
我一直在努力将其追踪到实际规范,以便我理解该维基百科页面中每个要点背后的理由。
矛盾例一:
HTML specification表示将空格编码为 +
并将其余部分推迟到 RFC1738 .但是,此 RFC 表示 ~
是不安全的,而且“[a]所有不安全字符必须始终在 URL 中进行编码”。这似乎与维基百科相矛盾。
在实践中,IE8 在它生成的查询字符串中对 ~
进行编码,而 FF3 保持原样。
矛盾例二:
维基百科指出,所有未提及的字符都必须进行编码。 !
没有在维基百科中提及。但是RFC1738声明 !
是一个“特殊”字符,并且“可以未经编码使用”。这似乎与维基百科说它必须被编码相矛盾。
在实践中,IE8 在它生成的查询字符串中对 !
进行编码,而 FF3 保持原样。
我知道这样做的寓意可能是对那些在维基百科和规范之间有疑问的字符进行编码。甚至可能编码所有不是 [A-Za-z0-9] 的东西。我只想知道这方面的实际标准。
结论
维基百科上描述的算法精确地编码那些不是 RFC3986 unreserved characters 的字符.也就是说,它对除字母数字和-._~
之外的所有字符进行编码。作为一种特殊情况,根据 RFC3986,空格被编码为 +
而不是 %20
。
一些应用程序使用较旧的 RFC。为了比较,RFC2396 unreserved characters是字母数字和 !'()*-._~
。
为了比较,HTML5 working draft algorithm编码除字母数字和 *-._
之外的所有字符。空格的特殊情况编码仍然是 +
。显着差异是 *
未编码,而 ~
已编码。 (从技术上讲,这种对 *
的处理与 RFC3986 兼容,即使 *
在 reserved
中,因为它在 sub-delims
在 query
生产中是允许的。)
最佳答案
答案在 RFC 3986 文档中,特别是 Section 3.4 .
The query component is indicated by the first question mark ("?") character and terminated by a number sign ("#") character or by the end of the URI.
...
The characters slash ("/") and question mark ("?") may represent data within the query component.
技术上,RFC 3986-3.4将查询组件定义为:
query = *( pchar / "/" / "?" )
此语法意味着查询可以包括 pchar
以及 /
和 ?
中的所有字符。 pchar
指的是路径字符的另一种规范。很有帮助,Appendix A RFC 3986 列出了相关的 ABNF 定义,最值得注意的是:
query = *( pchar / "/" / "?" )
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded = "%" HEXDIG HEXDIG
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
因此,除了所有字母数字和百分比编码字符之外,查询还可以合法地包含以下未编码字符:
/ ? : @ - . _ ~ ! $ & ' ( ) * + , ; =
当然,您可能需要记住“=”和“&”在查询中通常具有特殊意义。
关于html - HTTP 查询字符串中必须转义哪些字符?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2322764/