Абсолютные и относительные URL
Я хотел бы знать различия между этими двумя типами URL-адресов: относительными URL-адресами (для изображений, CSS-файлами, файлами JS и т. Д.) И абсолютными URL-адресами.
Кроме того, какой из них лучше использовать?
12 ответов
Как правило, рекомендуется использовать относительные URL-адреса, чтобы ваш веб-сайт не был привязан к базовому URL-адресу, на котором он развернут в настоящее время. Например, он сможет работать на локальном хосте, а также на вашем публичном домене, без изменений.
Должен ли я использовать абсолютные или относительные 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-адреса различий мы можем использовать:
http://yourdomain.com/images/example.png//yourdomain.com/images/example.png/images/example.pngimages/example.png
Какие ресурсы эти 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>
Некоторые (своего рода) дубликаты
Смотрите это: http://en.wikipedia.org/wiki/URI_scheme
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-адресов: если вы этого не сделаете, просто нет способа их найти, потому что они проживать на другом сервере.
Предположим, мы создаем дочерний сайт, файлы которого находятся в папке 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 (относительно домашней страницы)
Тег
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).
Есть действительно три типа, которые следует обсудить в явном виде. На практике, хотя 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-адресов и / или базовых тегов.
<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, который будет на каждой странице, то относительный будет относительным по отношению к множеству разных мест. Первое, что люди понимают, когда начинают создавать шаблон, это то, что им нужен способ управления URL-адресами.
ВЫЧИСЛЕНО - они реализованы вашим браузером (надеюсь, в соответствии с RFC). См. Главу 5 в RFC3986.
OOPS! - Ошибки или опечатки могут привести к ловушке паука.
Эволюция маршрутов
Разработчики прекратили писать URL-адреса в том смысле, который здесь обсуждается. Все запросы относятся к индексному файлу веб-сайта и содержат строку запроса, то есть маршрут. Маршрут можно представить как мини-URL, который сообщает вашему приложению, какое содержимое будет создано.
<a href="<?=Route::url('named_url', array('first' => 'my', 'last' => 'whacky'))?>">
http://dev.example.com/index.php/my:whacky:url
</a>
Маршруты Плюсы:
- Все преимущества абсолютных URL.
- Использование любого символа в URL.
- Больше контроля (хорошо для SEO).
- Возможность алгоритмически генерировать URL. Это позволяет настраивать URL-адреса. Изменение URL-адреса - это одно изменение в одном файле.
- Не нужно за 404 не основывать. Резервные маршруты могут отображать карту сайта или страницу ошибки.
- Удобная защита косвенного доступа к файлам приложения. Охранные заявления могут убедиться, что все прибывают по соответствующим каналам.
- Практичность в подходе MVC.
Мой дубль
Большинство людей так или иначе используют все три формы в своих проектах. Ключ должен понять их и выбрать тот, который лучше всего подходит для задачи.
Я собираюсь не согласиться с большинством здесь.
Я думаю, что схема относительных URL-адресов "хороша", когда вы хотите быстро запустить и запустить что-то, а не мыслить нестандартно, особенно если ваш проект мал, с несколькими разработчиками (или только вами).
Однако, как только вы начнете работать на больших, жирных системах, где вы все время переключаете домены и протоколы, я считаю, что более элегантный подход необходим.
Когда вы сравниваете абсолютные и относительные URL по существу, Абсолют побеждает. Зачем? Потому что это никогда не сломается. Когда-либо. Абсолютный URL это именно то, что он говорит. Загвоздка в том, когда вам нужно поддерживать абсолютные URL-адреса.
Слабый подход к абсолютной ссылке на URL - это жесткое кодирование всего URL. Не очень хорошая идея и, вероятно, виновник того, почему люди считают их опасными / злыми / раздражающими в обслуживании. Лучший подход - написать простой в использовании генератор URL. Их легко написать, и они могут быть невероятно мощными: они автоматически определяют ваш протокол, легко настраиваются (буквально устанавливают URL-адрес для всего приложения) и т. Д., И он самостоятельно внедряет ваш домен. Хорошая вещь об этом: вы продолжаете кодировать, используя относительные URL, и во время выполнения приложение вставляет ваши URL как полные абсолюты на лету. Потрясающие.
Учитывая, что практически все современные сайты используют какой-то динамический бэкэнд, в интересах указанного сайта сделать это таким образом. Абсолютные URL-адреса делают больше, чем просто дают вам уверенность в том, на что они указывают, они также могут повысить эффективность SEO.
Я мог бы добавить, что аргумент, что абсолютные URL-адреса каким-то образом изменят время загрузки страницы, является мифом. Если ваш домен весит больше нескольких байтов, и вы используете модем в 1980-х годах, конечно. Но это просто не тот случай. https://stackru.com/ составляет 25 байт, а файл "topbar-sprite.png", который они используют для области навигации сайта, весит 9+ кб. Это означает, что дополнительные данные URL составляют 0,2% от загруженных данных по сравнению со спрайтовым файлом, и этот файл даже не считается значительным ударом по производительности.
Это большое неоптимизированное полностраничное фоновое изображение с большей вероятностью замедлит время загрузки.
Интересный пост о том, почему относительные URL не должны использоваться, находится здесь: http://yoast.com/relative-urls-issues/
Например, проблема, которая может возникнуть у родственников, заключается в том, что иногда сопоставления серверов (обратите внимание на большие, испорченные проекты) не совпадают с именами файлов, и разработчик может сделать предположение об относительном URL, который просто не соответствует правда. Я только что видел это сегодня в проекте, в котором я участвую, и он принес мне целую страницу.
Или, возможно, разработчик забыл переключить указатель и внезапно Google проиндексировал всю вашу тестовую среду. Ой - дублированный контент (плохо для SEO!).
Абсолюты могут быть опасными, но при правильном использовании таким образом, который не может нарушить вашу сборку, они оказываются более надежными. Посмотрите на статью выше, которая дает множество причин, почему генератор URL-адресов Wordpress супер.
:)
Если он предназначен для использования на вашем веб-сайте, лучше использовать относительный URL-адрес, например, если вам нужно переместить веб-сайт на другое доменное имя или просто выполнить локальную отладку, вы можете это сделать.
Посмотрите на то, что делает stackru (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">
... но это только лучшая практика для улучшения скорости. В вашем случае не похоже, что вы делаете что-то подобное, поэтому я бы не волновался об этом.
В большинстве случаев относительные URL-адреса являются подходящим способом, они переносимы по своей природе, что означает, что если вы хотите поднять свой сайт и разместить его на другом месте, где бы он работал, мгновенно, сокращая, возможно, часы отладки.
Есть довольно приличная статья об абсолютных и относительных URL, посмотрите ее.
URL-адрес, который начинается со схемы URL и ее части (http://, https://, ftp://и т. д.) является абсолютным URL.
Любой другой URL-адрес является относительным URL-адресом и требует базового URL-адреса, с которого разрешается относительный URL-адрес (и, следовательно, зависит от него), то есть URL-адреса ресурса, в котором используется ссылка, если не объявлено иначе.
Взгляните на RFC 2396 - Приложение C, где приведены примеры разрешения относительных URL.
Допустим, у вас есть сайт 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, относительные будут продолжать работать как есть.
Для каждой системы, которая поддерживает относительное разрешение URI, и относительные, и абсолютные URI служат одной и той же цели: ссылкам. И они могут быть использованы взаимозаменяемо. Таким образом, вы могли бы решить в каждом случае по-разному. Технически они предоставляют одинаковые ссылки.
Чтобы быть точным, с каждым относительным URI уже есть абсолютный URI. И это базовый URI, против которого разрешается относительный URI. Таким образом, относительный URI на самом деле является функцией поверх абсолютных URI.
И именно поэтому с относительными URI вы можете сделать больше, чем с одним абсолютным URI - это особенно важно для статических веб-сайтов, которые в противном случае не могли бы быть настолько гибкими в обслуживании по сравнению с абсолютными URI.
Эти положительные эффекты относительного разрешения URI могут также использоваться для динамической разработки веб-приложений. Абсолютные URI с негибкостью вводить также проще в динамической среде, поэтому некоторые разработчики, которые не уверены в разрешении URI и в том, как правильно его реализовать и управлять им (не всегда так просто), часто выбирают использование абсолютного URI в динамической части веб-сайта, поскольку они могут вводить другие динамические функции (например, переменную конфигурации, содержащую префикс URI), чтобы обойти эту негибкость.
Так в чем же польза от использования абсолютных URI? Технически нет, но я бы сказал, что относительные URI являются более сложными, потому что их необходимо сопоставить с так называемым абсолютным базовым URI. Даже разрешение строго определено с годами, вы можете столкнуться с клиентом, у которого есть ошибка в разрешении URI. Поскольку абсолютные URI не нуждаются в каком-либо разрешении, использование абсолютных URI не имеет риска столкнуться с ошибочным поведением клиента при относительном разрешении URI. Так насколько велик этот риск на самом деле? Ну, это очень редко. Я знаю только об одном интернет-браузере, у которого была проблема с относительным разрешением URI. И это было не вообще, а только в очень (неясном) случае.
Рядом с HTTP-клиентом (браузером), возможно, сложнее и для автора гипертекстовых документов или кода. Здесь абсолютный URI имеет то преимущество, что его проще тестировать, так как вы можете просто ввести его как есть в адресную строку браузера. Однако, если это не просто ваша часовая работа, вам чаще всего полезно понять абсолютную и относительную обработку URI, чтобы вы могли использовать преимущества относительного связывания.
Я бы искренне рекомендовал относительные URL-адреса для указания битов того же сайта на другие биты того же сайта.
Не забывайте, что для изменения HTTPS - даже если он находится на том же сайте - понадобится абсолютный URL.