简而言之,HTML 是一团糟(由于它的宽大处理),使用分号有助于简化这一点。
为了使用分号作为分隔符,我不知道 .NET 是否允许这种自定义,或者我们开发人员是否需要编写自己的方法来处理 QueryString。.NET 确实让我们可以访问原始 QueryString,我们可以从那里运行它。这就是我所做的。我编写了自己的方法,这并不太难,但是花费了大量的测试时间和调试,其中一些是微软在处理代理对时甚至不符合 Web 标准的错。我确保我的实现适用于所有 Unicode 字符,包括多语言平面(因此适用于中文和日文字符等)。
在添加我自己的发现之前,我还想确认并包括罗琳、吉文和贝尼贝拉在罗琳的回答中指出的重要信息以及他们对此类回答的评论:在 HTML 中不逃避它们是不正确的,但它通常有效,但这只是因为解析器是如此宽容。有了这个,我还解释了为什么这会导致编码不当的错误(这可能是大多数开发人员的受害者)。
不能依赖在 QueryStrings 中不正确编码 & 符号的这种宽容,有时这种宽容会导致令人讨厌的错误。例如,假设一个 QueryString 传递一个随机的 ASCII 字符串(或用户输入)并且它们没有正确编码。然后'amp;' '&' 之后的内容被解码,意外的结果是 'amp;' 本质上是“吞下”。(通过吞下,我的意思是它被“吃掉”或丢失。)一个实际的使用场景是当用户被要求输入进入数据库的输入并且用户输入 HTML(如 StackOverflow 中的此处)但因为它不是正确发布然后讨厌的错误发展。
';' 的真正优势 分隔符很简单:对与号分隔的 QueryStrings 的正确编码对 HTML 页面中的 URL 字符串(以及 XML 中的 URL 字符串)采取了两个复杂步骤。首先键和值应该是 URL 编码,然后全部连接,然后整个 QueryString 或 URL 应该是 HTML 编码(或者对于 XML,使用与 HTML 编码非常相似的编码进行编码)。另外不要忘记,HTML 编码和 URL 编码的编码过程是不同的,重要的是它们是不同的。开发人员需要注意两者之间的关系。而且由于它们相似,因此新手程序员将它们混为一谈的情况并不少见。
潜在问题 URL 的一个很好的示例是在 QueryString 中传递两个名称/值时:
在这里,使用 '&' 作为分隔符,然后 '?a=me+%26+you&b=you+%26+me' 是一个正确的查询字符串,但在写入 HTML 源代码之前它也应该是 HTML 编码的。这对没有错误很重要。大多数开发人员不小心执行这两个步骤:首先对键和值进行 URL 编码,然后对 HTML 源代码中的完整 URL 进行 HTML 编码。难怪为什么,当我不得不坐下来认真思考这个过程并彻底检验我的结论时。当名称值为 'year=año' 或更复杂时,我们需要使用代理对来表示它们的中文或日文字符时的成像!
对于上面相同的 a 和 b 键值对,使用 ';' 时 作为分隔符,该过程要简单得多。事实上,与号分隔符使该过程比使用分号分隔符复杂两倍多!这是使用“;”表示的相同信息 作为分隔符:'?a=me+%26+you;b=you+%26+me'。我们注意到唯一的区别是字符串中没有'&'。但是使用这个';' 分隔符意味着不需要对 URL 或 QueryString 进行 HTML 编码的第二个过程。现在想象一下,如果我正在编写 HTML 并且想要正确的 HTML 并且需要编写 HTML 来解释这一切!所有这些带有 '&' 的 HTML 编码确实增加了很多复杂性(对于许多开发人员来说,也有很多混乱)。
新手开发人员根本不会对 QueryString 或 URL 进行 HTML 编码,这在 ; 是分隔符。但是当 & 符号编码不正确时,它会给错误留下空间。所以 '?someText=blah&blah' wud需要适当的编码。
同样在 .NET 中,我们可以为我们的方法编写 XML 文档。好吧,就在今天,我写了一个小解释,使用了上面的 'a=me+%26+you&b=you+%26+me' 示例。在我的 XML 中,我必须手动输入所有这些 & XML 的字符实体。在 XML 文档中,它很挑剔,因此必须正确编码 & 符号。但是 HTML 的宽大处理增加了歧义。
也许这并不太令人困惑。但是所有的混乱或困难都是由于使用了一个应该被 HTML 编码为分隔符的字符,因此 '&' 是罪魁祸首。分号消除了所有这些复杂性。
最后一个考虑:由于 '&' 分隔符使这个过程复杂得多,我难怪微软在 QueryStrings 中实现代理对仍然不遵循官方规范。而且,如果您编写自己的方法,则必须考虑 Microsoft 对百分比编码代理对的错误使用。官方规范禁止在 UTF-8 中对代理对进行百分比编码。因此,任何编写自己的方法来处理所有 Unicode 字符的人,都要小心这一点。