21

或者，也许你称它为“尖锐”——# 符号。

我遇到过一个实例，其中 #! 和 # 在单个 URL 中同时使用。通过阅读其他文章，包括 RFC，我无法理解这是否是合法的组合。当遇到这样的页面 Mozilla 浏览器（在这种情况下为 Iceweasel）显示 URL 有 2 个 #，而 Chrome 只显示一个，但很快就死掉了（包含该页面的选项卡变得无响应并崩溃 - 但它可能没有连接） .

现在，我的问题是，在一个 URL 中同时包含两者是否合法，是否可能合法且多余（应该规范化），还是只是 Mozilla 浏览器中的一个错误？所以，假设我正在发出 AJAX 请求，或者试图浏览浏览器历史记录 - 如果遇到这种情况，我该怎么办？

网址中的双哈希

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

另外：https ://developers.google.com/webmasters/ajax-crawling/docs/specification Google 爬虫如何看待事物。

4

3 回答 3

19

片段的格式只允许使用斜杠、问号和pchars。如果您查看 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
于 2012-06-01T13:15:52.990 回答
4

我的回答很明确，至少在参考RFC 3986时是这样。但你要看的不仅仅是3.4

第 3 节定义了 URI 的结构如下：

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

（我只取了上半部分，与 URL 相关）

因此，要回答您的问题，您必须查看所有部分：

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

因此，到目前为止，除了终止 URI 之外，不允许使用任何散列，如果想使用至少一个散列，这不是我们想要的；-)

最后：

  • 该片段'由数字符号（“#”）的存在表示'并且也仅由pchar、“/”或“?”组成。它“在 URI 的末尾终止”。

综上所述：在一个兼容的 URL（或 URI）中，只允许一个“#”作为 URL-fragment 的标记。特别是应该在路径中的哈希符号（至少从外观上看，因为后面有斜线）是有问题的，因为它们正式终止了路径部分。

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

于 2020-07-16T16:39:03.947 回答
2

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

那种网址：

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

对我来说似乎真的很困惑，对普通用户甚至搜索引擎来说会更加困惑。

于 2012-06-01T13:26:28.760 回答