URL中的多个#号

Question

或者你称之为“井号”——#符号。

我曾遇到过一个情况，即在单个URL中同时使用#!和#。通过阅读其他文章，包括RFC，我无法理解这种组合是否合法。在遇到这样的页面时，Mozilla浏览器（这里是Iceweasel）将URL显示为具有2个“#”，而Chrome仅显示一个“#”，但不久后就崩溃了（包含页面的选项卡变得无响应并崩溃了——但这可能与此无关）。

现在，我的问题是，在一个URL中同时使用两者是否合法，它可能是合法且多余的（应该被规范化），还是只是Mozilla浏览器的一个bug？那么，假设我正在进行AJAX请求或尝试导航浏览器历史记录——如果我遇到这种情况，我应该怎么办？

RFC-3986：https://www.rfc-editor.org/rfc/rfc3986#section-3.4 ，这应该澄清一下...以防万一。

另外：https://developers.google.com/webmasters/ajax-crawling/docs/specification，Google爬虫如何看待这些问题。

- user797257

---

可能是URL片段（#）允许的字符的重复问题。 - HostileFork says dont trust SE

^-- 标记为重复，优先引导人们到其他问题，因为此处的答案没有给出允许字符的具体列表和理由，而是让人去寻找“pchar”的含义。 - HostileFork says dont trust SE

Answer 1

片段格式只允许斜杠、问号和pchar。如果您查阅RFC，将会发现井号（#）不是一个有效的pchar。

然而，浏览器将尽力通过将重复的井号视为转义来读取非有效的URL。您可以通过检查window.location.hash的值（在IE，Firefox和Chrome中）来验证这一点。

http://www.example.com/hey#foo#bar

这与 window.location.hash 相同。

http://www.example.com/hey#foo%23bar

- apsillers

---

不，ABNF 很清楚地表明在片段中不能有未转义的 "#"。 - Julian Reschke

啊，那么这只是浏览器强制有效性的情况，将多个哈希视为已转义。 - apsillers

刚刚发现这个链接，可能是你回答的一个很好的补充：https://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Nov/0043.html - Naeio

Answer 2

我的答案很明确，至少在涉及RFC 3986时是不行的。但你必须看的不仅仅是3.4。 第3节将URI的结构定义如下：

     foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment

我只需要翻译上半部分，与URL有关。 因此，要回答您的问题，您需要查看所有部分：

• 方案可能不包含井号（仅限 ALPHA *（ALPHA / DIGIT / "+" / "-" / "."）
• 权威可能不包含井号（我在这里不做详细介绍），并且甚至“由下一个斜杠（"/"），问号（"?"）或井号（"#"）”结束。
• 路径由以斜杠（“/”）字符分隔的一系列路径段组成。路径段反过来只能由pchar组成，例如请参见此答案。所以这里没有井号！它也将被“第一个问号（“？”）或数字符号（“#”）或URI的结尾”终止。
• 查询部分（由第一个“？”指示）只能由pchar，“/”或“？”组成，并将由数字符号（“#”）字符或URI的结尾终止。

所以，目前除了用于终止URI的哈希之外，不允许使用其他哈希，如果想要使用至少一个哈希，则不符合我们的要求；-)

最后：

• fragment由数字符号("#")表示，并且仅由pchar、"/"或"?"组成。它由URI的结尾终止。

总之： 在符合规范的URL（或URI）中只允许一个"#"作为URL片段的标记。 特别是那些应该位于路径中的哈希符号（至少从外观上来看，因为后面有斜杠）会导致问题，因为它们正式终止了路径部分。

这可能会在单页应用程序中引起问题，因为在此情况下，哈希后的导航是在客户端而不是服务器上完成的。在这种情况下，SPA应确保在接收到URL的其余部分时正确处理它，其中可能包括（浏览器特定的）URL编码查询和片段。

- Zaphoid

Answer 3

正如@apsillers所提到的，这可能是合法的。但是，除非必要，否则我会避免使用它，因为它可能会导致url方面的某些混淆。

这种类型的url：

http://www.example.com/hey#foo#bar

对我来说似乎非常令人困惑，对于普通用户和搜索引擎来说可能会更加困惑。

- nebulousGirl