绝对与相对 URL答案

【问题标题】：Absolute vs relative URLs绝对与相对 URL
【发布时间】：2011-01-01 13:58:31
【问题描述】：

我想知道这两种 URL 的区别：相对 URL（用于图片、CSS 文件、JS 文件等）和绝对 URL。

另外，哪个更好用？

【问题讨论】：

seoclarity.net/resources/knowledgebase/…

标签： html url

【解决方案1】：

我应该使用绝对 URL 还是相对 URL？

如果您所说的绝对 URL 是指包含方案（例如 http / https）和主机名（例如 yourdomain.com）的 URL，则永远不要这样做（对于本地资源），因为维护和调试会很糟糕。

假设您在代码中的任何地方都使用了绝对 URL，例如 <img src="http://yourdomain.com/images/example.png">。现在，当你要去的时候会发生什么：

切换到其他方案（例如 http -> https）
切换域名（test.yourdomain.com -> yourdomain.com）

在第一个示例中，您将收到有关页面上请求的不安全内容的警告。因为您的所有 URL 都经过硬编码以使用 http(://yourdomain.com/images/example.png)。当通过 https 运行页面时，浏览器希望所有资源都通过 https 加载，以防止信息泄露。

在第二个示例中，当您的网站从测试环境上线时，这意味着所有资源仍指向您的测试域，而不是您的实时域。

所以要回答您关于使用绝对 URL 还是相对 URL 的问题：始终使用相对 URL（对于本地资源）。

不同的网址有什么区别？

首先让我们看看我们可以使用的不同类型的网址：

http://yourdomain.com/images/example.png
//yourdomain.com/images/example.png
/images/example.png
images/example.png

这些 URL 尝试访问服务器上的哪些资源？

在下面的示例中，我假设网站从服务器上的以下位置运行 /var/www/mywebsite。

http://yourdomain.com/images/example.png

上述（绝对）URL 尝试访问资源/var/www/website/images/example.png。由于上述原因，您总是希望避免使用这种类型的 URL 从您自己的网站请求资源。然而它确实有它的位置。例如，如果您有一个网站http://yourdomain.com，并且您想通过 https 从外部域请求资源，您应该使用它。例如。 https://externalsite.com/path/to/image.png.

//yourdomain.com/images/example.png

此 URL 基于当前使用的方案是相对的，并且在包含外部资源（图像、javascript 等）时几乎总是应该使用。

这种类型的 URL 的作用是使用它所在页面的当前方案。这意味着您在页面 http://yourdomain.com 上，并且该页面上有一个图片标签 <img src="//yourdomain.com/images/example.png">，图片的 URL 将解析为 http://yourdomain.com/images/example.png。
当您在页面http**s**://yourdomain.com 上并且该页面上有一个图片标签<img src="//yourdomain.com/images/example.png"> 时，图片的URL 将解析为https://yourdomain.com/images/example.png。

这可以防止在不需要时通过 https 加载资源，并自动确保在需要时通过 https 请求资源。。

以上网址在服务器端的解析方式与之前的网址相同：

上述（绝对）URL 尝试访问资源/var/www/website/images/example.png。

/images/example.png

对于本地资源，这是引用它们的首选方式。这是基于您网站的文档根目录 (/var/www/mywebsite) 的相对 URL。这意味着当您拥有<img src="/images/example.png"> 时，它将始终解析为/var/www/mywebsite/images/example.png。

如果您在某个时候决定切换域，它仍然可以工作，因为它是相对的。

images/example.png

这也是一个相对 URL，尽管与前一个有点不同。此 URL 相对于当前路径。这意味着它将根据您在站点中的位置解析为不同的路径。

例如，当您在页面 http://yourdomain.com 并使用 <img src="images/example.png"> 时，它会在服务器上按预期解析为 /var/www/mywebsite/images/example.png，但是当您在页面 http://yourdomain.com/some/path 上并且使用完全相同的图像时标记它会突然解析为/var/www/mywebsite/some/path/images/example.png。

什么时候用什么？

在请求外部资源时，您很可能希望使用相对于方案的 URL（除非您想强制使用不同的方案），而在处理本地资源时，您希望使用基于文档根目录的相对 URL。

示例文档：

<!DOCTYPE html>
<html>
    <head>
        <title>Example</title>
        <link href='//fonts.googleapis.com/css?family=Lato:300italic,700italic,300,700' rel='stylesheet' type='text/css'>
        <link href="/style/style.css" rel="stylesheet" type="text/css" media="screen"></style>
    </head>
    <body>
        <img src="/images/some/localimage.png" alt="">
        <script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js" ></script>
    </body>
</html>

一些（有点）重复

【讨论】：

与使用相对 URL 相比，使用绝对 URL 加载页面是否更快？（有没有花时间解决相对路径？）
任何可能的差异都非常小，如果它是可测量的，您不必担心。
将 Google Jquery 包含为无协议的示例：
这个答案假定绝对 URL 不是动态生成的，这解决了提到的每个问题。
J.Money 是正确的。现代 Web 框架具有“反向路由”的概念，允许您创建从一个页面到另一个页面的 URL（它必须是到同一网站中的另一个页面）。这些允许您为 URL 命名，然后使用此名称而不是 URL。这样，如果您想更改 URL，您可以在一个地方更改 URL，因为在其他任何地方您都只能通过其名称来引用该 URL。

【解决方案2】：

一般来说，使用相对 URL 被认为是最佳实践，这样您的网站就不会绑定到当前部署位置的基本 URL。例如，它无需修改即可在 localhost 以及您的公共域上运行。

【讨论】：

+1 我同意。可能有（几次）绝对网址更好，例如在使用 CDN 时，或者如果您需要更改内容网站。搜索域名比搜索相对 URL 恕我直言要容易得多。
出于维护目的，使用root-relative URL 会更容易，而无需使用域名。即在 StackOverflow 上使用根相对 URL '/questions/2005079/absolute-vs-relative-urls' 链接到这个问题。前面的“/”使 URL 相对于根。当您移动文件或更改项目的目录结构时，这种方法会得到回报。
@Baumr 但是你能做到吗？我绝对是使用该方法的粉丝/支持者，但是进入一个更大的框架和大型重构是一项众所周知的令人生畏/可怕的任务。尽管您认为您可能已将它们全部切换，即使在智能 IDE 中，如果将它们编码为字符串或动态创建，它们通常会被遗漏。最糟糕的是，通常在您的解决方案重新投入生产之前，这些遗漏的引用才会被捕获...... :(
我曾经使用绝对 URL 以 / 开头的情况，因此应该可以移动到另一台服务器，但后来我在 www.mydomain.com/apps/ 中部署了我的应用程序，现在我找不到任何资源俄亥俄州这就是为什么我同意相对 URL 更安全的原因 - 当您在不同的路由中重用服务器端模板时，它们仍然会出现问题，但是您可以轻松地使用 header-redirects 在渲染之前将用户发送到正确的路径。
一个 URL 甚至可以是相对的吗？协议的存在难道不是构成 URI 和 URL 的原因吗？

【解决方案3】：

看到这个：http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax

foo://username:password@example.com:8042/over/there/index.dtb;type=animal?name=ferret#nose
\ /   \________________/\_________/ \__/            \___/ \_/ \_________/ \_________/ \__/
 |           |               |       |                |    |       |           |       |
 |       userinfo         hostname  port              |    |       parameter query  fragment
 |    \_______________________________/ \_____________|____|____________/
scheme                |                               | |  |
 |                authority                           |path|
 |                                                    |    |
 |            path                       interpretable as filename
 |   ___________|____________                              |
/ \ /                        \                             |
urn:example:animal:ferret:nose               interpretable as extension

绝对 URL 包括“路径”部分之前的部分 - 换句话说，它包括方案（http://foo/bar/baz 中的 http）和主机名（http://foo/bar/baz 中的 foo）（以及可选端口、用户信息和端口）。

相对 URL 以路径开头。

绝对 URL 是绝对的：仅查看 URL 本身就可以解析资源的位置。相对 URL 在某种意义上是不完整的：要解析它，您需要方案和主机名，这些通常取自当前上下文。例如，在一个网页中

http://myhost/mypath/myresource1.html

你可以这样放一个链接

<a href="pages/page1">click me</a>

在链接的href属性中，使用了一个相对URL，如果被点击，则必须解析它才能跟随它。在这种情况下，当前上下文是

http://myhost/mypath/myresource1.html

因此，这些架构、主机名和前导路径被采用并附加到pages/page1，从而产生

http://myhost/mypath/pages/page1

如果链接是：

<a href="/pages/page1">click me</a>

（请注意出现在 URL 开头的 /）然后它会被解析为

http://myhost/pages/page1

因为前面的/ 表示主机的根目录。

在 web 应用程序中，我建议对属于您的应用程序的所有资源使用相对 URL。这样，如果您更改页面的位置，一切都会继续工作。任何外部资源（可能是完全在您的应用程序之外的页面，也可能是您通过内容交付网络交付的静态内容）应始终使用绝对 URL：如果您不这样做，则根本无法找到它们，因为它们驻留在不同的服务器上。

【讨论】：

相对 URL不需要需要以 URL 路径开头。 //example.com/…、?foobar 和 #foobar 也是相对 URL，并且不以 URL 路径开头（好吧，对于 ?foobar，您可以说它确实以 empty 路径开头）。
@Gumbo，//example.com/… 类型的 URL 是否称为相对 URL？这对我来说是新的。
@törzsmókus 在terms of RFC 2396：“相对 URI 引用与绝对 URI 的区别在于它们不以方案名称开头。”

【解决方案4】：

假设我们正在创建一个子站点，其文件位于文件夹 http://site.ru/shop。

1。绝对网址

Link to home page
href="http://sites.ru/shop/"

Link to the product page
href="http://sites.ru/shop/t-shirts/t-shirt-life-is-good/"

2。相对网址

Link from home page to product page
href="t-shirts/t-shirt-life-is-good/"

Link from product page to home page
href="../../"

虽然相对 URL 看起来比绝对 URL 短，但绝对 URL 更可取，因为链接可以在网站的任何页面上不加改变地使用。

中间案例

我们考虑了两种极端情况：“绝对”绝对和“绝对”相对 URL。但在这个世界上，一切都是相对的。这也适用于 URL。每次提到绝对 URL 时，都应该指定相对于什么。

3。协议相关的 URL

Link to home page
href="//sites.ru/shop/"

Link to product page
href="//sites.ru/shop/t-shirts/t-shirt-life-is-good/"

Google 推荐此类网址。但是现在一般认为http://和https://是不同的站点。

4。根相对 URL

即相对于域的根文件夹。

Link to home page
href="/shop/"

Link to product page
href="/shop/t-shirts/t-shirt-life-is-good/"

如果所有页面都在同一个域中，这是一个不错的选择。当您将您的网站移动到另一个域时，您不必在 URL 中进行大量的域名替换。

5。基本相对 URL（主页相对）

标签指定基本 URL，它会自动添加到所有相关链接和锚点。基本标签不影响绝对链接。作为基本 URL，我们将指定主页：。

Link to home page
href=""

Link to product page
href="t-shirts/t-shirt-life-is-good/"

现在您不仅可以将您的网站移动到任何域，还可以移动到任何子文件夹中。请记住，尽管 URL 看起来是相对的，但实际上它们是绝对的。尤其要注意主播。要在当前页面中导航，我们必须编写 href="t-shirts/t-shirt-life-is-good/#cmets" 而不是 href="#cmets"。后者会在首页抛出。

结论

对于内部链接，我使用基本相对 URL (5)。对于外部链接和新闻通讯，我使用绝对 URL (1)。

【讨论】：

很好的答案。太糟糕了，它在页面上停留得太低，人们看不到它。在其他答案上回答了很多 cmets。

【解决方案5】：

实际上应该明确讨论三种类型。在实践中，虽然 URL 已被抽象为在较低级别进行处理，但我什至可以说，开发人员可以在他们的整个生命周期中不用手动编写单个 URL。

绝对

绝对 URL 将您的代码与协议和域联系起来。这可以通过动态 URL 来克服。

<a href=“https://dev.example.com/a.html?q=”>https://dev.example.com/a.html?q=</a>

绝对优势：

控制 - 可以控制子域和协议。通过不知名的子域进入的人将被引导到正确的子域。您可以根据需要在安全和非安全之间来回切换。
可配置 - 开发人员喜欢绝对的东西。使用绝对 URL 时，您可以设计简洁的算法。 URL 可以进行配置，以便在单个配置文件中进行一次更改即可在整个站点范围内更新 URL。
千里眼 - 您可以搜索抓取您网站的人或获取一些额外的外部链接。

根相对

根相对 URL 将您的代码与基本 URL 联系起来。这可以通过动态 URL 和/或base tags 来克服。

<a href=“/index.php?q=”>.example.com/index.php?q=</a>

根相对优势：

可配置 - 基本标签使它们相对于您选择的任何根，从而使切换域和实施模板变得容易。

相对

相对 URL 将您的代码与目录结构联系起来。没有办法克服这一点。相对 URL 仅在文件系统中用于遍历目录或作为琐碎任务的快捷方式。

<a href=“index.php?q=”>index.php?q=</a>
<link src=“../.././../css/default.css” />

相对缺点：

混淆 - 那是多少个点？那是多少个文件夹？文件在哪里？为什么它不起作用？
维护 - 如果文件被意外移动资源退出加载，链接会将用户发送到错误的页面，表单数据可能会发送到错误的页面。如果需要移动文件，则所有要停止加载的资源和所有不正确的链接都需要更新。
不能缩放 - 当网页变得更加复杂并且视图开始在多个页面中重复使用时，相关链接将与它们包含的文件相关。如果你有一个 HTML 的导航 sn-p 将出现在每个页面上，那么 relative 将相对于许多不同的地方。当人们开始创建模板时，他们首先意识到他们需要一种管理 URL 的方法。
COMPUTED - 它们由您的浏览器实现（希望根据 RFC）。请参阅RFC3986 中的第 5 章。
糟糕！ - 错误或拼写错误可能导致蜘蛛陷阱。

路线的演变

开发人员已停止编写此处讨论的 URL。所有请求都是针对网站的索引文件并包含一个查询字符串，也就是一个路由。路由可以被认为是一个迷你 URL，它告诉您的应用程序要生成的内容。

<a href="<?=Route::url('named_url', array('first' => 'my', 'last' => 'whacky'))?>">
    http://dev.example.com/index.php/my:whacky:url
</a>

路线专家：

绝对网址的所有优点。
在 URL 中使用任何字符。
更多控制（有利于 SEO）。
能够通过算法生成 URL。这允许 URL 是可配置的。更改 URL 是对单个文件的一次更改。
不需要 404 未找到。后备路线可以显示站点地图或错误页面。
间接访问应用程序文件的便利安全性。守卫声明可以确保每个人都通过正确的渠道到达。
MVC 方法的实用性。

我的看法

大多数人会以某种方式在他们的项目中使用这三种形式。关键是要了解它们并选择最适合该任务的那个。

【讨论】：

您缺少相对于协议的 URL，这比完全绝对的 URL 更好。升级方案（主要是到 HTTPS）时，绝对 URL 很麻烦，相对 URL 可以解决这个问题。
@Tobu 只需通过 HTTPS 提供所有服务。
旁注：看起来您在上面的大多数代码示例中都使用了印刷引号。你可能想解决这个问题。
第一个带点的网址是什么类型的？例如。 "./index.html"
@Lovethenakedgun 如果人们复制代码，甚至将他们的域指向您服务器的 IP，则相对 URL 将使用户停留在虚假站点上，而绝对 URL 会将用户引导回真实站点。绝对 URL 是对源的归属。搜索引擎可用于查找粗心的抓取工具或欺诈者，他们正在窃取内容或复制整个网站，例如网络钓鱼。

【解决方案6】：

我将不得不不同意这里的大多数人。

我认为当您想要快速启动并运行某些东西而不是跳出框框思考时，相对 URL 方案“很好”，特别是如果您的项目很小，只有很少的开发人员（或只有您自己）。

但是，一旦您开始在大型、肥胖的系统上工作，并且一直在切换域和协议，我相信应该采用更优雅的方法。

当您从本质上比较绝对 URL 和相对 URL 时，Absolute 胜出。为什么？因为它永远不会破裂。曾经。绝对 URL 正是它所说的。问题是您必须维护绝对 URL。

绝对 URL 链接的弱方法实际上是对整个 URL 进行硬编码。这不是一个好主意，也可能是为什么人们认为它们是危险/邪恶/令人讨厌的罪魁祸首。更好的方法是为自己编写一个易于使用的 URL 生成器。这些很容易编写，并且可以令人难以置信强大 - 自动检测您的协议，易于配置（字面上为整个应用程序设置一次 url）等，并且它会自行注入您的域。这样做的好处是：您继续使用相对 URL 进行编码，并且在运行时应用程序将您的 URL 作为完整的绝对值动态插入。太棒了。

鉴于实际上所有现代网站都使用某种动态后端，这样做符合所述网站的最大利益。绝对 URL 不仅可以让您确定它们指向的位置，还可以提高 SEO 性能。

我可能会补充说，绝对 URL 会以某种方式改变页面加载时间的论点是一个神话。如果您的域重量超过几个字节，并且您在 1980 年代使用的是拨号调制解调器，那是肯定的。但现在情况已不再如此。 https://stackoverflow.com/ 是 25 个字节，而他们用于网站导航区域的“topbar-sprite.png”文件的重量为 9+ kb。这意味着与 sprite 文件相比，额外的 URL 数据占加载数据的 0.2%，而且该文件甚至不被视为对性能的重大影响。

那个大的、未优化的、整页的背景图片更有可能减慢你的加载时间。

关于为什么不应该使用相对 URL 的有趣帖子在这里： Why relative URLs should be forbidden for web developers

例如，亲戚可能会出现的一个问题是，有时服务器映射（请注意大型、混乱的项目）与文件名不一致，开发人员可能会假设相对 URL不是真的。我今天刚刚在我正在进行的一个项目中看到了这一点，它把整个页面都写下来了。

或者也许开发人员忘记切换指针，突然谷歌索引了你的整个测试环境。哎呀 - 重复的内容（对 SEO 不利！）。

绝对可能是危险的，但如果使用得当并以不会破坏您的构建的方式使用，它们会被证明更可靠。看看上面的文章，它给出了为什么 Wordpress url 生成器非常棒的一系列原因。

:)

【讨论】：

当你说绝对 URL 是指完整的 URL 还是使用 / 链接到基本路径？即/products/wallets/thing.html 而不是thing.html 而不是http://www.myshop.com/products/wallets/thing.html
我相信，前面加一个“/”总是相对于域根目录。因此，如果您的域是“www.example.com”，则任何编码为“/image1.jpg”的引用都将被解释为“www.example.com/image1.jpg”。没有前导斜杠的项目被解释为相对于请求根。当我说“绝对 URL”时，我指的是完全限定的 URL。我不敢通过互联网发送 MSDN 链接，但这实际上是一个很好的细分：msdn.microsoft.com/en-us/library/windows/desktop/…
这是当前的最佳实践，尽管很多人还没有意识到这一点。我喜欢路由，例如在 Kohana 中，您可以使用 echo Route::url('route_name') 使用站点 URL 和路由信息构建绝对 URL，并可选择通过 HTTPS 实现。
我觉得有必要指出，拨号调制解调器并没有在 80 年代遗留下来。现在有很多人除了拨号或超高价非常有限的卫星互联网之外别无选择……如果你很穷，还有什么比免费拨号更好的呢？看到那些相信拨号不再存在的开发人员真的让我很困扰。通过拨号登录我的银行网站可能需要 5-10 分钟（！！！）... Paypal、Amazon 和 Ebay 也好不了多少。 Egg Cave（一个虚拟宠物网站）和 Facebook 根本不适合拨号。这影响了许多生活在农村地区的人。
好的，是的，虽然有些人在拨号，但绝大多数（绝大多数）用户不在拨号。这也与人口统计有很大关系。如果您正在拍摄超大型的超高性能结果，那么请开始将您的域从您的 URL 中剪掉。但该评论的要点是强调性能通常在其他领域中发现 - 您可以通过优化单个图像获得在 url 字节中丢失的传输时间的所有。但是，如果 20% 或更多的用户使用拨号，我想这很重要。 2015 年，实际情况并非如此。

【解决方案7】：

如果是在您的网站中使用，最好使用相对 URL，例如，如果您需要将网站移至另一个域名或仅在本地调试，则可以。

看看stackoverflow在做什么（在firefox中是ctrl+U）：

<a href="/users/recent/90691"> // Link to an internal element

在某些情况下，他们使用绝对网址：

<link rel="stylesheet" href="http://sstatic.net/so/all.css?v=5934">

...但这只是提高速度的最佳做法。在你的情况下，你看起来不像在做那样的事情，所以我不会担心。

【讨论】：

【解决方案8】：

在大多数情况下，相对 URL 是可行的方法，它们本质上是可移植的，这意味着如果您想提升您的网站并将其放在其他地方可以立即运行，从而减少可能的调试时间。

有一个相当不错的article on absolute vs relative URLs，看看吧。

【讨论】：

【解决方案9】：

以 URL 方案和方案特定部分（http://、https://、ftp:// 等）开头的 URL 是绝对 URL。

任何其他 URL 都是相对 URL，并且需要一个基本 URL，该基本 URL 是从（并因此依赖于）解析相对 URL 的，如果未另行声明，则该基本 URL 是使用引用的资源的 URL。

查看 RFC 2396 – Appendix C 以获取解析相对 URL 的示例。

【讨论】：

【解决方案10】：

假设您有一个网站 www.yourserver.com。在 Web 文档的根目录中，您有一个 images 子目录，其中有 myimage.jpg。

绝对 URL 定义了文档的确切位置，例如：

http://www.yourserver.com/images/myimage.jpg

相对 URL 定义了 相对于当前目录的位置，例如，假设您位于您的图像所在的 Web 根目录中：

images/myimage.jpg

（相对于那个根目录）

您应该尽可能使用相对 URL。如果您将站点移至 www.anotherserver.com，则必须更新所有指向 www.yourserver.com 的绝对 URL，相对 URL 将保持原样工作。

【讨论】：

【解决方案11】：

对于每个支持相对 URI 解析的系统，相对和绝对 URI 都服务于相同的目标：引用。它们可以互换使用。所以你可以在 each 的情况下做出不同的决定。从技术上讲，它们提供了相同的引用。

准确地说，每个相对 URI 都已经有一个绝对 URI。这就是解析相对 URI 的基本 URI。所以相对 URI 实际上是绝对 URI 之上的一个特性。

这也是为什么使用相对 URI，您可以像使用绝对 URI 一样更多 - 这对于静态网站尤其重要，否则与绝对 URI 相比，静态网站维护起来不那么灵活.

相对 URI 解析的这些积极影响也可以用于动态 Web 应用程序开发。在动态环境中，绝对 URI 确实引入的不灵活性也更容易应对，因此对于一些不确定 URI 解析以及如何正确实现和管理它（并非总是很容易）的开发人员通常选择使用绝对 URI URI 位于网站的动态部分，因为它们可以引入其他动态特性（例如，包含 URI 前缀的配置变量），从而解决不灵活的问题。

那么使用绝对 URI 有什么好处呢？技术上不存在，但我想说的是：相对 URI 更复杂，因为它们需要针对所谓的绝对基本 URI 进行解析。即使是多年来严格定义的分辨率，您也可能会遇到在 URI 解析中有错误的客户端。由于绝对 URI 不需要任何解析，因此使用绝对 URI 不会在使用相对 URI 解析时遇到错误的客户端行为。那么这个风险到底有多高呢？嗯，这是非常罕见的。我只知道一种 Internet 浏览器存在相对 URI 解析问题。这不是一般情况，而是仅在非常（晦涩）的情况下。

除了 HTTP 客户端（浏览器）之外，对于超文本文档或代码的作者来说，它也可能更加复杂。在这里，绝对 URI 的好处是更容易测试，因为您可以将其按原样输入到浏览器地址栏中。但是，如果这不仅仅是您一小时的工作，那么实际了解绝对和相对 URI 处理通常对您更有好处，这样您就可以真正利用相对链接的好处。

【讨论】：

【解决方案12】：

我衷心推荐相对 URL，用于将同一站点的位指向同一站点的其他位。

不要忘记对 HTTPS 的更改（即使在同一个站点中）也需要一个绝对 URL。

【讨论】：