Абсолютные и относительные URL - PullRequest
183 голосов
/ 05 января 2010

Я хотел бы знать различия между этими двумя типами URL-адресов: относительными URL-адресами (для изображений, CSS-файлами, файлами JS и т. Д.) И абсолютными URL-адресами.

Кроме того, какой из них лучше использовать?

Ответы [ 12 ]

200 голосов
/ 17 февраля 2014

Должен ли я использовать абсолютные или относительные URL?

Если под абсолютными URL-адресами вы подразумеваете URL-адреса, включающие схему (например, http / https) и имя хоста (например, yourdomain.com), никогда не делайте этого (для локальных ресурсов), поскольку поддерживать и отлаживать будет ужасно.

Допустим, вы использовали абсолютный URL везде в своем коде, например <img src="http://yourdomain.com/images/example.png">. Теперь, что произойдет, когда вы собираетесь:

  • переключиться на другую схему (например, http -> https)
  • переключение доменных имен (test.yourdomain.com -> yourdomain.com)

В первом примере будет получено предупреждение о том, что на странице запрашивается небезопасный контент. Потому что все ваши URL жестко запрограммированы для использования http (: //yourdomain.com/images/example.png). А при запуске ваших страниц через http браузер ожидает загрузки всех ресурсов через https, чтобы предотвратить утечку информации.

Во втором примере, когда ваш сайт работает из тестовой среды, это будет означать, что все ресурсы по-прежнему указывают на ваш тестовый домен, а не на действующий домен.

Итак, чтобы ответить на ваш вопрос о том, использовать ли абсолютные или относительные URL-адреса: всегда используйте относительные URL-адреса (для локальных ресурсов).

В чем разница между разными URL?

Сначала давайте посмотрим, какие URL-адреса различий мы можем использовать:

К каким ресурсам эти URL-адреса пытаются получить доступ на сервере?

В приведенных ниже примерах я предполагаю, что веб-сайт работает из следующего местоположения на сервере /var/www/mywebsite.

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

Приведенный выше (абсолютный) URL пытается получить доступ к ресурсу /var/www/website/images/example.png. Этот тип URL - это то, что вы всегда хотели бы избегать при запросе ресурсов с вашего собственного сайта по причинам, изложенным выше. Однако это имеет свое место. Например, если у вас есть веб-сайт http://yourdomain.com и вы хотите запросить ресурс у внешнего домена через http, вы должны использовать это. Например. https://externalsite.com/path/to/image.png.

//yourdomain.com/images/example.png

Этот URL-адрес является относительным на основе текущей используемой схемы и должен почти всегда использоваться при включении внешних ресурсов (изображений, javascripts и т. Д.).

Этот тип 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-адрес разрешается таким же образом на стороне сервера, что и предыдущий URL-адрес:

Приведенный выше (абсолютный) URL пытается получить доступ к ресурсу /var/www/website/images/example.png.

/images/example.png

Для локальных ресурсов это предпочтительный способ ссылки на них. Это относительный URL, основанный на корне документа (/var/www/mywebsite) вашего веб-сайта. Это означает, что если у вас есть <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>

Некоторые (вроде) дубликаты

173 голосов
/ 05 января 2010

Как правило, рекомендуется использовать относительные URL-адреса, чтобы ваш веб-сайт не был привязан к базовому URL-адресу, по которому он развернут в настоящее время. Например, он сможет работать как на локальном, так и на вашем публичном домене без изменений.

60 голосов
/ 05 января 2010

Смотрите это: 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 в http://foo/bar/baz) и имя хоста (foo в http://foo/bar/baz) (и, необязательно, порт, userinfo и порт).

Относительные 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

потому что ведущий / указывает на корень хоста.

В веб-приложении я бы советовал использовать относительные URL-адреса для всех ресурсов, принадлежащих вашему приложению. Таким образом, если вы измените расположение страниц, все будет продолжать работать. Любые внешние ресурсы (это могут быть страницы за пределами вашего приложения, но также и статический контент, который вы доставляете через сеть доставки контента), всегда следует указывать с использованием абсолютных URL-адресов: если вы этого не сделаете, просто нет способа найти их, потому что они находиться на другом сервере.

38 голосов
/ 17 сентября 2016

Предположим, мы создаем дочерний сайт, файлы которого находятся в папке http://site.ru/shop.

1. Абсолютный URL

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. Относительный URL

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, вы всегда должны указывать относительно чего.

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 рекомендует такой URL. Однако теперь считается, что 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 / # comments" not href = "# comments". Последний выкинет на домашнюю страницу.

Заключение

Для внутренних ссылок я использую базовые URL (5). Для внешних ссылок и информационных бюллетеней я использую абсолютные URL (1).

24 голосов
/ 21 мая 2014

На самом деле есть три типа, которые следует обсудить явно. На практике, хотя URL-адреса были абстрагированы для обработки на более низком уровне, я бы сказал, что разработчики могут прожить всю свою жизнь, не написав ни одного URL-адреса вручную.

Absolute

Абсолютные URL привязывают ваш код к протоколу и домену. Это можно преодолеть с помощью динамических URL.

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

Абсолютные плюсы:

  1. Управление - Субдомен и протокол можно контролировать. Люди, которые входят через неясный поддомен, будут направлены в соответствующий поддомен. Вы можете переключаться между безопасным и небезопасным в зависимости от ситуации.

  2. Настраиваемый - Разработчики любят вещи, чтобы быть абсолютным. Вы можете разработать аккуратные алгоритмы при использовании абсолютных URL. URL-адреса можно настроить так, чтобы URL-адрес можно было обновлять по всему сайту с помощью одного изменения в одном файле конфигурации.

  3. Ясновидение - Вы можете искать людей, очищающих ваш сайт, или, возможно, получить дополнительные внешние ссылки.


Root Relative

Root Relative URLs привязывают ваш код к базовому URL. Это можно преодолеть с помощью динамических URL-адресов и / или базовых тегов .

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

Root Относительные плюсы:

  1. Настраиваемый - Базовый тег делает их относительными к любому выбранному вами корню, упрощая переключение доменов и внедрение шаблонов.

Относительный

Относительные URL связывают ваш код со структурой каталогов. Нет способа преодолеть это. Относительные URL-адреса полезны только в файловых системах для обхода каталогов или в качестве ярлыка для простой задачи.

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

Относительные минусы:

  1. Смущает - Сколько это точек? сколько это папок? Где файл? Почему не работает?

  2. ОБСЛУЖИВАНИЕ - Если файл случайно перемещен, ресурсы перестают загружаться, ссылки отправляют пользователя на неправильные страницы, данные формы могут быть отправлены на неправильную страницу. Если файл НУЖДАЕТСЯ в перемещении, все ресурсы, которые собираются прекратить загрузку, и все ссылки, которые будут некорректными, необходимо обновить.

  3. НЕ МАСШТАБИРОВАТЬ - Когда веб-страницы становятся более сложными и представления начинают повторно использоваться на нескольких страницах, относительные ссылки будут относиться к файлу, в который они были включены. Если у вас есть навигационный фрагмент HTML, который будет на каждой странице, то относительный будет относительным ко многим различным местам. Первое, что люди понимают, когда начинают создавать шаблон, это то, что им нужен способ управления URL-адресами.

  4. ВЫЧИСЛЕНО - Они реализованы вашим браузером (надеюсь, в соответствии с RFC). См. Главу 5 в RFC3986 .

  5. OOPS! - Ошибки или опечатки могут привести к появлению ловушек для пауков.


Эволюция маршрутов

Разработчики прекратили писать URL в том смысле, который здесь обсуждается. Все запросы относятся к индексному файлу веб-сайта и содержат строку запроса, то есть маршрут. Маршрут можно представить как мини-URL, который сообщает вашему приложению, какое содержимое будет создано.

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

Маршруты Плюсы:

  1. Все преимущества абсолютных URL.
  2. Использование любого символа в URL.
  3. Больше контроля (хорошо для SEO).
  4. Возможность алгоритмически генерировать URL. Это позволяет настраивать URL-адреса. Изменение URL - это одно изменение в одном файле.
  5. Нет необходимости в 404, не находит. Резервные маршруты могут отображать карту сайта или страницу ошибки.
  6. Удобная защита косвенного доступа к файлам приложения. Охранные заявления могут гарантировать, что все прибывают по соответствующим каналам.
  7. Практичность в подходе MVC.

My Take

Большинство людей так или иначе используют все три формы в своих проектах. Ключ должен понять их и выбрать тот, который лучше всего подходит для задачи.

6 голосов
/ 18 июля 2013

Я собираюсь не согласиться с большинством здесь.

Я думаю, что схема относительных URL-адресов "хороша", когда вы хотите быстро запустить и запустить что-то, а не мыслить нестандартно, особенно если у вас небольшой проект, в котором мало разработчиков (или только вы сами).

Однако, как только вы начнете работать на больших, жирных системах, где вы все время переключаете домены и протоколы, я считаю, что более элегантный подход необходим.

Когда вы сравниваете абсолютные и относительные URL по существу, Абсолют побеждает. Зачем? Потому что это никогда не сломается. Когда-либо. Абсолютный URL это именно то, что он говорит. Загвоздка в том, когда вам нужно поддерживать абсолютные URL.

Слабый подход к абсолютному URL-соединению на самом деле заключается в жестком кодировании всего URL-адреса. Не очень хорошая идея и, вероятно, виновник того, почему люди считают их опасными / злыми / раздражающими в обслуживании. Лучший подход - написать простой в использовании генератор URL. Их легко написать, и они могут быть невероятно мощными - автоматически определять ваш протокол, легко настраиваться (буквально устанавливать URL-адрес для всего приложения) и т. Д., И он самостоятельно внедряет ваш домен. Хорошая вещь об этом: вы продолжаете кодировать, используя относительные URL, и во время выполнения приложение вставляет ваши URL как полные абсолюты на лету. Потрясающе.

Учитывая, что практически все современные сайты используют какой-то динамический бэкэнд, в интересах этого сайта сделать именно так. Абсолютные URL-адреса делают больше, чем просто дают вам уверенность в том, на что они указывают, они также могут повысить эффективность SEO.

Могу добавить, что аргумент о том, что абсолютные URL-адреса как-то изменят время загрузки страницы, является мифом. Если ваш домен весит больше нескольких байтов и вы используете модем в 1980-х годах, конечно. Но это просто не тот случай. https://stackoverflow.com/ составляет 25 байт, тогда как файл «topbar-sprite.png», который они используют для области навигации сайта, весит 9+ кб. Это означает, что дополнительные данные URL составляют 0,2% от загруженных данных по сравнению со спрайтовым файлом, и этот файл даже не считается значительным ударом по производительности.

Такое большое неоптимизированное фоновое изображение на всю страницу намного быстрее замедляет загрузку.

Интересный пост о том, почему относительные URL не должны использоваться, находится здесь: http://yoast.com/relative-urls-issues/

Проблема, которая может возникнуть, например, с родственниками, заключается в том, что иногда сопоставления серверов (обратите внимание на большие, испорченные проекты) не совпадают с именами файлов, и разработчик может сделать предположение об относительном URL, который просто не правда Я только что видел это сегодня в проекте, в котором я участвую, и он опустил целую страницу.

Или, возможно, разработчик забыл переключить указатель и внезапно Google проиндексировал всю вашу тестовую среду. Ой - дублированный контент (плохо для SEO!).

Абсолюты могут быть опасными, но при правильном использовании таким образом, что не может сломать ваш билд они доказали свою надежность. Посмотрите на статью выше, в которой приведено несколько причин, почему генератор URL-адресов Wordpress супер.

:)

6 голосов
/ 05 января 2010

Если он предназначен для использования на вашем веб-сайте, лучше использовать относительный URL-адрес, например, если вам нужно переместить сайт на другое доменное имя или просто выполнить локальную отладку, вы можете.

Посмотрите, что делает стекопоток (Ctrl + U в Firefox):

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

В некоторых случаях они используют абсолютные URL:

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

... но это только лучшая практика для улучшения скорости. В вашем случае не похоже, что вы делаете что-то подобное, поэтому я бы не волновался об этом.

4 голосов
/ 05 января 2010

URL-адрес, начинающийся со схемы URL и конкретной части схемы (http://, https://, ftp:// и т. Д.), Является абсолютным URL-адресом.

Любой другой URL-адрес является относительным URL-адресом и требует базового URL-адреса, с которого разрешается относительный URL-адрес (и, следовательно, зависит от него), то есть URL-адреса ресурса, в котором используется ссылка, если не объявлено иначе.

Посмотрите RFC 2396 - Приложение C , где приведены примеры разрешения относительных URL.

4 голосов
/ 05 января 2010

В большинстве случаев относительные URL-адреса являются подходящим способом, они переносимы по своей природе, что означает, что если вы хотите поднять свой сайт и перевести его на другое место, где бы он работал, мгновенно, что может сократить время отладки.

Есть довольно приличная статья об абсолютных и относительных URL , зацените.

3 голосов
/ 05 января 2010

Допустим, у вас есть сайт www.yourserver.com. В корневом каталоге для веб-документов у вас есть поддиректория изображений, в которой у вас есть myimage.jpg.

Абсолютный URL-адрес определяет точное местоположение документа, например:

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

Относительный URL-адрес определяет местоположение относительно текущего каталога , например, если вы находитесь в корневом веб-каталоге, в котором находится ваше изображение:

images/myimage.jpg

(относительно этого корневого каталога)

Вы всегда должны использовать относительные URL, где это возможно. Если вы переместите сайт на www.anotherserver.com, вам придется обновить все абсолютные URL-адреса, которые указывали на www.yourserver.com, относительные будут просто продолжать работать как есть.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...