Url путь – URL адрес — что это такое и как узнать урл веб-страницы сайта, изображения или видео | Создание сайтов и заработок в сети

Содержание

протокол, доменное имя, путь к файлу

Каждый файл или документ в интернете находится по уникальному адресу, называемому URL (Uniform Resource Locator с анг. Единый указатель ресурса). Термин URI (Uniform Resource Identifier с анг. Единый идентификатор ресурса) иногда используют взаимозаменяемо с URL-адресом, хотя это более общий термин.

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

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

URL-адрес и его составляющие

Протокол

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

Доменное имя и поддомены

Hostname является именем сайта, с которого браузеру будет извлекать файл. Истинным адресом веб-сервера является уникальный числовой адрес интернет протокола (IP — Internet Protocol), и каждый компьютер, подключенный к сети интернет имеет один IP-адрес (что-то вроде «141.8.192.108»), который, безусловно, не очень-то легко запомнить. Доменное имя — более запоминающийся псевдоним, который направляет трафик из интернета на IP-адрес. Многие веб-хостинги имеют префикс перед именем домена, после которого идет конкретный сервер, к которому осуществляется доступ (особенно когда есть несколько серверов в рамках одного домена). Префикс может быть любым, самым распространенным префиксом является конечно «WWW». Это дает возможность существования нескольких отдельных сайтов на одном домене, но имеющих разные префиксы — поддомены. Hostname также содержит суффикс домена, указывающий категорию доменов, например «

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

Путь к файлам

Путь указывает каталог (папку) на веб-сервере, который содержит запрашиваемый документ. Файлы на веб-сервере могут храниться в подкаталогах — дочерних папках, расположенных внутри других папок, и каждый каталог в пути разделяется косой чертой (/). Путь является маршрутом, по которому будет следовать клиент, для достижения целевого файла. Каталог самого верхнего уровня веб-сайта (тот, который содержит в себе другие файлы и каталоги) называется корневым каталогом сайта и не отображается в URL-адресе.

Имя и расширение файла

Определенные файлы для извлечения идентифицируются по имени файла и расширению. Вы можете задать своему файлу любое нужное имя, а расширение файла будет указывать на тип файла. HTML документы (или XHTML) будут иметь расширение .html или .htm (сокращенный вариант используется на некоторых серверах, которые поддерживают только три буквы в расширении). CSS-файлы используют расширение .css, файлы с JavaScript кодом используют .js и так далее. Веб-серверы настраивают на узнавания этих расширений и обработки файлов соответствующим образом, обработка различных типов файлов осуществляется различными способами.

Скорее всего вы не увидите имя файла и его расширение в каждом URL-адресе с которым вы столкнётесь. Большинство веб-серверов настраивают для автоматического обнаружения специально именованного файла при запросе каталога без указанного имени файла. Это может быть файл index.html

, default.html или какое-нибудь другое имя, в зависимости от настроек сервера. Действительно, большинство различных частей URL-адреса могут быть зависимы от конфигурации конкретного сервера.

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

С этой темой смотрят:

путь, фрагмент, запрос и авторизация / Habr


URL’ы не должны были стать тем, чем стали: мудрёным способом идентифицировать сайт в интернете для пользователя. К сожалению, мы не смогли стандартизировать URN, который мог бы стать более полезной системой наименования. Считать, что современная система URL достаточно хороша — это как боготворить командную строку DOS и говорить, что все люди просто должны научиться пользоваться командной строкой. Оконные интерфейсы были придуманы, чтобы пользоваться компьютерами стало проще, и чтобы сделать их популярнее. Такие же мысли должны привести нас к более хорошему методу определения сайтов в Вебе.

— Дейл Догэрти, 1996

Есть несколько вариантов определения слова «интернет». Один из них — это система компьютеров, соединенных через компьютерную сеть. Такая версия интернета появилась в 1969 году с созданием ARPANET. Почта, файлы и чат работали в этой сети еще до создания HTTP, HTML и веб-браузера.

В 1992 году Тим Бернерс-Ли создал три штуки, благодаря которым родилось то, что мы считаем интернетом: протокол HTTP, HTML и URL. Его целью было воплотить понятие гипертекста в реальности. Гипертекст, в двух словах — это возможность создавать документы, которые ссылаются друг на друга. В те годы идея гипертекста считалась панацеей из научной фантастики, заодно с гипермедиа, и любыми другими словами с приставкой «гипер».

Ключевым требованием гипертекста была возможность ссылаться из одного документа на другой. В то время для хранения документов использовалась куча форматов, а доступ осуществлялся по протоколу вроде Gopher или FTP. Тиму нужен был надежный способ ссылаться на файл, так, чтобы в ссылке был закодирован протокол, хост в интернете и местонахождение на этом хосте. Этим способом стал URL, впервые официально задокументированный в RFC в 1994 году.

В начальной презентации World-Wide Web в марте 1992 Тим Бернерс-Ли описал его как «универсальный идентификатор документов» (Universal Document Identifier или UDI). Множество других форматов также рассматривались в качестве такого идентификатора:

protocol: aftp host: xxx.yyy.edu path: /pub/doc/README
PR=aftp; H=xx.yy.edu; PA=/pub/doc/README;
PR:aftp/xx.yy.edu/pub/doc/README
/aftp/xx.yy.edu/pub/doc/README)

Этот документ также объясняет, почему пробелы должны кодироваться в URL (%20):


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

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

scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]

Эта позволило обращаться к разным системам из гипертекста, но сегодня, возможно, такая форма уже избыточна, так как практически все передается через HTTP. В 1996 браузеры уже добавляли http:// и www. за пользователей автоматически (что делает рекламу с этими кусками URL по-настоящему бессмысленной).



Я не считаю, что вопрос «могут ли люди понять значение URL» имеет смысл. Я просто думаю, что морально неприемлемо заставлять бабушку или дедушку вникать в то, что в конечном итоге является нормами файловой системы UNIX.

— Исраэль дель Рио, 1996

Слэш, отделяющий путь в URL, знаком любому, кто использовал компьютер за последние пятьдесят лет. Сама иерархическая файловая система была представлена в системе MULTICS. Ее создатель в свою очередь ссылается на двухчасовую беседу с Альбертом Эйнштейном, которая состоялась в 1952 году.

В MULTICS использовался символ «больше» (>) для разделения компонентов файлового пути. Например:

>usr>bin>local>awk

Это совершенно логично, но, к сожалению, ребята из Unix решили использовать > для обозначения перенаправления, а для разделения пути взяли слэш (/).



Неправильно. Теперь я четко вижу, что мы не согласны друг с другом. Вы и я.

Как человек, я хочу сохранить за собой право использовать разные критерии для разных целей. Я хочу иметь возможность давать имена самим работам,

и конкретным переводам и конкретным версиям. Я хочу более богатого мира чем тот, что вы предлагаете. Я не хочу ограничивать себя вашей двухуровневой системой «документов» и «вариантов».

— Тим Бернерс-Ли, 1993

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

В 1993 году многие страстно верили, что URL отомрет, и на замену ему придет URN. Uniform Resource Name — это постоянная ссылка на любой фрагмент, который, в отличие от URL, никогда не изменится и не сломается. Тим Бернерс-Ли описал его как «срочную необходимость» еще в 1991.

Простейший способ создать URN — это использовать криптографический хэш содержания страницы, например:

urn:791f0de3cfffc6ec7a0aacda2b147839. Однако, этот метод не удовлетворяет критериям веб-сообщества, так как невозможно выяснить, кто и как будет конвертировать этот хэш обратно в реальный контент. Такой способ также не учитывает изменений формата, которые часто происходят в файле (например, сжатие файла), которые не влияют на содержание.

В 1996 Киф Шэйфер и несколько других специалистов предложили решение проблемы поломанных URL. Ссылка на это решение сейчас не работает. Рой Филдинг опубликовал предложение реализации в июле 1995 года. Ссылка тоже поломана.

Я смог найти эти страницы через Google, который по сути сделал заголовки страниц современным аналогом URN. Формат URN был окончательно оформлен в 1997 году, и практически не использовался с тех пор. У него интересная реализация. Каждый URN состоит из двух частей: authority, который может преобразовать определенный тип URN, и конкретный идентификатор документа в понятном для

authority формате. Например, urn:isbn:0131103628 будет обозначать книгу, формируя постоянную ссылку, которая (надеюсь) будет конвертирована в набор URL’ов вашим локальным преобразователем isbn .

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

<!-- On http://zack.is/history -->
<link rel="past-url" href="http://zackbloom.com/history.html">
<link rel="past-url" href="http://zack.is/history.html">


Формат application/x-www-form-urlencoded — это аномальный монстр во многих отношениях, результат многих лет случайностей реализаций и компромиссов, которые привели к необходимому для интероперабельности набору требований. Но это точно не образец хорошей архитектуры.

— WhatWG URL Spec

