分号作为 URL 查询分隔符

Question

虽然强烈建议（W3C source，通过Wikipedia）Web 服务器支持分号作为 URL 查询项的分隔符（除了 & 符号），但似乎并不普遍遵循。

例如比较

        http://www.google.com/search?q=nemo&oe=utf-8

        http://www.google.com/search?q=nemo;oe=utf-8

结果。 （在后一种情况下，分号是，或在撰写本文时，被视为普通字符串字符，就好像 url 是：http://www.google.com/search?q=nemo%3Boe=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']}

目前接受分号作为分隔符的状态如何，有哪些潜在问题或一些有趣的注意事项？ （从服务器和客户端的角度来看）

Answer 1

只要您的 HTTP 服务器和服务器端应用程序接受分号作为分隔符，您就可以开始使用了。我看不出有什么缺点。正如你所说，W3C spec is on your side：

我们建议 HTTP 服务器实现者，特别是 CGI 实现者支持使用“;”代替“&”来省去作者以这种方式转义“&”字符的麻烦。

Answer 2

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

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

Answer 3

简而言之，HTML 是一团糟（由于它的宽大处理），使用分号有助于简化这一点。我估计，当我考虑到我发现的复杂情况时，使用 & 作为分隔符会使整个过程的复杂度大约是使用分号作为分隔符的三倍！

我是一名 .NET 程序员，据我所知，.NET 不天生就允许使用 ';'分隔符，所以我编写了自己的解析和处理方法，因为我看到了使用分号的巨大价值，而不是使用 & 符号作为分隔符已经存在问题的系统。不幸的是，非常受人尊敬的人（例如另一个答案中的@Bob Aman）没有看到为什么使用分号比使用＆符号要优越得多且简单得多的价值。因此，我现在分享几点，或许可以说服其他尚未认识到使用分号的价值的可敬开发人员：

在 HTML 页面中使用像 '?a=1&b=2' 这样的查询字符串是不合适的（没有首先对其进行 HTML 编码），但大多数情况下它是有效的。然而，这只是因为大多数浏览器都具有容错性，并且这种容错性可能会导致难以发现的错误，例如，当键值对的值在没有正确编码的情况下发布在 HTML 页面 URL 中时（直接作为 '? HTML 源代码中的 a=1&b=2'）。像 '?who=me+&+you' 这样的 QueryString 也是有问题的。

我们人可能有偏见，并且可能整天不同意我们的偏见，因此认识到我们的偏见非常重要。例如，我同意我只是想用';'分开看起来“更干净”。我同意我的“更清洁”意见纯粹是一种偏见。另一个开发人员可能有同样相反和同样有效的偏见。所以我对这一点的偏见并不比相反的偏见更正确。

但鉴于分号的公正支持从长远来看使每个人的生活更轻松，如果考虑到整体情况，则无法正确争论。简而言之，使用分号确实让每个人的生活变得更简单，但有一个例外：习惯新事物的一个小障碍。就这样。做出任何改变总是比较困难的。但与继续使用 & 的持续困难相比，做出改变的困难就相形见绌了。

使用 ;作为 QueryString 分隔符使它更简单。 正确编码与使用分号相比，与号分隔符的难度要高出两倍多。 （我认为）大多数实现都没有正确编码，所以大多数实现不会复杂两倍。但是随后追踪和修复错误会导致生产力下降。在这里，我指出当 & 是分隔符时正确编码 QueryString 所需的 2 个单独的编码步骤：

• 第 1 步：对查询字符串的键和值进行 URL 编码。
• 第 2 步：将第 1 步中的 URL 编码后的键和值（如“a=1&b=2”）连接起来。
• 第 3 步：然后在页面的 HTML 源中对整个 QueryString 进行 HTML 编码。

因此，为了正确（无错误）的 URL 编码，必须进行两次特殊编码，不仅如此，而且编码是两种截然不同的不同编码类型。第一个是 URL 编码，第二个是 HTML 编码（用于 HTML 源代码）。如果其中任何一个不正确，那么我可以为您找到一个错误。但是对于 XML，第 3 步是不同的。对于 XML，则需要 XML 字符实体编码（几乎相同）。我的观点是，最后的编码取决于 URL 的上下文，无论是在 HTML 网页中还是在 XML 文档中。

现在有了更简单的分号分隔符，这个过程正如我们所期望的那样：

• 1：URL 对键和值进行编码，
• 2：将值连接在一起。 （第 3 步没有编码。）

我认为大多数 Web 开发人员会跳过第 3 步，因为浏览器非常宽松。但这会导致错误和更多复杂性，在寻找这些错误或如果这些错误不存在时用户无法执行操作，或编写错误报告等时。

实际使用中的另一个复杂情况是在我的 C# 和 VB.NET 源代码中编写 XML 文档标记时。由于必须对 & 进行编码，因此从字面上看，这对我的工作效率来说是一个真正的拖累。额外的步骤 3 也使阅读源代码变得更加困难。因此，这种难以阅读的缺陷不仅适用于 HTML 和 XML，还适用于 C# 和 VB.NET 代码等其他应用程序，因为它们的文档使用 XML 文档。因此，第 3 步的编码复杂性也会扩散到其他应用程序。

总之，使用 ;作为分隔符很简单，因为使用分号时的（正确）过程是人们通常期望的过程：只需要进行一个编码步骤。

也许这并不太令人困惑。但是所有的混乱或困难都是由于使用了一个应该是 HTML 编码的分隔符。因此'&'是罪魁祸首。分号可以解决所有这些复杂问题。

（我会指出，我上面的 3 步与 2 步流程通常大多数应用程序需要多少步。但是，对于完全健壮的代码，无论使用哪种分隔符，都需要所有 3 个步骤。但根据我的经验，大多数实现是草率且不健壮的。因此，使用分号作为查询字符串分隔符将使更多人的生活更轻松，网站更少，并且互操作错误，如果每个人都默认使用分号而不是 & 号。）

Answer 4

W3C Recommendation from 1999 已过时。根据2014 W3C Recommendation，目前的状态是分号现在非法作为参数分隔符：

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

1. 让字符串成为将字符串有效负载严格拆分为 U+0026 AMPERSAND 字符 (&) 的结果。

换句话说，?foo=bar;baz 表示参数foo 将具有值bar;baz；而?foo=bar;baz=sna 应该导致foo 成为bar;baz=sna（虽然技术上是非法的，因为第二个= 应该转义为%3D）。