昨天早上我注意到 Google 搜索正在使用哈希参数：
这似乎与更常见的搜索相同（使用 search?q=Client-side+URL+parameters）。 （在使用他们的表单进行搜索时，他们似乎不再默认使用它。）
他们为什么要这样做？
更一般地说，我看到很多网站上都出现了哈希参数。这是一件好事吗？是黑客吗？是否背离了 REST 原则？我想知道是否应该在 Web 应用程序中使用这种技术，以及何时使用。
有一个discussion by the W3C of different use cases，但我看不出哪个适用于上面的示例。他们似乎也对建议犹豫不决。
【问题讨论】：
标签： url hash parameters
Google 有许多实时实验功能，可根据您的偏好、位置和其他因素（可能也是随机选择）开启/关闭。我很确定您提到的也是其中之一。
当使用哈希而不是查询字符串参数时，在后台发生的情况是，它使用 JavaScript 查询“真实” URL (http://www.google.com/search?q=hello)，然后使用内容修改现有页面。由于页面不必完全重新加载，因此这对用户的响应会更加灵敏。散列的原因是为了维护浏览器历史记录和状态。如果你去http://www.google.com/#q=hello你会发现你实际上得到了“你好”的搜索结果（即使你的浏览器真的只请求http://www.google.com/）关闭JavaScript，它不会工作，但是你' d 只是获得谷歌首页。
随着动态网站成为常态，哈希越来越多地出现。哈希完全在客户端维护，因此在更改时不会引起服务器请求。这使它们成为维护 Web 应用程序不同状态的唯一地址的绝佳候选者，同时仍位于完全相同的页面上。
我自己最近越来越多地使用它们，您可以在这里找到一个示例：http://blixt.org/js -- 如果您查看该页面上的“哈希”库，您会看到我的支持实现跨浏览器的哈希值。
这里有一个使用哈希存储状态的小指南：
在散列中维护状态意味着您的应用程序（我将其称为应用程序，因为您通常只在更高级的 Web 解决方案中将散列用于状态）依赖于 JavaScript。如果没有 JavaScript，哈希的唯一功能就是告诉浏览器在页面的某处查找内容。
一旦您实现了一些 JavaScript 来检测散列的更改，下一步就是将散列解析为有意义的数据（就像您使用查询字符串参数一样。）
一旦您获得了哈希中的状态，您的代码（或您的用户）就可以对其进行修改，以表示您的应用程序中的当前状态。您想要这样做的原因有很多。
一个常见的情况是页面只有一小部分会根据变量进行更改，并且重新加载整个页面以反映该更改是低效的（例如：您有一个带有标签的框。活动标签可以在哈希中识别。）
其他情况是当您在 JavaScript 中动态加载内容时，您想告诉客户端要加载什么内容（例如：http://beta.multifarce.com/#?state=7001，将带您到文本冒险中的特定点。）
如果您查看我的“JavaScript 领域”，您会看到一个边界线过大的案例。我这样做只是因为我想在该页面中尽可能多地塞入 JavaScript 动态。在一个正常的项目中，我会对何时执行此操作持保守态度，并且仅在您看到以下一个或多个方面发生积极变化时才执行此操作：
这是一个很大的威慑。虽然您可以放心地依靠 99% 的用户拥有能够使用带有哈希状态的页面的浏览器，但在很多情况下您根本无法依靠它。例如，搜索引擎爬虫。虽然 Google 一直在努力让他们的爬虫与最新的网络技术一起工作（你知道他们索引 Flash 应用程序吗？），但它仍然不是一个人，也无法理解某些事情。
基本上，您正处于兼容性和用户体验之间的十字路口。
但是你总是可以在两者之间建立一条道路，这当然需要更多的工作。用不那么隐喻的术语：实现这两种解决方案，以便每个输出相关内容的客户端 URL 都有一个服务器端 URL。对于兼容的客户端，它会将它们重定向到哈希 URL。这样，Google 可以索引“硬” URL，当用户点击它们时，他们会得到动态的东西！
【讨论】：
wget blixt.org/js/projects.json 而不是 blixt.org/js 对于我的文字冒险游戏：beta.multifarce.com/api/get_frame?frame=7001 如果你想为搜索引擎提供数据，你可以有公共路径从将用户引导到“正确”路径的相同数据生成的 HTML 文档。
最近，谷歌也停止在搜索结果中提供直接链接，而是提供重定向。
我相信两者都与收集使用统计信息、同一用户执行了哪些搜索、以什么顺序、用户关注的搜索结果等有关。
附：现在，这很有趣，直接链接又回来了。我绝对记得在过去几周内只看到了重定向。他们肯定是在尝试一些东西。
【讨论】：