URL 中的尾随 & 符号合法吗？
像这样的 URL
http://localhost/path?a=b&c=d
很好 - 但是带有尾随 & 符号的同一 URL 的状态是什么？
http://localhost/path?a=b&c=d&
例如，Java Servlet API 允许它，而 Scala 的 Spray 不允许（即它会抛出错误） 。
我尝试在 URI 语法规范 中找到答案，但不确定如何来解析他们的语法。
A URL like
http://localhost/path?a=b&c=d
is fine - but what is the status of the same URL with a trailing ampersand?
http://localhost/path?a=b&c=d&
For example the Java Servlet API allows it where Scala's Spray does not (ie it throws an error).
I've tried to find the answer in the URI syntax spec, but not sure how to parse their grammar.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
URI 语法规范适用于通用 URI。它允许查询中的任何内容。我不知道有任何规范实际指定了与号分隔的键=值对。我相信这只是惯例。例如，我知道 PHP 提供了使用不同分隔符的选项。但现在，每个人在需要键值对时都使用“&”分隔的东西。您仍然偶尔会遇到仅将其用作简单字符串的情况，例如 http://example.com/?example< /a>.这是完全正确的。
不过，基本答案是
&在查询字符串中的任何位置（包括末尾）都有效。消除 RFC 语法的迷雾，或为什么
&在查询字符串中的任何位置都有效：首先，您有
（因此查询字符串由任意数量的
pchar以及文字斜杠和问号。）回过头来，你
还有更早的
所以文字
&位于sub-delims这是在pchar，因此它在query中有效The URI syntax spec is for generic URIs. It allows anything in the query. I am not aware of any specification which actually specifies ampersand-separated key=value pairs. I believe it is merely convention. I know that PHP, for example, offers an option for using a different separator. But now, everyone uses ampersand-separated things when they want key-value pairs. You still occasionally come across things which use it for just a simple string, e.g. http://example.com/?example. This is perfectly valid.
The basic answer, though, is that
&is valid anywhere in the query string, including at the end.Demistifying the RFC syntax, or Why
&is valid anywhere in the query string:First, you have
(So a query string is made of any number of
pcharand literal slashes and question marks.)Going back, you have
And earlier still
So a literal
&is insub-delimswhich is inpchar, so it's valid inquery我认为有一条不成文的规则，即所有 RFC 都必须几乎无法理解。你不是第一个无法解析语法的人 - 以我的愚见 - Spray 也失败了。
尾随 & 符号没有任何问题。它是URI中的合法字符，用于分隔参数。尾随的 & 符号可能毫无意义，但它并非无效。喷雾应该（再次，仅在我看来）简单地忽略它。
I think there is an unwritten rule that all RFCs must be near impossible to understand. You're not the first person unable to parse the grammar and - in my humble opinion - Spray also failed too.
There is nothing wrong with a trailing ampersand. It is a legal character in the URI used to separate parameters. A trailing ampersand may be pointless, but it isn't invalid. Spray should (again, only in my opinion) be simply ignoring it.
如果您的纯文本电子邮件中有类似以下的网址：
请点击此链接
https://server/doc?param=test.重置您帐户的密码。它成为一个有用的功能，因为如果最后一个参数以“.”（点+空格）结尾并放置在电子邮件中，则所有类型的邮件客户端都会假定该点正在结束一个句子，并将其从可单击的链接中排除。如果他们检测到 URL，则添加。
所有邮件客户端均不支持将链接放在双引号或尖括号之间，并且默认 URL 编码会留下点，因为它不是保留的 URI 字符...
我最终附加了一个尾随与符号“&”到解决这个问题的网址，你可以说我疯了，但它确实有效。
If you have a url like the following in a plain-text email:
Please follow this link
https://server/doc?param=test.to reset the password of your account.It becomes a useful feature since if the last parameter ends with ". " (dot + space) and is placed in an e-mail, all kinds of mail clients assume that the dot is ending a sentence and exclude it from the clickable link they add if they detect a URL.
Putting the link between double-quotes or angle-brackets isn't supported in all mail clients and default URL encoding leaves the dot as it is not a reserved URI character...
I ended up appending a trailing ampersand "&" to the URL to fix this, call me crazy but it works.