shebang/hashbang 是做什么用的?

发布于 2024-12-11 07:08:59 字数 67 浏览 0 评论 0原文

除了使 AJAX 内容可供 Google 抓取外,shebangs/hashbangs 是否还有其他用途?或者就是这样?

Is there any other use for shebangs/hashbangs besides for making AJAX contents crawlable for Google? Or is that it?

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

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

发布评论

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

评论(1

又怨 2024-12-18 07:08:59

在 URL 中使用的哈希早在 Ajax 发明之前就已经存在了。

它最初的目的是作为页面内子部分的引用。在这种情况下,例如,您将在页面顶部有一个目录,每个目录都是指向同一页面的某个部分的哈希链接。单击这些链接时,页面会向下(或向上)滚动到相关标记。

当浏览器收到包含哈希值的 URL 时,仅将哈希值之前的地址部分作为页面请求发送到服务器。哈希部分由浏览器保留以自行处理并将页面滚动到相关位置。

这就是哈希语法的最初用途,因此这是对您问题的直接答案。但我会继续解释一下我们是如何从那里走到现在的……

当 Ajax 发明时,人们开始想找到方法在他们的网站上拥有一个页面,但仍然有人们可以访问的链接点击外部可直接进入相关内容。

开发人员很快意识到现有的哈希语法可以为他们做到这一点,因为可以从 JavaScript 中读取 URL 的哈希值。然后你所要做的就是当它看到一个哈希值时阻止它滚动(这很容易),并且你已经得到了一些被浏览器有效忽略的 URL,但可以由 javascript 读取和写入;非常适合与 Ajax 一起使用。事实上,谷歌在其搜索中包含 URL 的哈希部分一开始只是一个幸运的奖励,但随着该技术变得更加广泛,它变得非常重要。

我注意到人们将此哈希语法称为“shebang”或“hashbang”,但从技术上讲这是不正确的;它只是一个相关的哈希值——“hashbang”一词的“bang”部分指的是感叹号(“bang”是印刷行业的术语)。有些URL确实可能会在hash后面添加感叹号,但只有hash是与浏览器相关的;后面的字符串完全由网站作者决定;它可能包含感叹号,也可能不包含感叹号,具体取决于他们的选择,但无论哪种方式,浏览器都不会对其执行任何操作。如果您愿意,可以随意将其称为 hashbang 或 shebang,但要明白只有哈希才是重要的。

实际术语“shebang”或“hashbang”可以追溯到更早的时期,并且确实指的是 #! 语法,但不是在 URL 的上下文中。

该术语的原始含义是在 Unix 脚本文件的开头使用这些符号,以告诉脚本处理器该脚本是用什么编程语言编写的。

所以这确实是您问题的答案,就像您所用的方式一样措辞,但可能不是你的意思,因为它与 URL 完全无关。

The hash when used in a URL has existed since long before Ajax was invented.

It was originally intended as a reference to a sub-section within a page. In this context, you would, for example, have a table of contents at the top of a page, each of which would be a hash link to a section of the same page. When you click on these links, the page scrolls down (or up) to the relevant marker.

When the browser receives a URL with a hash in it, only the part of the address before the hash is sent to the server as a page request. The hash part is kept by the browser to deal with itself and scroll the page to the relevant position.

This is what the hash syntax was originally intended for, so this is the direct answer to your question. But I'll carry on a bit and explain how we got from there to where we are now...

When Ajax was invented, people started wanting to find ways to have a single page on their site, but still have links that people could click on externally to get directly to the relevant content.

Developers quickly realised that the existing hash syntax could do this for them, because it is possible to read the URL's hash value from within javascript. All you have to do then is stop it from scrolling when it sees a hash (which is easy enough), and you've got a bit of the URL which is effectively ignored by the browser, but can be read and written to by javascript; perfect for use with Ajax. The fact that Google includes the hash part of a URL in its searches was just a lucky bonus to begin with, but has become quite important since the technique has become more widespread.

I note that people are calling this hash syntax a "shebang" or "hashbang", but technically that's incorrect; it's just a hash that is relevant -- the 'bang' part of the word "hashbang" refers to an exclamation mark ('bang' is a printing industry term for it). Some URLs may indeed add an exclamation mark after the hash, but only the hash is relevant to the browser; the string after it is entirely up to the site's authors; it may include an exclamation mark or not as they choose, but either way the browser won't do anything with it. Feel free to keep calling it a hashbang or shebang if you like, but understand that only the hash is of significance.

The actual term "shebang" or "hashbang" goes back a lot further, and does refer to a #! syntax, but not in the context of a URL.

The original meaning of this term was where these symbols were used at the beginning of a Unix script file, to tell the script processor what programming language the script is written in.

So this is indeed an answer to your question, the way you've worded it, but is probably not what you meant, since it has nothing to do with URLs at all.

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