Если вы использовали веб какое-то время, то вам знакомы параметры запросов. Они находятся после пути и нужны для кодирования параметров вроде ?name=zack&state=mi. Может показаться странным, что запросы используют символ амперсанда (&), который в HTML используется для кодирования специальных символов. Если вы писали на HTML, то скорее всего столкнулись с необходимостью кодировать амперсанды в URL, превращая http://host/?x=1&y=2 в http://host/?x=1&amp;y=2 или http://host?x=1&#38;y=2 (конкретно эта путаница существовала всегда).

Возможно, вы также замечали, что куки (cookies) используют похожий, но все же иной формат: x=1;y=2, и он никак не конфликтует с символами HTML. W3C не забыл про эту идею и рекомендовал всем поддерживать как ;, так и & в параметрах запросов еще в 1995 году.

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

Так или иначе, физикам нужен был способ кодирования и связывания информации, и способ поиска этой информации. Для этого Тим Бернерс-Ли создал тег <ISINDEX>. Если <ISINDEX> присутствовал на странице, то браузер знал, что по этой странице можно делать поиск. Браузер показывал поисковую строку и позволял пользователю делать запрос на сервер.

Запрос представлял собой набор ключевых слов, отделенных друг от друга плюсами (+):

http://cernvm/FIND/?sgml+cms

Как это обычно случается в интернете, тег стали использовать для всего подряд, в том числе как поле ввода числа для вычисления квадратного корня. Вскоре предложили принять тот факт, что такое поле слишком специфично, и нужен тег общего характера <input>.

В том предложении использовался символ плюса для отделения компонентов запроса, но в остальном все напоминает современный GET-запрос:

http://somehost.somewhere/some/path?x=xxxx+y=yyyy+z=zzzz

Далеко не все одобрили это. Некоторые считали, что нужен способ указать поддержку поиска по ту сторону ссылки:

<a HREF="wais://quake.think.com/INFO" INDEX=1>search</a>

Тим Бернерс-Ли думал, что нужен способ определения строго типизированных запросов:

<ISINDEX TYPE="iana:/www/classes/query/personalinfo">

Изучая прошлое, готов с определенной долей уверенности сказать: я рад, что победило более общее решение.

Работа над тегом <INPUT> началась в январе 1993 года, она основывалась на более старом типе SGML. Было решено (пожалуй, к сожалению), что тегу <SELECT> нужна своя, более широкая структура:

<select name=FIELDNAME type=CHOICETYPE [value=VALUE] [help=HELPUDI]>
<choice>item 1
<choice>item 2
<choice>item 3
</select>

Если вам любопытно, то да, была идея повторно использовать элемент <li> вместо создания нового <option>. Однако, были и другие предложения. В одном из них происходила замена переменных, что напоминает современный Angular:

<ENTRYBLANK TYPE=int LENGTH=length DEFAULT=default VAR=lval>
Prompt </ENTRYBLANK>
<QUESTION TYPE=float DEFAULT=default VAR=lval> Prompt </QUESTION>
<CHOICE DEFAULT=default VAR=lval>
<ALTERNATIVE VAL=value1> Prompt1
...
<ALTERNATIVE VAL=valuen> Promptn
</CHOICE>

В этом примере проверяется тип input’ов на основе указания type, а значения VAR доступны на странице для замены строк в URL, примерно так:

http://eager.io/apps/$appId

Дополнительные предложения использовали @ вместо = для разделения компонентов запроса:

name@value+name@(value&value)

Марк Андриссен предложил метод, основанный на том, что он уже реализовал в Mosaic:

name=value&name=value&name=value

Всего два месяца спустя Mosaic добавил поддержку method=POST в формы, и так родились современные HTML-формы.

Конечно, компания Netscape Марка Андриссена создала еще и формат куки (с другим разделителем). Их предложение было болезненно недальновидным, оно привело к попытке создания заголовка Set-Cookie2, и создало фундаментальные структурные проблемы, с которыми нам все еще приходится иметь дело в продукте Eager.


Часть URL после символа ‘#’ известна как «фрагмент» (fragment). Фрагменты были частью URL со времен первой спецификации, они использовались для создания ссылки на конкретное место на загруженной странице. Например, если у меня есть якорь на сайте:

<a name="bio"></a>

Я могу сделать на него ссылку:

http://zack.is/#bio

Эта концепция постепенно была расширена до всех элементов (а не только якорей), и перешла на атрибут id вместо name:

<h2>Bio</h2>

Тим Бернерс-Ли решил использовать этот символ, основываясь на связи с форматом почтовых адресов в США (не смотря на то, что сам Тим — британец). По его словам:


Как минимум в США в почтовых адресах часто используют знак номера для указания номера квартиры или комнаты в здании. 12 Acacia Av #12 означает «Здание 12 на Акация Авеню, и в этом здании квартира 12». Этот символ казался естественным для такой цели. Сегодня http://www.example.com/foo#bar означает «На ресурсе http://www.example.com/foo конкретный вид, известный как bar”.

Оказывается, первичная система гипертекста, созданная Дугласом Энгельбартом, также использовала «#» для таких целей. Это может быть совпадением или случайным «заимствованием идеи».

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


Кротовые холмики и горы


Есть целый стандарт, такой же мерзкий как SGML, созданный для передачи электронных данных, другими словами — для форм и отправки форм. Единственное, что мне известно: он выглядит как фортран задом наперед без пробелов.

— Тим Бернерс-Ли, 1993

Есть ощущение, разделяемое многими, что организации, отвечающие за стандарты интернета ничего особо не делали с момента окончательного принятия HTTP 1.1. и HTML 4.01 в 2002 до тех пор, пока HTML 5 не стал по-настоящему популярным. Этот период также известен (только для меня) как Темный Век XHTML. В реальности люди, занимающиеся стандартами, были безумно заняты. Просто они занимались тем, что в итоге оказалось не слишком ценным.

Одним из направлений было создание Семантического Веба. Была мечта: создать Фреймворк Описания Ресурсов (Resource Description Framework). (прим. ред.: бегите от любой команды, которая хочет сделать фреймворк). Такой фреймворк позволял бы универсально описывать мета-информацию о содержании. Например, вместо того, чтобы делать красивую веб-страницу про мой Корвет Стингрэй, я бы сделал RDF-документ с описанием размеров, цвета и количества штрафов за превышение скорости, которые мне выписали за все время езды.

Это, конечно, совсем не плохая идея. Но формат был основан на XML, и это большая проблема курицы и яйца: нужно задокументировать весь мир, и нужны браузеры, которые умеют делать полезные штуки с этой документацией.

Но эта идея хотя бы родила условия для философских споров. Один из лучших подобных споров длился как минимум десять лет, он известен под искусным кодовым именем ‘httpRange-14’.

Целью httpRange-14 было ответить на фундаментальный вопрос «чем является URL?». Всегда ли URL ссылается на документ или он может ссылаться на все, что угодно? Может ли URL ссылаться на мою машину?

