为什么开发人员要在每个相对路径的开头放置一个正斜杠?
我正在为一位朋友检查一些代码,发现构建其网站的开发人员开始了每一个相关的 src
、href
和 include
带有正斜杠 /
。
例如:
src="/assets/js/jquery.js"
我以前从未见过这个。所以我的问题是,为什么开发人员要在相对路径的开头放置正斜杠 /
?
I am examining some code for a friend, and have found that the developer who built his site began each and every relative src
, href
, and include
with a forward slash /
.
For example:
src="/assets/js/jquery.js"
I have never seen this before. So my question is, why would a developer place a forward slash /
at the start of a relative path?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
这样做是为了根路径(使其成为绝对路径)。
它确保路径不是相对的,而是从站点的根目录读取的。
这允许人们移动文件而不必更改到不同资源的链接。
使用您的示例:
如果引用文件位于
/pages/admin/main.html
(例如)中,使用相对路径,您将使用:假设您将文件移动到子目录。原始根路径不需要更改,但相对路径需要更改为:
It's done in order to root the path (making it an absolute path).
It ensures that the path is not relative but read from the root of the site.
This allows one to move a file around and not have to change the links to the different resources.
Using your example:
If the referencing file is in
/pages/admin/main.html
(for example) using relative paths you would use:Suppose you move the file to a child directory. No changes would be needed for with the original rooted path, but the relative one would need to change to:
添加 @Oded 的回答,斜杠使 URL 绝对化。
例如:
这转化为:
但是如果没有斜杠,事情会变得有点不同:
这告诉浏览器在当前文件夹(而不是根文件夹)中查找目录
foo 然后是后续目录和文件。
另外,以这个 HTML 为例:
如果您将 HTML 文件移动到另一个文件夹中,则脚本将不会加载,因为
foo.js
不会随 HTML 文件一起移动。但如果您使用绝对 URL:
那么无论 HTML 文件位于何处,JS 文件都会从
http://www.example.com/foo.js
加载完全 。Adding on @Oded's answer, the slash makes the URL absolute.
For example:
This translates to:
But without the slash, things become a bit different:
This tells the browser to look in the current folder (not the root folder) for the directory
foo
and then the subsequent directories and the file.Also, take for instance this HTML:
If you move the HTML file into another folder, then the script will not load, as
foo.js
isn't being moved with the HTML file.But if you use an absolute URL:
Then the JS file is loaded EXACTLY from
http://www.example.com/foo.js
no matter where the HTML file is.这是为了确保资产来自 Web 服务器的“根”。
例如
主机是 www.example.com
URL 变为
www.example.com/assets/js/jquery.js
我对我希望确保在其自己的虚拟主机上运行的项目执行此操作。
问题实际上归结为这些资产包含在哪里。例如,如果资产包含在 /help/pages/faq 中,那么当站点托管在不变的主机(例如 example.com)上时,开发人员可以确保该路径能够正常工作。
使用相对路径“assets/js/jquery.js”的问题是,如果资产包含在 /help/pages/faqs 中,则路径将变得相对于该起点,例如 /help/pages/faqs/assets /js/jquery.js
This is to ensure the asset comes from the "root" of the web server.
e.g.
Host is www.example.com
URL becomes
www.example.com/assets/js/jquery.js
I do this with project I want to ensure live on their own virtual host.
The issue really comes down to where those assets are being included. For example if the asset is being included from /help/pages/faq then the developer can be sure the path will work correctly when the site is hosted on a non changing host, e.g. example.com.
The issue of using relative paths, 'assets/js/jquery.js' is that if the assets are included from the /help/pages/faqs then the path becomes relative to that starting point, e.g. /help/pages/faqs/assets/js/jquery.js
这有点偏离主题,但如果您的应用程序有可能在子路径下的反向代理(例如使用 apache2 或 nginx)后面提供服务,您应该尽量避免绝对路径。
例如,如果您在 https://example.com/ 上引用“/style.css”,并且您尝试过将其隐藏在 https://proxy.example.com/example/ 的反向代理后面,你的绝对参考会被破坏。当浏览器应该请求“https://proxy.example.com/example/style.css”时,它会向“https://proxy.example.com/style.css”发出请求。
来自前导正斜杠的无意绝对路径对于反向代理来说是一场噩梦。
This is a bit off topic, but if there is any chance that your application will ever be served behind a reverse proxy (eg. using apache2 or nginx) under a sub-path, you should try to avoid absolute paths.
For example, if you reference "/style.css" on https://example.com/, and you tried to hide it behind a reverse proxy at https://proxy.example.com/example/, your absolute reference would break. The browser would make the request to "https://proxy.example.com/style.css" when it should have requested "https://proxy.example.com/example/style.css".
Unintentional absolute paths from a leading forward slash are a nightmare for reverse proxies to deal with.
是的 user1869743,但您可以使用:
<代码>
Yes user1869743, but you can use: