分号作为URL查询分隔符

Question

分号作为URL查询分隔符

myk*_*hal 51 url webserver parsing http query-string

虽然强烈建议(W3C源,通过维基百科)Web服务器支持分号作为URL查询项的分隔符(除了&符号),但似乎通常不会遵循.

例如,比较

http://www.google.com/search?q=nemo & OE = UTF-8

http://www.google.com/search?q=nemo ; OE = UTF-8

结果.(在后一种情况下,分号是,或者在撰写本文时,被视为普通的字符串字符,就像网址是:http://www.google.com/search？q = nemo %3B oe = utf-8)

虽然我尝试了第一个URL解析库,但表现良好:

>>> from urlparse import urlparse, query_qs
>>> url = 'http://www.google.com/search?q=nemo;oe=utf-8'
>>> parse_qs(urlparse(url).query)
{'q': ['nemo'], 'oe': ['utf-8']}

Run Code Online (Sandbox Code Playgroud)

接受分号作为分隔符的当前状态是什么,哪些是潜在的问题或一些有趣的注释？(从服务器和客户端的角度来看)

Answer 1

gei*_*ira 19

1999年的W3C建议书已经过时.根据2014 W3C建议书,目前的状态是分号现在是非法的参数分隔符:

要解码application/x-www-form-urlencoded有效载荷,应使用以下算法.[...]此算法的输出是名称 - 值对的排序列表.[...]

设字符串是在U + 0026 AMPERSAND字符(&)上严格分割字符串有效负载的结果.

换句话说,?foo=bar;baz意味着参数foo将具有该值bar;baz; 而?foo=bar;baz=sna应导致foo被bar;baz=sna(虽然在技术上非法的,因为第二个=应该逃到%3D).

这个答案是误导性的，因为它严格地讲的是形式编码，这不是OP所要求的，在所包含的示例中也不是。表单url编码非常古老，并且在通过<form>标记发送数据时使用，我们正在远离现在朝着AJAX。使用＆作为分隔符是一个不幸的旧“错误”，由于向后兼容的原因，现在将其保留下来。只要您的Web服务器支持分号，它就是前进的方式。 (4认同)
如果您阅读 HTTP 和 URL 标准，您会发现除了转义之外，它们没有为查询字符串定义任何语法。事实上，提到的两个文档是现有查询参数的唯一规范。虽然您在技术上正确地认为表单编码（这两个 W3C 建议书都描述了）与 POST 请求相关，但没有类似的 GET 规范，因此浏览器实现遵循前者。现代框架（例如 Mojolicious）也在放弃分号分隔符的支持，除非所有浏览器都被重写，符号永远不会消失。 (4认同)
至于转向 AJAX，请不要认为当前的 [Swagger](https://swagger.io/docs/specification/describing-parameters/)（又名 OpenAPI）标准仅允许使用与号分隔的参数；仅允许使用分号作为路径或 cookie 参数。如果您设计的 API 与 Swagger 规范相矛盾，那么您就会遇到问题。 (2认同)

Answer 2

Dan*_*llo 17

只要您的HTTP服务器和服务器端应用程序接受分号作为分隔符,您就应该好了.我看不出任何弊端.如你所说,W3C规范就在你身边:

我们建议HTTP服务器实现者,特别是CGI实现者支持使用";" 代替"&"来节省作者以这种方式逃避"&"字符的麻烦.

有缺点.通过给予 ";" 特殊的附加含义最初未在RFC中指定,你强制";" 要在密钥和值文本中进行转义.例如,`？q ='one; two'&x = 1`.你期望`{"q":"'one; two'","x":"1"}`,但很可能最终得到:`{"q":"'one","two" ":null,"x":"1"}`或其他一些值.那里有很多潜在的含糊之处.基本上,W3C是愚蠢的. (16认同)

Answer 3

Mat*_*ipp 5

我同意Bob Aman的观点.W3C规范旨在使锚点超链接更容易使用看起来像表单GET请求的URL(例如http://www.host.com/?x=1&y=2).在这种情况下,&符号与系统冲突,用于字符实体引用,所有这些都以&符号开头(例如").因此,W3C建议Web服务器允许使用分号作为字段分隔符而不是&符号,以便更容易编写这些URL.但是这个解决方案要求编写者记住,&符号必须被某些东西替换,并且a ;是一个同样有效的字段分隔符,即使Web浏览器在提交表单时普遍使用URL中的&符号.记住用&这些链接替换&符号可能会更加困难,正如文档中其他地方所做的那样.

更糟糕的是,在所有Web服务器都允许分号作为字段分隔符之前,URL编写者只能对某些主机使用此快捷方式,并且必须&用于其他主机.如果给定主机停止允许使用分号分隔符,他们还必须稍后更改其代码.这肯定比简单使用更难&,这将永远适用于每个服务器.这反过来又消除了Web服务器允许分号作为字段分隔符的任何动机.当每个人都在改变&符号&而不是;？时,为什么还要烦恼？

归档时间：	15 年，2 月前
查看次数：	30589 次
最近记录：	6 年，2 月前