Они не пытались ответить на этот вопрос хоть сколько-нибудь удовлетворительно. Вместо этого они фокусировались на том, как и когда можно использовать редирект 303 чтобы сообщить пользователю, что по ссылке нет документа, и перенаправить его туда, где документ есть. И на том, когда можно использовать фрагменты (часть после ‘#’), чтобы направлять пользователей на связанные данные.

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

Но Семантический Веб заботился только о семантике.

Эта конкретная тема обсуждалась 1 июля 2002 года, 15 июля 2002 года, 22 июля 2002 года, 29 июля 2002 года, 16 сентября 2002 года, и как минимум еще 20 раз в течение 2005 года. Обсуждение закончилось благодаря тому самому ‘решению httpRange-14’ в 2005 году, и к нему вернулись снова из-за жалоб в 2007 и 2011, а запрос новых решений был открыт в 2012. Вопрос долго обсуждался группой pedantic web, у которой очень подходящее название. Единственное, чего так и не произошло — никакие из этих семантических данных так и не были добавлены в веб в какой-либо URL.


Авторизация

Как вы знаете, в URL можно включить логин и пароль:

http://zack:[email protected]

Браузер кодирует эти данные в формат Base64 и посылает в виде заголовка:

Authentication: Basic emFjazpzaGhoaGho

Base64 используется только для того, чтобы можно было передавать запрещенные в заголовках символы. Он никак не скрывает логин и пароль.

Это было проблемой, особенно до распространения SSL. Любой человек, который следит за вашим соединением, мог с легкостью увидеть пароль. Предлагали много альтернатив, в том числе Kerberos, который был и остается популярным протоколом безопасности.

Как и с другими примерами нашей истории, простую базовую авторизацию было проще всего реализовать разработчикам браузеров (Mosaic). Так базовая авторизация стала первым и единственным решением до тех пор, пока разработчики не получили инструменты для создания собственных систем аутентификации.


Веб-приложение

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

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

Абсолютный и относительный путь к файлам

При разработке сайта часто приходится прописывать пути к файлам, ссылки на документы, страницы.
В книгах по компьютерным технологиям можно часто встретить употребление терминов абсолютного и относительного пути к файлам. Часто автор не разъясняет, что означает тот или иной путь. Читатель, соответственно, путается, когда автор в последствии говорит об использовании абсолютного и(или) относительного пути.
Допустим, у Вас есть сайт и Вам нужно создать гиперссылку(ссылку) на одну из страниц сайта. Здесь нужно выбрать какой использовать тип пути: относительный или абсолютный.

Абсолютный и относительный путь к файлам

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

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

Оглавление

  1. Абсолютный путь
  2. Относительный путь
  3. Путь относительно документа
  4. Путь относительно корня сайта

Абсолютный путь

Когда ссылка представляет из себя полный URL файла или страницы, это и есть абсолютный путь. При этом в адресе должен присутствовать используемый протокол. Например, http://www.uamedwed.com — это абсолютный путь к конкретному веб-сайту. В данном случае абсолютный путь к главной странице моего блога. Где протоколом является http, а www.uamedwed.com доменом(именем).

Если указывать ссылку на католог, например http://yourdomain.ua/web/ то будет загружаться(отображаться) индексный файл. Это правило применимо в основном к статическим сайтам. Так как при использовании языка программирования можно создать внутренний роутинг. Индексный файл обычно представляет из себя файл с именем index.php, index.html, index.phtml, index.shtml. Для того что бы использовать другой индексный файл, нужно создать в нужной директории файл с именем .htaccess, и в нем прописать некоторую директиву. Изменение и создание файла .htaccess, как и роутинг с помощью языка программирования, выходит за рамки этой статьи.

В основном абсолютный путь используется, тогда, когда нужно сослаться на другой сайт. Иными словами если Вы хотите отправить посетителя на другой сайт, то нужно использовать абсолютный путь. Хотя, такой путь можно использовать и на собственном сайте. Но многие придерживаются того, что ссылки внутри сайта должны быть относительными.
Использование абсолютного пути может повлечь за собой некоторые проблемы. Например при переносе сайта с локальной машины на сервер(это в том случае, если вы использовали на локальной машине адреса в виде http://localhost/sitename.ua/…). Трудности могут возникнуть, тогда, когда появится необходимость в смене домена(имени сайта). Хотя, все эти трудности решаемы, но на них придётся потратить некоторое количество времени.
Когда есть минусы, значит должны быть и плюсы. Возьмём к примеру такую ситуацию, как кража контента с вашего сайта. На практике я уже не раз убедился в том, что текст воруют целиком, при этом не оставляя обратной ссылки на оригинал. Так вот, при использовании абсолютных путей, можно получить обратные ссылки с сайта, на котором находится сворованный контент. Но это только в том случае если у Вас внутренняя перелинковка осуществлялась с использованием абсолютных путей. Хотя это не всегда работает, но я уже не раз замечал появление ссылок с чужих сайтов, на которых был расположен мой контент.

Немного отступив от темы хочу вкратце рассказать про то что такое URL.

Каждая веб-страница или документ в сети Интернет имеет собственный уникальный адрес, который и называется URL.
URL — единообразный локатор (определитель местонахождения) ресурса. Расшифровывается URL как Uniform Resource Locator(унифицированный адрес ресурса). Можно так же встретить и такую расшифровку как Universal Resource Locator(универсальный локатор ресурса). Этот способ записи адреса стандартизирован в сети Интернет. Более общая и широкая система идентификации ресурсов URI постепенно заменяет термин URL.
URI — это символьная строка, которая идентифицирует какой-либо ресурс: документ, файл, и т.д. Конечно, здесь подразумеваются ресурсы сети Интернет.

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

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

Путь относительно документа

Именно путь относительно документа используется чаще всего. Такие ссылки ещё называются локальными. В основном такой путь используется тогда, когда текущий и связанный документ(страница) находятся в одной директории. Если переместить документ в другую директорию, то путь(ссылку) придётся менять. Хотя можно ссылаться и на документы(страницы) из других директорий. Для этого путь прописывается от текущего документа до целевого документа(страницы). При этом путь относительно документа должен задаваться в зависимости от структуры директорий.
Возьмём к примеру простейшую структуру статического сайта.

Абсолютный и относительный путь к файлам

Предположим, что каждое изображение в каталоге images нужно вставить в соответствующие страницы home.html, products.html, contact.html. Для того что бы вставить изображение к примеру на страницу «home.html», нужно прописать путь, где расположено изображение. Если использовать путь относительно документа, то нужно будет прописать в коде страницы следующее:

<img src="images/home.png">

<img src=»images/home.png»>

Этот код для вставки изображения на страницу — неполный. Так как он не содержит нескольких важных атрибутов, таких как ширина, высота и др. Атрибут src, здесь служит для указания пути к файлу. Здесь опущены все остальные атрибуты, так как они сейчас не столь важны. Главное сейчас, что бы Вы имели представление о том, как выглядит путь относительно документа.
При использовании путей относительно документа отсутствует часть абсолютного пути. Часть абсолютного пути, здесь усекается, как для текущего документа(страницы), так и для связанного. Здесь используется только та часть пути, которая всегда меняется.
Напомню ещё раз про то, что при использовании пути относительно документа, нужно учитывать исходное расположение файлов.

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

Абсолютный и относительный путь к файлам

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

<img src="../images/products.png">

<img src=»../images/products.png»>

Как видно из приведённого выше кода, к пути теперь добавилось следующее: ../. Как раз эта последовательность символов ../ и служит для перехода на одну директорию(уровень) выше в иерархии каталогов. Путь в вышеприведённом коде можно прочесть так: «Перейти на один каталог выше(назад), зайти в директорию images и взять от туда файл products.png«.
Если ../ означает переход на одну директорию(уровень) выше в иерархии каталогов, то символ / обозначает переход на один уровень ниже.
Последовательность символов ../ можно использовать в пути неоднократно. Например, если файл products.html переместить в три директории вложенные в друг друга, то нужно будет использовать следующий код:

<img src="../../../images/products.png">

<img src=»../../../images/products.png»>

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

Путь относительно корня сайта

Вы наверное уже поняли что пути относительно документа используются очень часто. Но при их использовании существует одна проблема. Которая заключается в том, что при смене структуры директорий, пути придется менять.
Но такая проблема решаема при использовании путей относительно корня сайта. Где путь указывается от корневой директории до документа.
Все пути относительно корня сайта начинаются со знака /. Только здесь, в отличии от путей относительно документа этот знак используется для указания корневой директории. Потому, что он используется в начале пути.
Путь относительно корня сайта позволяет перемещать некоторые файлы, без ущерба для ссылок. Этот тип пути Вы сможете использовать только на web-сервере в интернете, или на web-сервере расположенном на локальной машине.

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

Корневой относительный путь не содержит ни протокола http, ни доменного имени. И как я уже говорил начинается с указания символа /, который указывает на корневую директорию. В этой директории обычно располагается индексный файл главной страницы.

Например, /images/products.png обозначает, что файл products.png находится в папке images, которая расположена в корневом каталоге.

Самый простой способ определить корневой относительный путь — взять абсолютный и отбросить http:// и имя хоста.

Пример
Иногда бывает нужно, что бы информацию одной страницы использовали другие страницы сайта. Часто это делается для того что бы сократить количество повторяемого кода на каждой странице. Допустим есть файл _contact.html, который содержит информацию о телефонных номерах, e-mail и содержит изображение contact.png. (Пускай это будет небольшая таблица, которая будет располагаться на каждой странице сайта.)

Абсолютный и относительный путь к файлам

Следующий код предназначен для вставки изображения «contact.png».

<img src="images/contact.png">

<img src=»images/contact.png»>

Код, который необходим для вставки одного файла в другой, выходит за рамки этой статьи. Здесь все зависит от используемого языка программирования.

Я надеюсь, что Вы уже знаете какой тип пути использовался в вышеприведённом коде. Если нет, тогда посмотрите приведённое выше определение пути относительно документа.
Теперь, когда посетитель зайдет на такие страницы сайта как home.html, contact.ntml, он увидит прекрасно отображаемую страницу. В каждую из которых вставлен файл _contact.html, в который, в свою очередь, вставлено изображение contact.png.
Другими словами зайдя, к примеру, на страницу home.html, происходит следующее: «Выполняется код основной страницы home.html. Затем вставляется и исполняется код страницы _contact.html. Код страницы _contact.html, говорит что нужно перейти в директорию images и взять от туда изображение contact.png«.
Если опустить сам код для вставки, то все работает отлично. Но вот если запустить страницу products.html, то произойдет ошибка. Так как код будет пытаться найти директорию images и файл contact.png в директории products. Но такой директории там не существует, из за чего собственно и возникает проблема.
Становится ясным, что использовать путь относительно документа здесь нельзя.
Конечно здесь можно использовать абсолютный путь. О плюсах и минусах данного подхода я говорил выше.
В общем говоря, это одна из ситуаций, когда нужно использовать путь относительно корня сайта. При использовании пути относительно корня сайта, ссылка будет всегда начинаться с корневого каталога(корня сайта). Такой тип пути позволит использовать код для вставки, например изображения, независимо от иерархии сайта, и его директорий.
Использование пути относительно корня сайта в вышеприведённом примере, позволит избежать проблем, со вставкой изображения. Потому как независимо от того где будет использовать такой тип пути, он всегда найдет указанный в нем файл.
Путь относительно корня сайта, очень похож на путь относительно документа. Для того что бы создать путь относительно корня сайта, нужно добавить символ / в начало пути.

<img src="/images/contact.png">

<img src=»/images/contact.png»>

Теперь изображение будет корректно вставляться на любой из страниц сайта.

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

Css url путь к файлу

Категории блога

При разработке сайта часто приходится прописывать пути к файлам, ссылки на документы, страницы.
В книгах по компьютерным технологиям можно часто встретить употребление терминов абсолютного и относительного пути к файлам. Часто автор не разъясняет, что означает тот или иной путь. Читатель, соответственно, путается, когда автор в последствии говорит об использовании абсолютного и(или) относительного пути.
Допустим, у Вас есть сайт и Вам нужно создать гиперссылку(ссылку) на одну из страниц сайта. Здесь нужно выбрать какой использовать тип пути: относительный или абсолютный.

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

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

Оглавление

Абсолютный путь

Когда ссылка представляет из себя полный URL файла или страницы, это и есть абсолютный путь. При этом в адресе должен присутствовать используемый протокол. Например, http://www.uamedwed.com — это абсолютный путь к конкретному веб-сайту. В данном случае абсолютный путь к главной странице моего блога. Где протоколом является http, а www.uamedwed.com доменом(именем).

Если указывать ссылку на католог, например http://yourdomain.ua/web/ то будет загружаться(отображаться) индексный файл. Это правило применимо в основном к статическим сайтам. Так как при использовании языка программирования можно создать внутренний роутинг. Индексный файл обычно представляет из себя файл с именем index.php, index.html, index.phtml, index.shtml. Для того что бы использовать другой индексный файл, нужно создать в нужной директории файл с именем .htaccess, и в нем прописать некоторую директиву. Изменение и создание файла .htaccess, как и роутинг с помощью языка программирования, выходит за рамки этой статьи.

В основном абсолютный путь используется, тогда, когда нужно сослаться на другой сайт. Иными словами если Вы хотите отправить посетителя на другой сайт, то нужно использовать абсолютный путь. Хотя, такой путь можно использовать и на собственном сайте. Но многие придерживаются того, что ссылки внутри сайта должны быть относительными.
Использование абсолютного пути может повлечь за собой некоторые проблемы. Например при переносе сайта с локальной машины на сервер(это в том случае, если вы использовали на локальной машине адреса в виде http://localhost/sitename.ua/…). Трудности могут возникнуть, тогда, когда появится необходимость в смене домена(имени сайта). Хотя, все эти трудности решаемы, но на них придётся потратить некоторое количество времени.
Когда есть минусы, значит должны быть и плюсы. Возьмём к примеру такую ситуацию, как кража контента с вашего сайта. На практике я уже не раз убедился в том, что текст воруют целиком, при этом не оставляя обратной ссылки на оригинал. Так вот, при использовании абсолютных путей, можно получить обратные ссылки с сайта, на котором находится сворованный контент. Но это только в том случае если у Вас внутренняя перелинковка осуществлялась с использованием абсолютных путей. Хотя это не всегда работает, но я уже не раз замечал появление ссылок с чужих сайтов, на которых был расположен мой контент.

Немного отступив от темы хочу вкратце рассказать про то что такое URL.

Каждая веб-страница или документ в сети Интернет имеет собственный уникальный адрес, который и называется URL.
URL — единообразный локатор (определитель местонахождения) ресурса. Расшифровывается URL как Uniform Resource Locator(унифицированный адрес ресурса). Можно так же встретить и такую расшифровку как Universal Resource Locator(универсальный локатор ресурса). Этот способ записи адреса стандартизирован в сети Интернет. Более общая и широкая система идентификации ресурсов URI постепенно заменяет термин URL.
URI — это символьная строка, которая идентифицирует какой-либо ресурс: документ, файл, и т.д. Конечно, здесь подразумеваются ресурсы сети Интернет.

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

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

Путь относительно документа

Именно путь относительно документа используется чаще всего. Такие ссылки ещё называются локальными. В основном такой путь используется тогда, когда текущий и связанный документ(страница) находятся в одной директории. Если переместить документ в другую директорию, то путь(ссылку) придётся менять. Хотя можно ссылаться и на документы(страницы) из других директорий. Для этого путь прописывается от текущего документа до целевого документа(страницы). При этом путь относительно документа должен задаваться в зависимости от структуры директорий.
Возьмём к примеру простейшую структуру статического сайта.

Предположим, что каждое изображение в каталоге images нужно вставить в соответствующие страницы home.html, products.html, contact.html. Для того что бы вставить изображение к примеру на страницу «home.html», нужно прописать путь, где расположено изображение. Если использовать путь относительно документа, то нужно будет прописать в коде страницы следующее:

Этот код для вставки изображения на страницу — неполный. Так как он не содержит нескольких важных атрибутов, таких как ширина, высота и др. Атрибут src, здесь служит для указания пути к файлу. Здесь опущены все остальные атрибуты, так как они сейчас не столь важны. Главное сейчас, что бы Вы имели представление о том, как выглядит путь относительно документа.
При использовании путей относительно документа отсутствует часть абсолютного пути. Часть абсолютного пути, здесь усекается, как для текущего документа(страницы), так и для связанного. Здесь используется только та часть пути, которая всегда меняется.
Напомню ещё раз про то, что при использовании пути относительно документа, нужно учитывать исходное расположение файлов.

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

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

Как видно из приведённого выше кода, к пути теперь добавилось следующее: ../. Как раз эта последовательность символов ../ и служит для перехода на одну директорию(уровень) выше в иерархии каталогов. Путь в вышеприведённом коде можно прочесть так: «Перейти на один каталог выше(назад), зайти в директорию images и взять от туда файл products.png«.
Если ../ означает переход на одну директорию(уровень) выше в иерархии каталогов, то символ / обозначает переход на один уровень ниже.
Последовательность символов ../ можно использовать в пути неоднократно. Например, если файл products.html переместить в три директории вложенные в друг друга, то нужно будет использовать следующий код:

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

Путь относительно корня сайта

Вы наверное уже поняли что пути относительно документа используются очень часто. Но при их использовании существует одна проблема. Которая заключается в том, что при смене структуры директорий, пути придется менять.
Но такая проблема решаема при использовании путей относительно корня сайта. Где путь указывается от корневой директории до документа.
Все пути относительно корня сайта начинаются со знака /. Только здесь, в отличии от путей относительно документа этот знак используется для указания корневой директории. Потому, что он используется в начале пути.
Путь относительно корня сайта позволяет перемещать некоторые файлы, без ущерба для ссылок. Этот тип пути Вы сможете использовать только на web-сервере в интернете, или на web-сервере расположенном на локальной машине.

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

Корневой относительный путь не содержит ни протокола http, ни доменного имени. И как я уже говорил начинается с указания символа /, который указывает на корневую директорию. В этой директории обычно располагается индексный файл главной страницы.

Например, /images/products.png обозначает, что файл products.png находится в папке images, которая расположена в корневом каталоге.

Самый простой способ определить корневой относительный путь — взять абсолютный и отбросить http:// и имя хоста.

Пример
Иногда бывает нужно, что бы информацию одной страницы использовали другие страницы сайта. Часто это делается для того что бы сократить количество повторяемого кода на каждой странице. Допустим есть файл _contact.html, который содержит информацию о телефонных номерах, e-mail и содержит изображение contact.png. (Пускай это будет небольшая таблица, которая будет располагаться на каждой странице сайта.)

Следующий код предназначен для вставки изображения «contact.png».

Код, который необходим для вставки одного файла в другой, выходит за рамки этой статьи. Здесь все зависит от используемого языка программирования.

Я надеюсь, что Вы уже знаете какой тип пути использовался в вышеприведённом коде. Если нет, тогда посмотрите приведённое выше определение пути относительно документа.
Теперь, когда посетитель зайдет на такие страницы сайта как home.html, contact.ntml, он увидит прекрасно отображаемую страницу. В каждую из которых вставлен файл _contact.html, в который, в свою очередь, вставлено изображение contact.png.
Другими словами зайдя, к примеру, на страницу home.html, происходит следующее: «Выполняется код основной страницы home.html. Затем вставляется и исполняется код страницы _contact.html. Код страницы _contact.html, говорит что нужно перейти в директорию images и взять от туда изображение contact.png«.
Если опустить сам код для вставки, то все работает отлично. Но вот если запустить страницу products.html, то произойдет ошибка. Так как код будет пытаться найти директорию images и файл contact.png в директории products. Но такой директории там не существует, из за чего собственно и возникает проблема.
Становится ясным, что использовать путь относительно документа здесь нельзя.
Конечно здесь можно использовать абсолютный путь. О плюсах и минусах данного подхода я говорил выше.
В общем говоря, это одна из ситуаций, когда нужно использовать путь относительно корня сайта. При использовании пути относительно корня сайта, ссылка будет всегда начинаться с корневого каталога(корня сайта). Такой тип пути позволит использовать код для вставки, например изображения, независимо от иерархии сайта, и его директорий.
Использование пути относительно корня сайта в вышеприведённом примере, позволит избежать проблем, со вставкой изображения. Потому как независимо от того где будет использовать такой тип пути, он всегда найдет указанный в нем файл.
Путь относительно корня сайта, очень похож на путь относительно документа. Для того что бы создать путь относительно корня сайта, нужно добавить символ / в начало пути.

Теперь изображение будет корректно вставляться на любой из страниц сайта.

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

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

Итак, начнем с определения самого термина «путь»:

Путь (англ. path) — набор символов, показывающий расположение файла в файловой системе, адрес каталога.

Если говорить о сайтах, то путь — это то же, что и ссылка. Ссылки могут быть абсолютными и относительными. Рассмотрим оба варианта более подробно.

Что такое абсолютный путь к файлу

Абсолютный адрес ссылки на файл включает в себя протокол (например, http:// ), имя сайта в Сети, подкаталог (или несколько подкаталогов), название файла. Пример того, как выглядит абсолютный URL:

Абсолютный путь можно использовать в CSS. Например, чтобы задать рисунок в качестве фона, вы можете взять абсолютный URL к файлу с изображением И указать его в таблице стилей:

Абсолютная ссылка всегда будет указывать на одно и то же место, независимо от того, где расположен содержащий ее документ (в нашем случае таблица стилей). Чего не скажешь об относительной ссылке.

Что такое относительный путь к файлу

С относительным адресом всё намного интереснее — он может отсчитываться как от корня сайта, так и от текущего документа. Корневой относительный путь — это путь, который указывает на расположение файла относительно корневого каталога сайта. В этом случае адрес не содержит ни протокола, ни имени домена, и начинается со знака слэша / , который указывает на корневую папку. Выглядит этот адрес так:

Как легко определить корневой относительный адрес? Просто возьмите абсолютную ссылку и уберите из нее протокол и название домена, оставив слэш и все символы, которые идут дальше.

Относительный путь к файлу от документа — это путь к файлу относительно текущего документа. Такой адрес зависит от расположения файла, в котором он записан. Так, когда относительная ссылка указывается в та­блице стилей, она рассчитывает путь к файлу, отталкиваясь от таблицы стилей, а не от текущей веб-страницы либо корневой папки. Приведем несколько примеров.

Пример I

Если наша таблица стилей style.css и файл с фоновым рисунком bg.png находятся в одной папке (не обязательно корневой), то относительный путь от таблицы до рисунка будет выглядеть так:

Пример II

Если таблица стилей находится в корне, а рисунок — в папке img , относительная ссылка будет таковой:

Пример III

Если таблица стилей находится в папке, а рисунок соседствует с этой папкой, то относительный путь будет таким:

Пример IV

Если таблица стилей находится в двух папках, а рисунок соседствует с первой папкой, то относительный путь будет следующий:

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

В том случае, когда рисунок спрятан в папку img , а таблица стилей — в папку css , вам понадобится выйти из папки css и зайти в папку img . Вот так:

Если папок несколько, необходимо также прописать их. Изменим предыдущий пример: представим, что в папке img есть еще одна папка backgrounds , в которой лежит наш рисунок. Относительный путь будет таким:

Какой путь лучше использовать

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

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

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

Попробуйте потренироваться в использовании относительных путей как на локальном компьютере, так и на веб-сервере. Понимание того, как это работает, непременно пригодится вам в любом проекте.

Далее в учебнике: свойство background-repeat — управление повтором фонового изображения.

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

Навигация по статье:

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

Что такое абсолютный путь к файлу?

Если говорить простым языком, то это полный путь к файлу, который содержит в себе название сайта, протокол http или https, название папок, внутри которых он находится, а так же его имя и расширение.

Например, для картинки image.png, которая лежит в папке images на вашем хостинге абсолютный путь будет выглядеть так:

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

Посмотреть этот путь можно в адресной строке:

Как определить абсолютный путь к файлу у себя на хостинге?

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

В этом случае нам нужно:

    1. Найти папку, в которой лежат файлы сайта.
    Например, в случае с CMS WordPress в ней должны находиться папки «wp-admin», «wp-content» и так далее.

Потом приписываем к нему скопированный адрес папки с загруженным файлом и в конце пишем название его название и расширение.

Особенности абсолютного пути:

  • указанный адрес будет работать при его использовании на других сайтах или страницах
  • при смене домена основного сайта или при переходе на https адреса в этом пути тоже нужно будет менять.

Что такое относительный путь к файлу?

С эти немного сложнее. Относительный путь к файлу указывается относительно расположения того файла в коде которого он указывается. Давайте разберём на конкретных примерах.

Пример 1.
Допустим, мы вставляем картинку в index.html, который лежит в папке с доменом. Там же в папке с доменом находится папка images с нашей картинкой.

Относительный путь будет выглядеть так:

Пример 2.
Нам нужно указать относительный путь к картинке в файле style.css, который лежит в папке CSS. При этом сама картинка находится не папке images.

В этом случае если мы просто напишем /images/image.png, как в предыдущем примере, то это не сработает!

Браузер будет воспринимать эту запись так: «Зайди в папку images, которая лежит рядом с файлом style.css и возьми там файл image.png». Проблема в том, что в рядом с style.css нет никакой папки images! Она находится на уровень выше.

В таком случае мы должны как бы сказать браузеру: «Сначала выйди из папки CSS, в которой лежит style.css в котором мы указываем наш абсолютный путь, а потом зайди в папку images и возьми там файл image.png»

На языке кода команда «выйди из папки» будет выглядеть так: ../

В итоге получим:

Пример 3.

Если нужная картинка лежит рядом с файлом, в коде которого вы пишете путь, то это будет выглядеть так:

Особенности относительного пути:

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

Определение пути к файлу в WordPress и других CMS

При работе с движками для отображения определённых файлов на сайте вам нужно указывать пути к ним или в админке или коде темы или шаблона.

Если вы вносите правки в коде, то указывать относительный путь вы должны относительно файла index.php который лежит в папке с доменом.

Получается, что вы вносите правки в файле шаблона, но путь должны указывать как будто бы вы работаете с index.php в корне сайта. Такова особенность работы движков.

Если вы указываете адрес внутри скрипта или CSS файла, то путь указывается относительно этого файла.

Так же в WordPerss есть специальные функции, которые избавят вас от необходимости бродить по папкам и гадать какой адрес нужно указывать. Эти функции возвращают абсолютный путь к папке с темой. Их несколько, но я обычно использую вот эту:

Рекомендуем к прочтению

URI — сложно о простом (Часть 1) / Habr

Привет хабр!

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

«Пфф, ссылки они и в Африке ссылки, чего тут разбираться?» — скажете вы, тогда я задам вопрос:

Что есть что и куда нас приведет?


Если вы не знаете однозначного ответа или вам просто интересно и если вы не боитесь огромного количества трехбуквенных аббревиатур — милости прошу под кат.

Перед тем как начать хотел бы обозначить, что есть пост на схожую тему, в котором все обозначено проще и немного понятнее. Целью же этого поста, я ставлю более глубокое изучение вопроса и сбор информации об URI в одном месте, дабы «не потерять». Ну, почти в одном месте, статья будет разделена на две части
А для удобства бахнем оглавление, которое работает не без особенностей URI, которую мы рассмотрим попозжа, в этой статье.

ОГЛАВЛЕНИЕ

  1. URI
    1.1. Синтаксис
    1.2. Компоненты URI
  2. URL
    2.1. Структура
  3. URN
    3.1. Структура

Ознакомление


1. URI


Унифицированный Идентификатор Ресурса, в простонародье — URI
Самое свежее описание того, чем же все-таки являются эти пресловутые URI датируется январем аж 2005-го, а именно RFC3986, написанный самим Тимом Бёнесом-Ли, родоначальника всеми нами любимого тырнета.
Резюмируя п.1.1 можно сформулировать определение:

URI — последовательность символов, идентифицирующая физический или абстрактный ресурс, который не обязательно должен быть доступен через сеть Интернет, причем, тип ресурса, к которому будет получен доступ, определяется контекстом и/или механизмом.
Например:

  • перейдя по http://example.com — мы попадем на http-сервер ресурса идентифицируемого как example.com
  • в то же время ftp://example.com — приведет наc на ftp-сервер того же самого ресурса
  • или например http://localhost/ — URI идентифицирующий саму машину откуда производится доступ

В современном интернете, чаще всего используется две разновидности URIURL и URN.
Основное различие между ними — в задачах:
  • URLUniform Resource Locator, помогает найти какой либо ресурс
  • URNUniform Resource Name, помогает этот ресурс идентифицировать

Упрощая: URL — отвечает на вопрос: «Где и как найти что-то?», URN — отвечает на вопрос: «Как это что-то идентифицировать».
Парочка интересностей про URIМногие из вас замечали, что на разных ресурсах ссылки называют то URL, то URI и, вероятно, становилось интересно — какой же из вариантов правильный?
Дело в том, что URL увидел свет и был документирован в 1990 году, в то время как URI был документирован лишь в 1994 году. И вплоть до 2002 года, до выхода RFC3305, уместными были оба варианта именования, что, порой вносило путаницу.
В п.2 RFC3305 сообщается об устаревании такого термина как URL, применимо к ссылкам, и что отныне верным будет именование URI, с того момента, во всех документах W3C использует термин URI. Исходя из этого, применяя термин URL к соответствующим ссылкам, вы не делаете смысловой ошибки, но делаете ее с точки зрения правильного именования.

Так же примечателен тот момент, что вплоть до выхода RFC2396, в 1997 году, URI расшифровывался как Universal Resource Identifier, что можно увидеть в RFC1630

Обобщая всевозможные варианты, URI имеет следующий вид:

Забегая вперед, стоит отметить, что не все три компоненты являются строго обязательными. Для того чтобы ссылка считалась URI необходимо наличие:

  • либо scheme+authority+path,
  • либо sheme+path,
  • либо только path.
1.1. Синтаксис

Согласно п.2 RFC3986:
URI составлен из ограниченного набора символов, состоящих из цифр, букв и нескольких графических символов, все эти символы вписываются в кодировку US-ASCII (ASCII). Зарезервированное подмножество символов может использоваться, чтобы разграничить компоненты синтаксиса в URI, в то время как остающиеся символы: не зарезервированный набор и включая те зарезервированные символы, которые не действуют как разделители в данной компоненте URI, определяют данные идентификации каждого компонента.

Зарезервированные символы
Зарезервированные символы делятся на два типа:
  • gen-delims, они же «главные разделители», т.е. символы, разделяющие URI на крупные компоненты.
     ":", "/", "?", "#", "[", "]", "@"
  • sub-delims, они же «под разделители» — символы, которые разделяют текущую крупную компоненту, на более мелкие составляющие, для каждой компоненты они свои, вот список самых распространенных:
     "!", "$", "&", "'", "(", ")", "*", "+", ",", ";", "="

Не зарезервированные символы
Исходя из предыдущего пункта, не зарезервированные символы — символы, не входящие в gen-delims, а так же не значимые для данной компоненты sub-delims. Но в общем случае это:
ALPHA, DIGIT, "-", ".", "_", "~"
Для данного случая, согласно ABNF:
ALPHA — любая буква верхнего и нижнего регистров кодировки ASCII (в regExp [A-Za-z])
DIGIT — любая цифра (в regExp [0-9])
HEXDIG — шестнадцатиричная цифра (в regExp [0-9A-F])

Процентное кодирование
В случае, если используются символы выходящие за пределы кодировки ASCII используется механизм т.н. «Процентного кодирования«. Так же он применяется для передачи зарезервированных символов в составе данных. Зарезервированные символы, по правилам, не участвуют в процентном кодировании.
Процентно-кодированный символ представляет из себя символьный триплет, состоящий из знака «%» и следующих за ним двух шестнадцатиричных чисел:
pct-encoded = "%" HEXDIG HEXDIG
Т.о., %20, например, означает пробел.
1.2. Компоненты URI

Следующий список содержит описания крупных компонент, составляющих URI:
  • Scheme (схема)
    Каждый URI начинается с имени схемы, которое относится к спецификации для присвоения идентификаторов в этой схеме. Также, синтаксис URI — объединенная и расширяемая система именования, причем, спецификация каждой схемы может далее ограничить синтаксис и семантику идентификаторов, использующих эту схему.
    Название схемы обязательно начинается с буквы и далее может быть продолжено любым количеством разрешенных символов.
    Разрешенные символы для схемы:
    ALPHA, DIGIT, "+", "-", "."
  • Authority (честно говоря, не знаю как перевести слово на русский, без потери смысла)
    Компонента authority начинается с двойного слеша(//) и заканчивается следующим слешем(/), знаком вопроса(?) или октоторпом(#)(да-да, «решеточка» зовется именно так=)) или концом URI
    Authority состоит из:
    [ userinfo "@" ] host [ ":" port ]
    где в квадратных скобках опциональные компоненты
    Каждую из подкомпонент, отдельно, мы рассмотрим чуть позже, в разделе посвященном URL.
  • Path (Путь)
    Компонента пути содержит данные, обычно, организованные в иерархической форме, которые, вместе с данными в неиерархическом компоненте запроса (Query), служит, чтобы идентифицировать ресурс в рамках схемы URI и authority (если таковая компонента указана).
    Путь начинается со слеша(/) и заканчивается знаком вопроса(?), октоторпом(#) или концом URI
    Разрешенные символы для пути:
    Не зарезервированные, процентно-кодированные, sub-delims, ":", "@"
  • Query (Запрос)
    Компонента запроса содержит данные, организованные в неиерархической форме, которые, вместе с данными в иерархическом компоненте пути (Path), служит, чтобы идентифицировать ресурс в рамках схемы URI и authority (если таковая компонента указана).
    Запрос начинается с первого знака вопроса(?) и заканчивается октоторпом(#) или концом URI
    Разрешенные символы для запроса:
    Не зарезервированные, процентно-кодированные, sub-delims, ":", "@", "/", "?"
    В запросе чаще всего передаются данные в формате key=value (ключ=значение), значение рекомендуется передавать в процентно-кодированном виде, обусловлено это тем, что в значении может встретиться символ «&», который используется для разделения пар ключ-значение, в результате появления такого артефакта дальнейшая последовательность пар ключ-значение может быть нарушена.
  • Fragment (Фрагмент)
    Компонента фрагмент позволяет осуществить косвенную идентификацию вторичного ресурса по отношению к первому.
    Семантика фрагмента никак не ограничена, фрагмент начинается октоторпом(#) и заканчивается концом URI, при этом может состоять из абсолютно любого набора символов.
    Примером применения фрагментов является оглавление данной статьи. Оно состоит из относительных ссылок
    <a href="#someanchor"></a>
    а по статье, в определенных местах, раскиданы т.н. «якоря» — теги
    <anchor>someanchor</anchor>

    Переходя по указанной в оглавлении ссылке, браузер производит переход ко вторичному ресурсу относительно данной страницы, т.е. скроллит вниз, до появления нужного

    <anchor>
    на экране.

На этом, пожалуй, знакомство с URI можно закончить и начать углубляться в отдельные подвиды URI, а именно

2. URL


Стандарт URL документирован в RFC1738.
Из п.2:
URL используются, чтобы определить местоположение ресурсов, обеспечивая абстрактную идентификацию расположения ресурса. Определив местоположение ресурса, система может выполнить множество операций на ресурсе, которые могут быть характеризованы такими словами как ‘доступ’, ‘обновление’, ‘замена’, ‘поиск атрибутов’. В целом только метод доступа должен быть определен для любой схемы URL.
Т. о.: URL призван решить широкий ряд задач, начиная с получения и заканчивая изменением данных на ресурсе, а обязательным параметром для получения доступа — является метод, т. е. любой полноценный (абсолютный) URL можно свести к виду:
<scheme>:<часть свойственная этой схеме>

2.1. Структура

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

И вот, примерно на этом моменте, можно рассмотреть различия между абсолютными (absolute) и относительными (relative) URL, данные определения распространяются не только на URL, но и на URI в целом.

  • Относительная ссылка использует иерархический синтаксис, чтобы выразить ссылку URI относительно пространства имен другого иерархического URI.
    Относительные ссылки так же делятся на несколько подвидов:
    • Ссылка сетевого пути
      Имеет вид:
      //<authority> <path> [<query>] [<fragment>]
      Такой тип ссылок применяется не часто, смысл заключается в переходе по указанной ссылке с применением текущей схемы.
      Т. е.: находясь, например на http://example.com и перейдя по ссылке //domain.com — мы попадем на http://domain.com
      А в случае если перейдем по той же ссылке с ftp://example.com, то попадем на ftp://domain.com
    • Ссылка абсолютного пути
      Имеет вид:
      /<path> [<query>] [<fragment>]
      На этот раз мы останемся в пределах текущего хоста, но попадем по пути path в любом случае, по какому бы пути мы сейчас не находились.
      Т. е.: даже находясь на http://example.com/just/some/long/path и перейдя по ссылке /path, мы попадем на http://example.com/path
    • Ссылка относительного пути
      Имеет вид:
      <path> [<query>] [<fragment>]
      Теперь же, мы будем перемещаться в пределах текущего положения.
      Т. е.: находясь на http://example.com/just/some/long/path и перейдя по ссылке path, мы попадем на http://example.com/just/some/long/path/path
    • Ссылка того же документа
      Фактически это ссылки, состоящие только из фрагментарной части URI, либо же ссылки, у которых все компоненты за исключением фрагментарной совпадают с исходной.
      Т.е. #fragment и http://habrahabr.ru/topic/232385/#fragment являются ссылками того же документа.

  • Абсолютная ссылка — ссылка вида
    <scheme> <authority> [<path>] [<query>] [<fragment>]
    Применяя абсолютные ссылки, мы будем попадать на нужный нам ресурс вне зависимости от того, откуда мы переходим.
    Т. е.: находись мы на http://example.com/just/some/long/path или же на ftp://example.com, перейдя по http://domain.com/path, мы в любом случае попадем на http://domain.com/path

После того, как мы разобрались с тем, что же такое относительные и абсолютные пути — можно отвечать на вопрос заданный в начале поста:
  • http://example.com — откроет http://example.com
  • www.example.com — по-идее должен открыть http://habrahabr.ru/topic/232385/www.example.com, но хабр сам исправляет ссылку, хотя по стандартам www.example.com — ссылка относительного пути
  • //www.example.com — откроет www.example.com со схемой с которой вы просматриваете текущую страницу, т.е. скорее всего будет открыт http://example.com
  • mailto:[email protected] — здесь уже вступают в силу настройки браузера, он предложит вам открыть эту ссылку при помощи почтовой программы и отправить электронное письмо адресату [email protected], а так, это абсолютный URL со схемой mailto

Мы уже рассмотрели крупные компоненты, а теперь давайте углубимся в детали построения URL.
  • Scheme — как говорилось ранее: схема определяет метод доступа к ресурсу. Список актуальных схем можно посмотреть тут.
  • Userinfo — под-компонент authority, использующийся для авторизации пользователя на ресурсе. Состоит из username и необязательного password, от остальной части authority отделяется символом «@«. Не смотря на то, что параметр password указан в спецификации, его использование крайне не рекомендуется, т. к. фактически производится передача пароля к учетной записи username, в незашифрованном виде.
    Разрешенные символы:
    Не зарезервированные, процентно-кодированные, sub-delims, ":"

    Пример можно привести следующий:
    На локалке есть папка test, на которую стоит доступ по паре логин-пароль. То есть, перейдя по http://localhost/test/, я увижу следующее:
    А если я перейду по ссылке http://admin:admin@localhost/test/, то процедура авторизации произойдет автоматически, с данными указанными в блоке userinfo:
  • Host — компонент authority, использующийся для определения целевого узла (или ресурса, если угодно, но понятие «узел» будет более точным), который может находиться как в сети интернет, так и вне её, в зависимости от указанной схемы. Данная компонента не чувствительна к регистру.
    Хост может представлять из себя либо IP-адрес, либо регистрационное имя (reg-name) и, опционально, следующий за ними порт(port).
    Предусматривается как поддержка существующих форматов IP-адресов (IPv4, IPv6), так и всевозможных будущих, которые будут описаны впоследствии.
    Регистрационное имя — привычные нам, т. н. доменные имена — последовательность символов, обычно предназначенных для поиска в локально определенном узле или реестре имени службы, хотя специфичная для схемы семантика URI может потребовать, чтобы вместо этого использовался определенный реестр (или фиксированная таблица имен).
    Наиболее распространенный механизм реестра имен — Система Доменных Имен (DNS).
    Доменное имя, используемое для поиска в DNS, состоит из доменных меток, разделенных при помощи «.», каждая доменная метка может содержать следующие символы:
    Не зарезервированные, процентно-кодированные, sub-delims
    Синтаксис регистрационного имени позволяет использование процентно-кодированных символов, для представления не-ASCII символов, в едином порядке, не зависящем от технологии разрешения имен. Символы, не входящие в ASCII, должны быть сначала закодированы в UTF-8, а затем каждый октет UTF-8 последовательности должен быть процентно закодирован.
    В случае, если регистрационное имя с не-ASCII символами представляет собой многоязычное доменное имя, разрешаемое через DNS, оно должно быть преобразовано в кодировку IDNA (RFC3490) до поиска имени и, как следствие, регистраторами доменных имен такие регистрационные имена должны предоставляться в кодировке IDNA.
    Port (Порт) — десятичный номер порта, отделяется от hostname одним двоеточием «:», может состоять только из цифр. Схема может определять порт по-умолчанию, который будет использоваться в случае если порт не указан. Например, для схемы HTTP порт по-умолчанию — 80, что соответствует зарезервированному под неё порту 80/TCP. Тип порта, так же как и назначенный номер порта, определяется схемой.
  • Компоненты Запрос и Фрагмент полностью описаны ранее.

3. URN


Стандарт URN документирован в RFC2141.
Из п.1:
Унифицированные имена ресурсов (URN) предназначены, чтобы служить постоянными, независимыми от расположения, идентификаторами ресурсов и разработаны для упрощения отображения других пространств имен (которые совместно используют свойства URN) в URN-пространство. Таким образом, синтаксис URN обеспечивает средство закодировать символьные данные в форме, которая может быть отправлена посредством существующих протоколов, записана при помощи большинства клавиатур, и т.д.
Т. е., в отличие от URL, который ссылается на како-то место, где хранится документ, URN ссылается на сам документ, и при перемещении документа в другое место ссылка не изменится.
В силу того, что URN концептуально отличается от URL, то и система разрешения имен у него другая — DDDS, которая преобразует URN в URL, по которым можно найти ресурс/объект или что бы то ни было, на что ссылается URN.
3.1. Структура

URN имеет следующий вид:
"urn:" <NID> ":" <NSS>

  • «urn:» — обязательная, регистронезависимая часть URN
  • NID — Namespace Identifier, данная компонента определяет синтаксическую интерпретацию компоненты NSS.
    Минимальная длина — 2 символа, максимальная — 32, разрешенные символы:
    латинские буквы, цифры, "-"
    NID должен начинаться только с буквы или цифры.
    Так же, слово «urn» для NID является зарезервированным, дабы избежать неоднозначности при определении URN в целом.
    Список официально зарегистрированных NID можно посмотреть тут
  • NSS — Namespace Specific String, эта компонента служит непосредственно для передачи каких-либо данных.
    Разрешенные символы:
    латинские буквы, цифры, процентно-кодированные, "(", ")", "+", ",", "-", ".", ":", "=", "@", ";", "$", "_", "!", "*", "'"
    Зарезервированные символы:
    "%", "/", "?", "#"
    Запрещенные символы должны быть процентно-кодированы. Если указанный символ встретится в явном виде, его позиция будет считаться концом URN:
    октеты 0-32 (0-20 hex), "\", """, "&", "<", ">", "[", "]", "^", "`", "{", "|", "}", "~", октеты 127-255 (7F-FF hex)
Самоидентифицирующийся URN
Такие URN содержат в NID название хэш-функции, а в NSS значение хэша, вычисленного для идентифицируемого объекта. Такие ссылки используются в magnet-ссылках и заголовках p2p-сети Gnutela2.
Например, URN из magnet-ссылки с одного торрент-трекера:
magnet:?xt=urn:btih:c68abc1ba9b8c7c4bc373862cad1a8c01d69e53d...

С теорией все, во второй части рассмотрим, что можно и что нужно делать с URI, если мы их обрабатываем, а именно — нормализация, разбор и т.д.

За сим откланяюсь, спасибо что читали, надеюсь не было скучно, удачи!

URL — Википедия

Единый указатель ресурса (от англ. Uniform Resource Locator — унифицированный указатель ресурса, сокр.  URL [ˌjuː ɑːr ˈel]) — система унифицированных адресов электронных ресурсов, или единообразный определитель местонахождения ресурса (файла)[1].

Используется как стандарт записи ссылок на объекты в Интернет (Гипертекстовые ссылки во «всемирной паутине» www).

История

URL был изобретён Тимом Бернерсом-Ли в 1990 году в стенах Европейского совета по ядерным исследованиям (фр. Conseil Européen pour la Recherche Nucléaire, CERN) в Женеве, Швейцария. URL стал фундаментальной инновацией в Интернете. Изначально URL предназначался для обозначения мест расположения ресурсов (чаще всего файлов) во Всемирной паутине. Сейчас URL применяется для обозначения адресов почти всех ресурсов Интернета. Стандарт URL закреплён в документе RFC 3986. Сейчас URL позиционируется как часть более общей системы идентификации ресурсов URI, сам термин URL постепенно уступает место более широкому термину URI. Стандарт URL регулируется организацией IETF и её подразделениями.

В 2009 году Тим Бернерс-Ли высказал мнение об избыточности двойного слеша // в начале URL, после указания сетевого протокола[2].

Структура URL

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

<схема>:[//[<логин>[:<пароль>]@]<хост>[:<порт>]][/<URL‐путь>][?<параметры>][#<якорь>]

В этой записи:

схема 
схема обращения к ресурсу; в большинстве случаев имеется в виду сетевой протокол
логин 
имя пользователя, используемое для доступа к ресурсу
пароль 
пароль указанного пользователя
хост 
полностью прописанное доменное имя хоста в системе DNS или IP-адрес хоста в форме четырёх групп десятичных чисел, разделённых точками; числа — целые в интервале от 0 до 255.
порт 
порт хоста для подключения
URL-путь 
уточняющая информация о месте нахождения ресурса; зависит от протокола.
параметры 
строка запроса с передаваемыми на сервер (методом GET) параметрами. Начинается с символа ?, разделитель параметров — знак &. Пример: ?параметр_1=значение_1&параметр_2=значение_2&параметр3=значение_3
якорь 
идентификатор «якоря» (англ.)русск. с предшествующим символом #. Якорем может быть указан заголовок внутри документа или атрибут id (англ.)русск. элемента. По такой ссылке браузер откроет страницу и переместит окно к указанному элементу. Например, ссылка на этот раздел статьи: https://ru.wikipedia.org/URL#Структура_URL.

Схемы (протоколы) URL

Общепринятые схемы (протоколы) URL включают:

  • ftp — Протокол передачи файлов FTP
  • http — Протокол передачи гипертекста HTTP
  • rtmp — Real Time Messaging Protocol проприетарный протокол потоковой передачи данных, в основном используется для передачи потокового видео и аудиопотоков с веб-камер через интернет.
  • rtsp — Потоковый протокол реального времени.
  • https — Специальная реализация протокола HTTP, использующая шифрование (как правило, SSL или TLS)
  • gopher — Протокол Gopher
  • mailto — Адрес электронной почты
  • news — Новости Usenet
  • nntp — Новости Usenet через протокол NNTP
  • irc — Протокол IRC
  • smb — Протокол SMB/CIFS
  • prospero — Служба каталогов Prospero Directory Service
  • telnet — Ссылка на интерактивную сессию Telnet
  • wais — База данных системы WAIS
  • xmpp — Протокол XMPP (часть Jabber)
  • file — Имя локального файла
  • data — Непосредственные данные (Data: URL)
  • tel — звонок по указанному телефону

Экзотические схемы URL:

  • afs — Глобальное имя файла в файловой системе Andrew File System
  • cid — Идентификатор содержимого для частей MIME
  • mid — Идентификатор сообщений для электронной почты
  • mailserver — Доступ к данным с почтовых серверов
  • nfs — Имя файла в сетевой файловой системе NFS
  • tn3270 — Эмуляция интерактивной сессии Telnet 3270
  • z39.50 — Доступ к службам ANSI Z39.50
  • skype — Протокол Skype
  • smsto — Открытие редактора SMS в некоторых мобильных телефонах
  • ed2k — Файлообменная сеть eDonkey, построенная по принципу P2P
  • market — Android Маркет
  • steam — протокол Steam
  • bitcoin — Криптовалюта Биткойн
  • ob — OpenBazaar
  • tg — Telegram

Схемы URL в браузерах:

Кодирование URL

Стандарт URL использует набор символов US-ASCII. Это имеет серьёзный недостаток, поскольку разрешается использовать лишь латинские буквы, цифры и несколько lзнаков пунктуации. Все другие символы необходимо перекодировать. Например, перекодироваться должны буквы кириллицы, буквы с диакритическими знаками, лигатуры, иероглифы. Перекодирующая кодировка описана в стандарте RFC 3986 и называется URL-encoding, URLencoded или percent‐encoding.

Пример кодирования можно видеть в русскоязычной Википедии, использующей в URL русский язык. Например, строка вида:

https://ru.wikipedia.org/Путин

кодируется как:

https://ru.wikipedia.org/%D0%94%D0%B6%D0%B8%D0%B3%D1%83%D1%80%D0%B4%D0%B0

Реализация

Преобразование происходит в два этапа: сначала каждый символ кириллицы кодируется в UTF-8 в последовательность из двух байтов, а затем каждый байт этой последовательности записывается в шестнадцатеричном представлении с предшествующим знаком процента (%):

Д → D0 и 94 → %D0%94
ж → D0 и B6 → %D0%B6
и → D0 и B8 → %D0%B8
г → D0 и B3 → %D0%B3, и т. д.

Все другие символы в URI кодируются.

Зарезервированные символы кодируются в таком соответствии:

!»#[5]$%&[5]*+,[5]:[5];[5]<=[5]>?[5][]^`{|}<пробел>
%21%22%23%24%25%26%27%2A%2B%2C%3A%3B%3C%3D%3E%3F%5B%5D%5E%60%7B%7C%7D%20[6]

Кодирование параметров в Internet Explorer и старом Firefox происходит несколько иначе[7].

В некоторых случаях URL формируется с использованием кодирования Base58[8].

Стандарт IRI

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

Это всё входит в противоречие с принципом интернационализма, провозглашаемого всеми ведущими организациями Интернета, включая W3C и ISOC. Эту проблему призван решить стандарт IRI (англ. Internationalized Resource Identifier) — международных идентификаторов ресурсов, в которых можно было бы без проблем использовать символы Юникода, и которые поэтому не ущемляли бы права других языков. Хотя заранее сложно сказать, смогут ли когда‐либо идентификаторы IRI заменить столь широко используемые URL (и URI в целом).

Ограничение длины

Формально, длина URL не ограничена, но браузеры имеют ограничения по длине URL. Не рекомендуется использовать URL длиной более 2048 символов, так как Microsoft Internet Explorer имеет именно такое ограничение[9].

Инициатива PURL

Ещё один кардинальный недостаток URL состоит в отсутствии гибкости. Ресурсы во Всемирной паутине и Интернете перемещаются, а ссылки в виде URL остаются, указывая на уже отсутствующие ресурсы. Это особенно болезненно для электронных библиотек, каталогов и энциклопедий. Для решения этой проблемы были предложены постоянные локаторы PURL (англ. Persistent Uniform Resource Locator). В сущности это те же URL, но они указывают не на конкретное место расположения ресурса, а на запись в базе данных PURL, где, в свою очередь, записан уже конкретный URL‐адрес ресурса. При обращении к PURL сервер находит нужную запись в этой базе данных и перенаправляет запрос уже на конкретное местоположение ресурса. Если адрес ресурса меняется, то нет нужды исправлять все бесчисленные ссылки на него — достаточно лишь изменить запись в БД. В настоящий момент эта идея не стандартизирована и не имеет широкого распространения.

См. также

Примечания

Ссылки

SIP URI и URL. Часть 1 (URI, URL и URN) / Habr

В предыдущих двух статьях мы рассмотрели основы взаимодействия по протоколу SIP.

  1. Взаимодействие клиентов SIP. Часть 1 (Простое взаимодействие)
  2. Взаимодействие клиентов SIP. Часть 2 (Взаимодействие с использованием Proxy-сервера)

Далее я предлагаю разобраться с такой важной составляющей SIP, как SIP URI. Мы сталкивались с ними раньше, когда говорили о полях From, To и других, однако не уделяли им должного внимания.

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

URI

Викепедия говорит следующее: URI (англ. Uniform Resource Identifier) — унифицированный (единообразный) идентификатор ресурса. На английский манер произносится как [ю-ар-ай], по-русски чаще говорят [ури]. URI — это последовательность символов, идентифицирующая абстрактный или физический ресурс. Ранее назывался Universal Resource Identifier — универсальный идентификатор ресурса.

При этом URI может указывать как местоположение ресурса (URL), так и его имя (URN). А может содержать и то и другое. То есть URL и URN — это частные случаи URI.

URI строится по определенным правилам и состоит из обязательных схемы и иерархической части, а также опциональных запроса (ему предшествет знак «?») и фрагмента (ему предшествует знак «#»). Иерархическая часть в свою очередь состоит из необязательного Authority (думаю, перевод только усложнит понимание) и обязательного пути. Authority включает в себя Userinfo (логин и пароль), хост и порт. Кроме того, путь может содержать так называемые параметры. Параметры используются не часто, но нам повезло — в SIP URI они присутствуют. На схеме это выглядит вот так:

Выглядит довольно запутанно, поэтому приведу пример:

URL

URL (Uniform Resource Locator) указывает путь (локацию) объекта и метод получения доступа к нему. Например, en.wikipedia.org/wiki/Main_Page указывает на главную страницу английской Википедии и в качестве метода доступа предлагает использовать протокол http.

URL описывается в RFC 1738. В этом RFC указаны описаны различные схемы для протоколов ftp, http, nntp и т.д. Послкольку URL — это частный случай URI, схема в общем случае выглядит точно так же, однако для разных протоколов актуальны те или иные ее части. Например, для протокола telnet, схема URL выглядит следующим образом:

Интересный факт: Тим Бернерс-Ли, основоположник URL в последствии сожалел, что разделил точкой доменные имена в рамках URL. URL мог бы выглядеть вот так:

URN

URN не используется в рамках SIP, однако без него рассказ был бы неполным.

URN (Uniform Resource Name) является уникальным именем объекта. URN включает в себя название пространства имен и идентификатора в этом пространстве. Типичный пример URN — это ISDN-Имя книги. URN состоит из NID (namespace identifier или идентификатор пространства имен) и NSS (namespace-specific string или уникального для данного пространства имен имени). Схематично это выглядит следующим образом:

Чтобы стало совсем понятно, приведу следующий пример. Допустим, мы хотим описать некого Ивана.

URN в данном случае будет выглядеть следующим образом: паспорт РФ: Иванов Иван Иванович, паспорт серия 1234 номер 123456. Где «паспорт РФ» — это название идентификатора пространства имен, а «Иванов Иван Иванович, паспорт серия 1234 номер 123456» — это уникальное имя в этом пространстве.

С помощью этого URN мы одназначно идентифицируем Ивана, но не сможем определить его местоположение. Здесь нам поможет URL. Выглядеть это может примерно так: машина: город N/улица M/квартира L. Где «машина» — это метод получения доступа, а «город N…» — путь.

Подведем итог. URN отвечает идентифицирует ресурс по имени и отвечает на вопрос «Что?». URL — указывает путь и метод доступа к ресурсу и отвечает на вопросы «Где?» и «Как?». При этом URN и URL — это частные случаи URI.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *