hashbang 斜线还是不斜线?

发布于 2024-10-25 06:52:26 字数 348 浏览 2 评论 0原文

我们应该使用 site.com/#!/blog 还是 site.com/#!blog

我知道没有实际的区别,但是作为一个网络开发者社区,仍然应该有一个传统的标准,以便用户可以轻松记住 URL。如果没有既定的标准,理想情况下,有人会发布一个有利于一个人的答案,另一个人会发布另一个有利于另一个人的答案,一个人会比另一个人获得更多的选票......

我个人更喜欢:site.com /#!blog 只是因为它更短。然而,我看到许多其他网站使用其他变体。

顺便说一句,如果您的第一反应是指示我们不要使用 hashbang,那么这个问题不适合您,请别打扰我们。

Should we do site.com/#!/blog or site.com/#!blog?

I understand there's no actual difference, however as a community of webdevelopers there should still be a conventional standard so that users can easily remember the url. If there's no already established standard, ideally someone will post an answer in favor of one and someone will post another in favor of another and one will get a lot more votes than the other...

Personally I prefer: site.com/#!blog simply because it's shorter. However I've seen many other sites use the other variant.

By the way, if your first instinct is to instruct us to not use hashbangs, then this question is not for you, please leave us alone.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

日暮斜阳 2024-11-01 06:52:26

您忘记了 site.com#!blog 的第三个选项。

如果你想获得所有语义,问题就变成了“url 中的‘/’代表什么?”

  • 是否代表物理
    目录? [site.com#!blog]

浏览文件系统时,文件夹之间用斜杠分隔。这也是网络上的自然行为,但路由改变了这一点。

  • 它是否代表了一个层次结构
    内容? [site.com/#!blog]

介绍了内容的层次结构。查询变量不是用问号和与号,而是用斜杠分隔,根据开发人员认为重要的内容创建深层链接结构。

  • 是否代表着分离
    您的网址中的上下文? [site.com/#!/blog]

Stack Overflow 是我所说的“上下文分离”的一个很好的例子。该问题的 URL 是 [http://stackoverflow.com/questions/5414972/hashbang-slash-or-no-slash/]。问题 ID 和问题标题之间不存在斜杠,因为名为 5414972 的文件夹内有一个文件。只有一个问题的 ID 为 5414972,因此对于层次结构来说也不是必需的。我们有意识地选择使用斜杠来分隔 ID 和名称,而不是使用任何其他分隔符,例如连字符、下划线,甚至根本不使用分隔符。非斜杠的分隔符可能会使两个变量变得相似。通过在 hash bang 的两侧添加斜杠,url 变为:

url prefix > ajax爬行表示法>特定页面

而不是

url前缀> ajax抓取表示法和具体页面

根据您的回答“是”(是的,这是主观的),您将得到答案。我认为,当我们仍然无法决定如何格式化日期时,尝试让全世界就这一标准达成一致有点愚​​蠢。

至于最后关于对“哈希爆炸”的不满的小评论,我认为你是在想象。当“哈希刘海”听起来与“闪光刘海”如此相似时,谁会不喜欢它们呢?

You forgot the third option of site.com#!blog.

If you want to get all semantical, the question becomes "what does a '/' represent in a url?"

  • Does it represent a physical
    directory? [site.com#!blog]

When navigating a file system, folders are separated with slashes. This is the natural behavior on the web as well, but routing has changed this.

  • Does it represent a hierarchy of
    content? [site.com/#!blog]

outing introduced hierarchy of content. Instead of question marks and ampersands, query vars were separated with slashes creating a deep link structure based on what the developers feel is important.

  • Does it represent a separation of
    context within your url? [site.com/#!/blog]

Stack Overflow is a good example of what I mean by "separation of context". The URL of this question is [http://stackoverflow.com/questions/5414972/hashbang-slash-or-no-slash/]. The slash between the question ID and the question title isn't there because there is a file inside a folder named 5414972. There is only one question with the ID 5414972 so it isn't necessary for hierarchy either. It was a conscious choice to use a slash to separate the ID and the name rather than using any other delimiter such as a hyphen, underscore, or even no delimiter at all. A delimiter that isn't a slash would probably make the two variables resemble one. By putting slashes on either sides of the hash bang, the url becomes:

url prefix > ajax crawling notation > the specific page

rather than

url prefix > ajax crawling notation and the specific page.

Depending on what you answer yes to (and yes, it's subjective), you will have your answer. I think it's a little silly to try and get the entire world to agree on a standard for this when we still can't decide on how we should format dates.

As for that last little comment about resentment towards the "hash bang", I think you are imagining this. Who wouldn't like "hash bangs" when they sound so similar to "flash bangs"?

墨小墨 2024-11-01 06:52:26

一条斜线就像一只蚂蚁:当你看到它时,你期望看到另一只蚂蚁。

site.com/#!/blog 是正确的,前提是有 site.com/#!/blog/latestsite.com/#!/blog/ archive/october,或者我们未来的类似的东西。

只是我的 0.014185 欧元。

One slash is like one ant: when you see it, you expect to see another.

site.com/#!/blog is correct iff there's a site.com/#!/blog/latest , site.com/#!/blog/archive/october, or something like that in our future.

Just my €0.014185.

画离情绘悲伤 2024-11-01 06:52:26

这取决于你在做什么。如果您基本上只是尝试使用 ajaxify 站点结构,那么在我看来,包含根 / 是有意义的,因此 /#!/blog。弹出窗口、跳转选项卡等可以使用其他结构。

我认为对此不应该有一个常规标准。像 mod_rewrite 这样的工具存在是有原因的:无限的问题有无限的解决方案,并且尝试标准化像 URL 这样复杂的东西是不可能的。

另外,对于任何想知道 hashbang 的合法用途的人:http://code.google.com/web /ajax爬行/

This depends on what you're doing. If you are basically just trying to ajaxify your site structure, then IMO it makes sense to include that root /, so /#!/blog. Popups, jumping through tabs, etc can use the other structure.

I don't believe there should be a conventional standard for this. There's a reason such tools as mod_rewrite exist: there are infinite solutions to infinite problems and attempting to standardize something as complex as URLs is impossible.

Also, for anyone wondering what a legitimate use is for hashbangs: http://code.google.com/web/ajaxcrawling/

几味少女 2024-11-01 06:52:26

使用斜杠的一个优点是更容易解析。无需担心特定浏览器在缺少 ("") 或空的情况下是否返回 """#" hash ("#"),您可以简单地将第一个斜杠作为起点:您不必担心它之前的内容。

var tokens = window.location.hash.split("/").shift();

tokens 变成带有 [#] 的 token 数组!已经不碍事了。当您在哈希中使用斜杠分隔标记的层次结构时特别方便。

但当然,您仍然应该检查剥离的令牌以确保它是有效的 hashbang。

An advantage of using the slash is easier parsing. Without having to worry about whether a particular browser returns a "" or a "#" in case of a missing ("") or empty hash ("#"), you can simply take the first slash as your starting point: You don't have to worry about what's before it.

var tokens = window.location.hash.split("/").shift();

tokens becomes an array of tokens with [#]! already out of the way. Especially handy when you use a hierarchy of slash-delimited tokens in your hashes.

But of course, you should still check the stripped token to make sure it is a valid hashbang.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文