Я хотел бы знать различия между этими двумя типами URL-адресов: относительные URL-адреса (для изображений, CSS файлов, JS файлов и т.д.) и абсолютных URL-адресов.
Кроме того, какой из них лучше использовать?
Я хотел бы знать различия между этими двумя типами URL-адресов: относительные URL-адреса (для изображений, CSS файлов, JS файлов и т.д.) и абсолютных URL-адресов.
Кроме того, какой из них лучше использовать?
В целом, рекомендуется использовать относительные URL-адреса, поэтому ваш сайт не будет привязан к базовому URL-адресу, где он в настоящее время развернут. Например, он сможет работать на локальном хосте, а также в вашем общедоступном домене без изменений.
Если по абсолютным URL-адресам вы имеете в виду URL-адреса, включая схему (например, http/https) и имя хоста (например, yourdomain.com), никогда не делайте этого (для локальных ресурсов), потому что будет ужасно поддерживать и отлаживать.
Скажем, вы использовали абсолютный URL везде в своем коде, например <img src="http://yourdomain.com/images/example.png">
. Теперь, что произойдет, когда вы собираетесь:
В первом примере произойдет то, что вы получите предупреждения о небезопасном содержимом, запрашиваемом на странице. Поскольку все ваши URL-адреса жестко запрограммированы для использования http (://yourdomain.com/images/example.png). И при запуске ваших страниц через http браузер ожидает, что все ресурсы будут загружены через https, чтобы предотвратить утечку информации.
Во втором примере, когда вы размещаете свой сайт в тестовой среде, это будет означать, что все ресурсы по-прежнему указывают на ваш тестовый домен вместо вашего живого домена.
Итак, чтобы ответить на ваш вопрос о том, использовать ли абсолютные или относительные URL-адреса, всегда используйте относительные URL-адреса (для локальных ресурсов).
Сначала давайте посмотрим, какие URL-адреса разницы можно использовать:
http://yourdomain.com/images/example.png
//yourdomain.com/images/example.png
/images/example.png
images/example.png
В приведенных ниже примерах я предполагаю, что веб-сайт работает из следующего местоположения на сервере /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#Generic_syntax
foo://username:[email protected]: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
in 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.
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/"
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-адресе, вы всегда должны указывать относительно того, что.
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://- разные сайты.
т.е. относительно корневой папки домена.
Link to home page
href="/shop/"
Link to product page
href="/shop/t-shirts/t-shirt-life-is-good/"
Это хороший выбор, если все страницы находятся в одном домене. Когда вы перемещаете свой сайт в другой домен, вам не нужно выполнять массовые замены имени домена в URL-адресах.
Тег <base> указывает базовый URL-адрес, который автоматически добавляется ко всем относительным ссылкам и привязкам. Базовый тег не влияет на абсолютные ссылки. В качестве базового URL мы укажем домашнюю страницу: < base href= "http://sites.ru/shop/" > .
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", а не 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-адрес можно было обновлять по всему сайту одним изменением в одном файле конфигурации.
Clairvoyance. Вы можете искать людей, соскабливающих ваш сайт, или, возможно, получить дополнительные внешние ссылки.
Корректные 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" />
Относительные недостатки:
ПОДТВЕРЖДЕНИЕ. Сколько точек это? сколько папок это? Где находится файл? Почему это не работает?
ТЕХНИЧЕСКОЕ ОБСЛУЖИВАНИЕ. Если файл случайно перемещен, ресурсы перестают загружаться, ссылки отправляют пользователя на неправильные страницы, данные формы могут быть отправлены на неправильную страницу. Если файл NEEDS должен быть перемещен, все ресурсы, которые будут прекращать загрузку, и все ссылки, которые будут некорректны, должны быть обновлены.
НЕ МАСШТАБЫ. Когда веб-страницы становятся более сложными и представления начинают использоваться повторно на нескольких страницах, относительные ссылки будут относиться к файлу, в который они были включены. Если у вас есть фрагмент кода навигации, который будет размещаться на каждой странице, то относительный будет относиться к множеству разных мест. Первое, что люди понимают, когда начинают создавать шаблон, - это то, что им нужен способ управления URL-адресами.
COMPUTED. Они реализованы вашим браузером (надеюсь, согласно 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-адрес, например, если вам нужно переместить сайт на другое доменное имя или просто отлаживать локально, вы можете.
Посмотрите, что делает stackoverflow (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 по существу, выигрывает Absolute. Зачем? Потому что он никогда не сломается. Когда-либо. Абсолютный URL - это именно то, что он говорит. Уловка - это когда вам нужно ПОДДЕРЖАТЬ абсолютные URL-адреса.
Слабый подход к абсолютной привязке URL-адресов на самом деле жестко кодирует весь URL-адрес. Не лучшая идея и, вероятно, виновник того, почему люди считают их опасными/злыми/раздражающими для поддержания. Лучший подход - написать себе простой в использовании генератор URL-адресов. Они просты в написании и могут быть невероятно мощными - автоматически обнаруживают ваш протокол, легко конфигурируются (буквально устанавливают URL-адрес для всего приложения) и т.д., И он сам внедряет ваш домен. Самое приятное в этом: вы продолжаете кодирование с использованием относительных URL-адресов, и во время выполнения приложение вставляет ваши URL-адреса в полные абсолюты "на лету". Высокий.
Увидев, как практически все современные сайты используют какой-то динамический back-end, он в наилучших интересах этого сайта делает это именно так. Абсолютные URL-адреса делают больше, чем просто дают вам определенную информацию о том, где они указывают, - они также могут улучшить производительность SEO.
Я могу добавить, что аргумент, что абсолютные URL-адреса каким-то образом изменяет время загрузки страницы, является мифом. Если ваш домен весит более нескольких байт, и вы в модеме в 80-х годах, конечно. Но это уже не так. /fooobar.com/... составляет 25 байт, тогда как файл topbar-sprite.png, который они используют для навигационной области сайта, весит 9+ кб. Это означает, что дополнительные URL-данные составляют 0,2% от загруженных данных по сравнению с файлом спрайта, и этот файл даже не считается большим хитом производительности.
Это большое, неоптимизированное полностраничное фоновое изображение гораздо более вероятно замедлит ваше время загрузки.
Интересное сообщение о том, почему относительные URL не следует использовать, приведено здесь: http://yoast.com/relative-urls-issues/
Проблема, которая может возникнуть у родственников, например, заключается в том, что иногда сопоставления серверов (у вас на больших, запутанных проектах) не совпадают с именами файлов, и разработчик может сделать предположение относительно относительного URL-адреса, который просто это неверно. Я только что видел, что сегодня в проекте, в котором я нахожусь, и это привело к тому, что вся страница была опущена.
Или, возможно, разработчик забыл переключить указатель и внезапно проиндексировал Google всю тестовую среду. Упс - дублировать контент (плохо для SEO!).
Абсолюты могут быть опасными, но при правильном использовании и способом, который не может сломать вашу сборку, они оказались более надежными. Посмотрите на статью выше, которая дает кучу причин, почему генератор url Wordpress является супер удивительным.
:)
В большинстве случаев относительные URL-адреса - это путь, они переносимы по своей природе, а это означает, что если вы хотите поднять свой сайт и поместить его туда, где еще он будет работать мгновенно, сокращая, возможно, часы отладки.
Существует довольно приличная статья об абсолютных относительных URL-адресах, проверьте ее.
URL, который начинается с URL-схемы и конкретной схемы (http://
, https://
, ftp://
и т.д.), является абсолютным URL-адресом.
Любой другой URL-адрес является относительным URL-адресом и требует базового URL-адреса, из которого относительный URL-адрес разрешен (и, следовательно, зависит от него), который является URL-адресом ресурса, в котором используется ссылка, если не объявлено иначе.
Взгляните на RFC 2396 - Приложение C для примеров относительных URL-адресов.
Скажем, у вас есть сайт www.yourserver.com. В корневом каталоге для веб-документов у вас есть суб-directoy изображений, и у вас есть 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.