分号作为URL查询分隔符
删除死了Imageshack链接 – ＆符号与分号
尽pipe强烈build议（ W3C源代码 ，通过维基百科 ）为Web服务器支持分号作为URL查询项目的分隔符（除了＆符号之外），但似乎并没有遵循。
例如，比较
http://www.google.com/search?q=nemo& oe = utf-8
http://www.google.com/search?q=nemo ; OE = UTF-8
结果。 （在后一种情况下，分号是， 或正在编写此文本时 ，将其视为普通string字符，就像URL是： http : //www.google.com/search?q=nemo ％3B oe = utf-8 ）
虽然我尝试的第一个URLparsing库，但performance良好：
>>> 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']} 什么是接受分号作为分隔符的当前状态，什么是潜在的问题或一些有趣的笔记？ （从服务器和客户端的angular度来看）
从1999年开始的W3C推荐标准已经过时了。 根据2014年W3C推荐标准 ，目前的状态是分号现在是非法的参数分隔符：
为了解码application / x-www-form-urlencoded载荷，应该使用下面的algorithm。 […]该algorithm的输出是名称 – 值对的sorting列表。 […]
- 让string成为严格分割U + 0026 AMPERSAND字符（＆）上的string有效负载的结果。
换句话说， ?foo=bar;baz表示参数foo将具有值bar;baz ; 而?foo=bar;baz=sna导致foo成为bar;baz=sna （虽然技术上是非法的，因为second =应该转义为%3D ）。
只要您的HTTP服务器和您的服务器端应用程序接受分号作为分隔符，您应该很好。 我看不到任何缺点。 正如你所说， W3C规范在你身边 ：
我们推荐HTTP服务器实现者，特别是CGI实现者支持使用“;” 代替“＆”来节省作者以这种方式逃避“＆”字符的麻烦。
我同意Bob Aman。 W3C规范的devise目的是为了更容易地使用看起来像表单GET请求的URL（例如http://www.host.com/?x=1&y=2 ）来使用定位超链接。 在这种情况下，符号与字符实体引用的系统冲突，这些引用都以"符号（例如" ）开头。 因此，W3Cbuild议Web服务器允许使用分号作为字段分隔符而不是和号，以便更容易编写这些URL。 但是这个解决scheme要求作者记住，＆符号必须被某种东西替代， 是一个同样有效的字段分隔符，即使网页浏览器在提交表单时在URL中普遍使用＆符号。 记住用& 在这些链接中，就像文档中其他地方所做的一样。
更糟糕的是，在所有Web服务器允许分号作为字段分隔符之前，URL编写者只能对某些主机使用这个快捷方式，并且必须使用& 为他人。 如果给定主机停止允许分号分隔符，那么他们也将不得不稍后更改它们的代码。 这当然比单纯使用& ，这将永远为每个服务器工作。 这反过来消除了networking服务器允许分号作为字段分隔符的动机。 为什么麻烦呢，每个人都已经在改变＆符号& 而不是; ？
总之，HTML是一个很大的混乱（由于其宽大），并使用分号有助于简化这一个很大。 我估计，当我把我发现的复杂因素考虑在内时，使用“＆”符号作为分隔符会使整个过程比分隔符使用分号复杂三倍！
我是一个.NET程序员，据我所知，.NET本身并不允许';' 分隔符，所以我写了我自己的parsing和处理方法，因为我看到使用分号的巨大价值，而不是已经有问题的使用＆符号分隔符的系统。 不幸的是，非常值得尊敬的人（比如@Bob Aman在另一个答案中）没有看到分号用法为什么比使用＆符号更加优越和简单。 所以我现在分享几点，也许说服其他可敬的开发人员谁不承认使用分号的价值：
在HTML页面中使用像'？a = 1＆b = 2'这样的查询string是不合适的（没有使用HTML编码），但大部分时间工作。 然而，这只是由于大多数浏览器容忍，并容忍可以导致难以发现的错误，例如，键值对的值发布在HTML页面URL没有适当的编码（直接作为'？ HTML源代码中的a = 1＆b = 2'）。 一个像'谁=我+ +你'的查询string也是有问题的。
我们人们可以有偏见 ，可以整天不同意我们的偏见，所以认识到我们的偏见是非常重要的。 例如，我同意我只是想与';'分离。 看起来比较干净。 我同意我的“清洁”意见纯粹是一种偏见。 而另一位开发人员可能有同样相反且同样有效的偏见。 所以我对这一点的偏见并不比对立的偏见更正确。
但是，由于分号的无偏见的支持使得每个人的生活更加容易，从长远来看，在考虑到整个图景的时候是不能正确的争议的。 总之，使用分号确实让每个人都变得更简单，只有一个例外：适应新事物的一个小障碍。 就这样。 做任何改变总是比较困难的。 但是，与继续使用的难度相比，变更的难度更大。
使用; 作为QueryString分隔符使得它更简单。 与使用分号相比，“和号”分隔符的编码难度要高出一倍以上。 （我认为）大多数实现没有正确编码，所以大多数实现不是两倍复杂。 但是，追踪并修复这些错误会导致生产力的下降。 在这里，我指出了当＆是分隔符时，正确编码QueryString所需的2个独立的编码步骤：
- 步骤1：URL编码查询string的键和值。
- 步骤2：在步骤1中进行URL编码后，将键和值连接成“a = 1＆b = 2”。
- 第3步：然后HTML将整个QueryString编码到页面的HTML源代码中。
因此，为了正确（无错误）的URL编码，必须进行两次特殊的编码，而不仅仅是这样，编码是两种截然不同的编码types。 第一个是URL编码，第二个是HTML编码（用于HTML源代码）。 如果这些不正确，那么我可以find你的错误。 但是，步骤3与XML不同。 对于XML，则需要XML字符实体编码（这几乎是相同的）。 我的意思是，最后的编码依赖于URL的上下文，无论是在HTML网页还是在XML文档中。
现在用更简单的分号分隔符，这个过程就像一个人想的那样：
- 1：URL对键和值进行编码，
- 2：将这些值连接在一起。 （没有步骤3的编码）
我认为大多数web开发人员跳过第3步，因为浏览器是如此宽松。 但是，如果发现这些错误或者用户在这些错误不存在的情况下无法执行任何操作或编写错误报告等，则会导致错误和更多的复杂性。
实际使用中的另一个复杂情况是在C＃和VB.NET中的源代码中编写XML文档标记。 由于＆必须被编码，从字面上看，这是一个真正的拖累，我的生产力。 额外的步骤3使得读取源代码变得更加困难。 所以这个难以阅读的赤字不仅适用于HTML和XML，也适用于其他应用程序，如C＃和VB.NET代码，因为它们的文档使用XML文档。 所以步骤＃3编码复杂化也扩展到其他应用程序。
所以总之，使用; 作为分隔符是很简单的，因为使用分号时的（正确）过程是一个wud通常期望的过程：只有一个编码步骤需要发生。
也许这不是太混乱。 但是所有的困惑或困难都是由于使用了一个分离字符，而这个字符是HTML编码的。 因此'＆'是罪魁祸首。 而分号解除了所有的复杂性。
