Что это uri: URI, URL, URN. Что это, чем отличаются | Дропшиппинг

Содержание

URI, URL, URN. Что это, чем отличаются

Сегодня обсудим еще три определения – это URI, URL, URN, что каждое из них обозначает и чем они отличаются друг от друга.

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

Ресурсы на сервере

URI

Итак, давайте начнем с первого термина URI и дадим ему такое определение:

URI (Uniform Resource Identifier) – это строка символов, которая используется для идентификации какого-либо ресурса по его адресу или по его имени, либо по тому и тому вместе.

Чтобы стало понятнее проведем аналогию с реальным миром на примере какого-нибудь человека. У человека есть имя, например Боб. Также у человека есть адрес проживания, например, пр. Победы 152. Предположим, нам нужно найти человека. Мы можем это сделать, начав поиск только по имени, или только по адресу, или по имени и адресу вместе.

URI

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

URL

Следующий термин – это URL. Дадим такое определение:

URL (Uniform Resource Locator) – это строка символов, которая используется для идентификации какого-либо ресурса, но только по его адресу, по его местоположению.

URL

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

URN

И последний термин – это URN. Дадим такое определение:

URN (Uniform Resource Name)

– это строка символов, которая используется для идентификации какого-либо ресурса, но только по его имени.

URN

В нашем примере это выглядит так. Мы знаем этого человека, знаем, что его зовут Боб. Но мы не знаем, где он живет. Нам придется искать его только по имени.

Важно запомнить такой момент. Все эти три термина находятся в такой условной зависимости (или иерархии), как на картинке ниже. Потому что URI может использовать и адрес, и имя при идентификации ресурса. В то время как URL и URN только адрес и только имя соответственно.

Каждый URL является URI. Каждый URN является URI. Но не каждый URI, к примеру, является URL (он может быть URN).

Теперь давайте более подробно разберем каждое из этих понятий.

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

Любой URL состоит из нескольких компонентов. Протокол и хост являются обязательными, все остальные — нет.

Подопытный URL выше можно прочитать как: используя протокол https обратиться к домену www.mysite.com по стандартному порту 80, в каталоге найти товар желтого цвета с идентификатором 15, в браузере пользователя сразу же переместиться в область где указана цена.

URN служит для обозначения уникального имени ресурса, неважно, где этот ресурс располагается в данный момент времени или вообще. Такая природа URN (независимость от адреса) позволяет ресурсам перемещаться с одного места на другое. URN позволяет получить доступ к ресурсу по различным сетевым протоколам, обращаясь к одному и тому же имени.

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

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

Выводы

Подводя итог можно сказать, что если мы говорим про сеть Интернет, то чаще всего используем термин URL, так как находим определенный ресурс в сети именно по его адресу на каком-то сервере. Также часто можно встретить аббревиатуру URI, подразумевающую именно URL. Хотя по факту это не совсем так, потому что URL является часть URI. В то же время в контексте веба URN практически не используется.

Что такое URI, URL, URN и чем они различаются

Пост из серии «Ликбез». Всегда хотел это понять, но значимость его была настолько мала, что всегда находился повод этого не делать.

А вы задавались вопросом:

URL — что это?

Всегда с таким сталкиваюсь, но до сих пор не желал понять в чем различие между терминами URI, URL, URN.

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

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

Расшифровка аббревиатур

URL — Uniform Resource Locator (унифицированный определитель местонахождения ресурса)

URN — Unifrorm Resource Name (унифицированное

имя ресурса)

URI — Uniform Resource Identifier (унифицированный идентификатор ресурса)

Внимание! Далее в мелочах кроется истина, и пока ничего не понятно, — какая-то каша, но, едем дальше.

В чем различия

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

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

URI: Это лишь обобщенное понятие (множество) идентификации ресурса, включающее в нашем случае как URL, так и URN, как по отдельности, так и совместно. Т.е. мы можем считать, что: URI = URL или URI = URN или URI = URL + URN

Подведем итоги

URI — это абстракция концепции идентификации,
а URL и URN — это конкретные реализации — полного адреса ресурса и уникального контекстного имени соответственно.

P.S.

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

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

Привет хабр!

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

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

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

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

http://example.com
www.example.com
//www.example.com
mailto:[email protected]

Если вы не знаете однозначного ответа или вам просто интересно

~~и если вы не боитесь огромного количества трехбуквенных аббревиатур~~

— милости прошу под кат.

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

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

ОГЛАВЛЕНИЕ

URI
1.1. Синтаксис
1.2. Компоненты URI
URL
2.1. Структура
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 идентифицирующий саму машину откуда производится доступ

В современном интернете, чаще всего используется две разновидности

URI

—

URL

URN

Основное различие между ними — в задачах:

URL — Uniform Resource Locator, помогает найти какой либо ресурс
URN — Uniform 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, эта компонента служит непосредственно для передачи каких-либо данных.
Разрешенные символы:
```
латинские буквы, цифры, процентно-кодированные, "(", ")", "+", ",", "-", ".", "`", "{", "|", "}", "~", октеты 127-255 (7F-FF hex)
```

Самоидентифицирующийся URN

Такие URN содержат в NID название хэш-функции, а в NSS значение хэша, вычисленного для идентифицируемого объекта. Такие ссылки используются в magnet-ссылках и заголовках p2p-сети Gnutela2.

Например, URN из magnet-ссылки с одного торрент-трекера:

magnet:?xt=urn:btih:c68abc1ba9b8c7c4bc373862cad1a8c01d69e53d...

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

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

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

Привет хабр!

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

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

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

http://example.com
www.example.com
//www.example.com
mailto:[email protected]

Если вы не знаете однозначного ответа или вам просто интересно

~~и если вы не боитесь огромного количества трехбуквенных аббревиатур~~

— милости прошу под кат.

ОГЛАВЛЕНИЕ

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

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

1. URI
Унифицированный Идентификатор Ресурса

, в простонародье —

URI

Самое свежее описание того, чем же все-таки являются эти пресловутые URI датируется январем аж 2005-го, а именно

RFC3986

, написанный самим Тимом Бёнесом-Ли, родоначальника всеми нами любимого

тырнета

Резюмируя п.1.1 можно сформулировать определение:

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

В современном интернете, чаще всего используется две разновидности

URI

—

URL

URN

Основное различие между ними — в задачах:

URL — Uniform Resource Locator, помогает найти какой либо ресурс
URN — Uniform Resource Name, помогает этот ресурс идентифицировать

Упрощая:

URL

— отвечает на вопрос: «Где и как найти что-то?»,

URN

— отвечает на вопрос: «Как это что-то идентифицировать».

Парочка интересностей про URI

RFC3305

, уместными были оба варианта именования, что, порой вносило путаницу.

либо 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.

<scheme>:<часть свойственная этой схеме>

2.1. Структура

Графически ее можно выразить в следующем виде:

Относительная ссылка использует иерархический синтаксис, чтобы выразить ссылку 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 обеспечивает средство закодировать символьные данные в форме, которая может быть отправлена посредством существующих протоколов, записана при помощи большинства клавиатур, и т.д.

В силу того, что URN концептуально отличается от URL, то и система разрешения имен у него другая —

DDDS

, которая преобразует URN в URL, по которым можно найти ресурс/объект или что бы то ни было, на что ссылается URN.

3.1. Структура

URN имеет следующий вид:

"urn:" <NID> ":" <NSS>

«urn:» — обязательная, регистронезависимая часть URN
NID — Namespace Identifier, данная компонента определяет синтаксическую интерпретацию компоненты NSS.
Минимальная длина — 2 символа, максимальная — 32, разрешенные символы:
```
латинские буквы, цифры, "-"
```
NID должен начинаться только с буквы или цифры.», «`», «{«, «|», «}», «~», октеты 127-255 (7F-FF hex)

Самоидентифицирующийся URN

Например, URN из magnet-ссылки с одного торрент-трекера:

magnet:?xt=urn:btih:c68abc1ba9b8c7c4bc373862cad1a8c01d69e53d...

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

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

Привет хабр!

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

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

http://example.com
www.example.com
//www.example.com
mailto:[email protected]

Если вы не знаете однозначного ответа или вам просто интересно

~~и если вы не боитесь огромного количества трехбуквенных аббревиатур~~

— милости прошу под кат.

ОГЛАВЛЕНИЕ

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

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

1. URI
Унифицированный Идентификатор Ресурса

, в простонародье —

URI

Самое свежее описание того, чем же все-таки являются эти пресловутые URI датируется январем аж 2005-го, а именно

RFC3986

, написанный самим Тимом Бёнесом-Ли, родоначальника всеми нами любимого

тырнета

Резюмируя п.1.1 можно сформулировать определение:

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

В современном интернете, чаще всего используется две разновидности

URI

—

URL

URN

Основное различие между ними — в задачах:

URL — Uniform Resource Locator, помогает найти какой либо ресурс
URN — Uniform Resource Name, помогает этот ресурс идентифицировать

Упрощая:

URL

— отвечает на вопрос: «Где и как найти что-то?»,

URN

— отвечает на вопрос: «Как это что-то идентифицировать».

Парочка интересностей про URI

RFC3305

, уместными были оба варианта именования, что, порой вносило путаницу.

либо 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.

<scheme>:<часть свойственная этой схеме>

2.1. Структура

Графически ее можно выразить в следующем виде:

Относительная ссылка использует иерархический синтаксис, чтобы выразить ссылку 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 обеспечивает средство закодировать символьные данные в форме, которая может быть отправлена посредством существующих протоколов, записана при помощи большинства клавиатур, и т.д.

В силу того, что URN концептуально отличается от URL, то и система разрешения имен у него другая —

DDDS

, которая преобразует URN в URL, по которым можно найти ресурс/объект или что бы то ни было, на что ссылается URN.

3.1. Структура

URN имеет следующий вид:

"urn:" <NID> ":" <NSS>

«urn:» — обязательная, регистронезависимая часть URN
NID — Namespace Identifier, данная компонента определяет синтаксическую интерпретацию компоненты NSS.
Минимальная длина — 2 символа, максимальная — 32, разрешенные символы:
```
латинские буквы, цифры, "-"
```
NID должен начинаться только с буквы или цифры.», «`», «{«, «|», «}», «~», октеты 127-255 (7F-FF hex)

Самоидентифицирующийся URN

Например, URN из magnet-ссылки с одного торрент-трекера:

magnet:?xt=urn:btih:c68abc1ba9b8c7c4bc373862cad1a8c01d69e53d...

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

В чем разница между URI, URL и URN?

Содержит информацию о том, как извлечь ресурс из его местоположения. Например:

http://example.com/mypage.html
ftp://example.com/download.zip
mailto:[email protected]
file:///home/user/file.txt
http://example.com/resource?foo=bar#fragment
/other/link.html (Относительный URL, полезный только в контексте другого URL)

URLs всегда начинается с протокола ( http ) и обычно содержит такую информацию, как имя сетевого хоста ( example.com ) и часто путь к документу ( /foo/mypage.html ). URLs могут иметь параметры запроса и идентификаторы фрагментов.

Определяет ресурс по имени. Он всегда начинается с префикса urn: , например:

urn:isbn:0451450523 для идентификации книги по ее номеру ISBN.
urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66 глобальный уникальный идентификатор
urn:publishing:book — Пространство имен XML, идентифицирующее документ как тип книги.

URNs может идентифицировать идеи и концепции. Они не ограничиваются документами, удостоверяющими личность. Когда URN действительно представляет документ, он может быть переведен в URL с помощью «resolver». Затем документ можно загрузить с URL.

URIs включает в себя как URLs, URNs, так и другие способы указания ресурса.

Примером URI, который не является ни URL, ни URN, будут данные URI , такие как data:,Hello%20World . Это не URL или URN, потому что URI содержит данные. Он не называет его и не говорит вам, как найти его по сети.

Существуют также единообразные ссылки на ресурсы (URCs), которые указывают на метаданные о документе, а не на сам документ. Примером URC может служить индикатор для просмотра исходного кода веб-страницы: view-source:http://example.com/ . URC-это другой тип URI, который не является ни URL, ни URN.

Я слышал, что мне больше не следует говорить URL, почему?

В спецификации w3 для HTML говорится, что href тега привязки может содержать URI, а не только URL. Вы должны быть в состоянии ввести URN, например <a href="urn:isbn:0451450523"> . Затем ваш браузер разрешит этот URN на URL и загрузит книгу для вас.

Действительно ли какие-либо браузеры знают, как извлекать документы по URN?

Насколько я знаю, нет, но современный веб-браузер действительно реализует схему data URI.

Может ли a URI быть одновременно a URL и a URN?

Хороший вопрос. Я видел много мест в Интернете, где говорится, что это правда. Я не смог найти ни одного примера чего-то, что одновременно является URL и URN. Я не понимаю, как это возможно, потому что URN начинается с urn: , который не является допустимым сетевым протоколом.

Имеет ли разница между URL и URI какое-либо отношение к тому, является ли она относительной или абсолютной?

Нет. Как относительные, так и абсолютные URLs равны URLs (и URIs.)

Имеет ли разница между URL и URI какое-либо отношение к тому, есть ли у него параметры запроса?

Нет. Как URLs с параметрами запроса, так и без них-это URLs (и URIs.)

Имеет ли разница между URL и URI какое-либо отношение к тому, имеет ли он идентификатор фрагмента?

Нет. И URLs с идентификаторами фрагментов, и без них-это URLs (и URIs.)

Является ли

tel: URI URL или URN?

Например tel:1-800-555-5555 . Он не начинается с urn: и имеет протокол для доступа к ресурсу по сети. Это должно быть URL.

Но разве w3C теперь не говорит, что URLs и URIs-это одно и то же?

Да. W3C понял, что в этом есть тонна путаницы. Они выпустили разъясняющий документ URI, в котором говорится, что теперь OK использовать URL и URI взаимозаменяемо. Больше не полезно строго сегментировать URIs на различные типы, такие как URL, URN и URC.

URI — это… Что такое URI?

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

Основы

URI — это символьная строка, позволяющая идентифицировать какой-либо ресурс: документ, изображение, файл, службу, ящик электронной почты и т. д. Прежде всего, речь идёт, конечно, о ресурсах сети Интернет и Всемирной паутины. URI предоставляет простой и расширяемый способ идентификации ресурсов. Расширяемость URI означает, что уже существуют несколько схем идентификации внутри URI, и ещё больше будет создано в будущем.
Подробнее см. «Структура URI» ниже.

Связь между URI, URL и URN

URI является либо URL, либо URN, либо одновременно обоими.

URL — это URI, который, помимо идентификации ресурса, предоставляет ещё и информацию о местонахождении этого ресурса. А URN — это URI, который только идентифицирует ресурс в определённом пространстве имён (и, соответственно, в определённом контексте), но не указывает его местонахождения. Например, URN urn:ISBN:0-395-36341-1 — это URI, который указывает на ресурс (книгу) 0-395-36341-1 в пространстве имён ISBN, но, в отличие от URL, URN не указывает на местонахождение этого ресурса: в нём не сказано, в каком магазине её можно купить, или на каком сайте скачать. Впрочем, в последнее время появилась тенденция говорить просто URI о любой строке-идентификаторе, без дальнейших уточнений. Так что, возможно, термины URL и URN скоро уйдут в прошлое.

Поскольку URI не всегда указывает на то, как получить ресурс, в отличие от URL, а только идентифицирует его, это даёт возможность описывать с помощью RDF (Resource Description Framework) ресурсы, которые не могут быть получены через Интернет (например, личность, автомобиль, город и проч.).

История

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

Новая версия URI была определена в 1998 году в RFC 2396, тогда же слово Universal в названии было заменено на Uniform. В декабре 1999 года RFC 2732 ввёл в спецификацию URI небольшие изменения, обеспечив совместимость с IPv6. В августе 2002 года RFC 3305 анонсировал устаревание термина URL и приоритет URI. Текущая структура и синтаксис URI регулируется стандартом RFC 3986, вышедшим в январе 2005 года. Многие новейшие технологии семантической паутины (например, RDF) базируются на стандарте URI. Сейчас ведущая роль в развитии URI принадлежит Консорциуму Всемирной паутины.

Недостатки

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

http://ru.wikipedia.org/wiki/Кириллица

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

http://ru.wikipedia.org/wiki/%D0%9A%D0%B8%D1%80%D0%B8%D0%BB%D0%BB%D0%B8%D1%86%D0%B0

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

Ещё одной интересной вариацией URI является расширяемый идентификатор ресурса XRI (англ. Extensible Resource Identifier), разработанный организацией OASIS. Этот формат стремится создавать идентификаторы, которые были бы совершенно независимы от контекста, то есть не зависели бы ни от протокола, ни от домена, ни от пути, ни от приложения, ни от платформы — были бы совершенно независимыми.

Также и сам создатель URI, Тим Бернерс-Ли, говорил, что система доменных имён, лежащая в основе URL, — плохое решение, навязывающее ресурсам иерархическую архитектуру, мало подходящую для гипертекстового веба.

Структура URI

URI = [ схема ":" ] иер-часть [ "?" запрос ] [ "#" фрагмент ]

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

схема: схема обращения к ресурсу (часто указывает на сетевой протокол), например http, ftp, file, ldap, mailto, urn

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

запрос: этот необязательный компонент URI описан выше.

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

Цитата из RFC 3986: The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations.

Часть идентификатора URI без схемы обращения к ресурсу часто называется «ссылкой URI» (англ. URI reference). Прецеденты применения ссылок URI имеются в HTML, XHTML, XML и XSLT. Процесс превращения ссылки URI в абсолютную форму URI называют «разрешением URI» (англ. URI resolution).

Процесс разработки новых схем описан в документе RFC 2718. Новые схемы должны регистрироваться в организации IANA (англ. Internet Assigned Numbers Authority), процедура регистрации зафиксирована в RFC 2717. Оба указанных запроса комментариев (RFC) сейчас находятся в процессе переработки.

Разбор структуры URI

Для так называемого «па́рсинга» URI (англ. parsing), то есть для разложения URI на составные части и их последующей идентификации удобнее всего использовать систему регулярных выражений, доступную ныне почти во всех современных языках программирования. Для разбора URI рекомендуется^[1] использовать следующий шаблон:

^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
 12            3  4          5       6  7        8 9

Этот шаблон включает в себя 9 обозначенных выше цифрами групп (подробнее о шаблонах и группах см. Регулярные выражения), которые наиболее полно и точно разбирают типичную структуру URI, где:

группа 2 — схема,
группа 4 — источник,
группа 5 — путь,
группа 7 — запрос,
группа 9 — фрагмент.

Таким образом, если при помощи данного шаблона разобрать, например, такой типичный идентификатор URI:

http://www.ics.uci.edu/pub/ietf/uri/#Related

то 9 вышеуказанных групп шаблона дадут следующие результаты соответственно:

http:
http
//www.ics.uci.edu
www.ics.uci.edu
/pub/ietf/uri/
нет результата
нет результата
#Related
Related

Примеры URI

Абсолютные URI

http://ru.wikipedia.org/wiki/URI
ftp://ftp.is.co.za/rfc/rfc1808.txt
file://C:\UserName.HostName\Projects\Wikipedia_Articles\URI.xml
ldap://[2001:db8::7]/c=GB?objectClass?one
mailto:[email protected]
sip:[email protected]
news:comp.infosystems.www.servers.unix
data:text/plain;charset=iso-8859-7,%be%fe%be
tel:+1-816-555-1212
telnet://192.0.2.16:80/
urn:oasis:names:specification:docbook:dtd:xml:4.1.2

Ссылки URI

/relative/URI/with/absolute/path/to/resource.txt

relative/path/to/resource.txt

../../../resource.txt

resource.txt

/resource.txt#frag01

#frag01

[пустая строка] — эквивалентно разбору идентификатора парсером с результатом [пустая строка], то есть ссылка идет на объект по умолчанию в схеме по умолчанию^{[источник не указан 535 дней]}

См. также

Ссылки

Примечания

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

Термины «URI» и «URL» часто используются как синонимы, но это не совсем одно и то же.

A UR I — это идентификатор определенного ресурса. Как страница, или книга, или документ.
A UR L — это специальный тип идентификатора , который также сообщает вам, как получить к нему доступ , например HTTPs , FTP и т. Д., Например https://www.google.com.
Если протокол ( https , ftp и т. Д.) либо присутствует, либо подразумевается для домена, , вы должны называть его URL-адресом — даже если это также URI.

Все URL-адреса являются URI, но не все URI являются URL-адресами.

Домены не являются ни URI, ни URL-адресами, потому что все URL-адреса также являются URI-адресами.

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

Вот и все.

TL; DR: при общении обычно лучше быть более конкретным, поэтому «URL» лучше, чем «URI», когда речь идет о веб-адресах.

Это все, что вам, вероятно, нужно знать, но если вы хотите увидеть, как делается колбаса (предупреждаю, это мерзко), не стесняйтесь читать!

Более глубокое объяснение (давайте перейдем к техническим вопросам)

Это одна из самых частых дискуссий о Nerd Fight в истории технологий, и это о многом говорит.

Одним из препятствий на пути к сути является то, что соответствующие RFC чрезвычайно сложны, запутаны и даже противоречивы. Например, RFC 3986 говорит, что URI может быть именем, локатором или и тем, и другим…

Мое выделение.

URI может быть дополнительно классифицирован как локатор, имя или и то, и другое . В термин «унифицированный указатель ресурса» (URL) относится к подмножеству URI которые, помимо идентификации ресурса, предоставляют средства поиск ресурса путем описания его основного механизма доступа (например, его сетевое «местоположение»).
RFC 3986, раздел 1.1.3

Но чуть ниже тот же RFC говорит…

Мое выделение.

Сам URI предоставляет только удостоверение личности; доступ к ресурсу не гарантируется и не подразумевается наличием URI .
RFC 3986, раздел 1.2.2

И затем, если вы еще не полностью запутались, , он также говорит…

Мое выделение.

Каждый URI начинается с имени схемы , как определено в разделе 3.1, что относится к спецификации для присвоения идентификаторов внутри этого схема.
RFC 3986, раздел 1.1.1

Далее приведены примеры:

Обратите внимание, что во всех их примерах есть схемы.

ftp://ftp.is.co.za/rfc/rfc1808.txt
http://www.ietf.org/rfc/rfc2396.txt
ldap: // [2001: db8 :: 7] / c = GB? objectClass? one
mailto: [email protected]
новости: comp.infosystems.www.servers.unix
тел: + 1-816-555-1212
телнет: //192.0.2.16: 80 /
урна: оазис: имена: спецификация: docbook: dtd: xml: 4.1.2

Подождите… что?

Эти три противоречия являются источником всей этой долгой дискуссии.

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

Неудивительно, что все запутались!

Причина, по которой Интернет борется по этому поводу более десяти лет, заключается в том, что RFC плохо написан.

Как извлечь из всего этого практические правила

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

Хорошо, так что, учитывая тот факт, что RFC лишь усугубляет путаницу, а не устраняет ее, что — если вообще — мы можем от них использовать?

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

Все бабочки летают, но не все, что летает, — это бабочки.

Унифицированный идентификатор ресурса (URI) предоставляет простые и расширяемые средства для идентификации ресурса (прямо из RFC 3986). Это просто идентификатор; не зацикливайтесь на этом.
Для большинства споров по этому поводу URI — это надмножество, поэтому вопрос только в том, является ли данный URI формально URL-адресом или нет . Все URL-адреса являются URI, но не все URI являются URL-адресами. Как правило, если вы видите http (s): //, это URL.
URI технически требуют схемы (см. Выше), но RFC также говорит, что они могут быть именем, локатором или и тем, и другим, так что YOLO! Мой совет всем, кто говорит, что для URI требуется или не требуется схема, — показать им эту статью, потому что это единственное, что мне известно о противоречиях в RFC.
Фрагменты, такие как file.htm , на самом деле не являются URN , потому что URN должны использовать специальную нотацию с urn: в начале.
Малоизвестный раздел RFC 3986 на самом деле говорит напрямую о религиозной части аргумента, и, кажется, говорит, что мы должны говорить URI вместо URL .

RFC 3986 написан в 2005 году, поэтому, по-видимому, они говорят, что после этой точки предпочтительным термином является URI.

Будущие спецификации и сопутствующая документация должны используйте общий термин «URI», а не более ограничительные термины. «URL» и «URN»
RFC 3986, раздел 1.1.3

Итак, это поддержка наименования «URI», но, на мой взгляд, это еще больше поддержки для тех, кто говорит: «хватит искать ответы в RFC 15-летней давности ».

В этом смысле это как еще один широко читаемый текст.

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

Сводка

Какой бардак. Вот TL; DR…

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

Я приветствовал бы новую версию RFC, которая упрощает и разъясняет различия с современными примерами.

Эти RFC были написаны очень давно, , и они написаны с академической слабостью, поскольку не оптимизированы для чтения.

Лучшее, что я могу вам сказать об этих дебатах, — это не переоценивать их. Я ни разу за 20 лет не встречал ситуации, когда путаница между URI и URL действительно имела значение.

Ирония заключается в том, что RFC должны устранять путаницу, а не добавлять ее.

Таким образом, хотя есть прямая поддержка того, что «URI» предпочтительнее в RFC, а «URL» кажется наиболее точным для полных адресов со схемами http (s) (потому что он наиболее конкретен), я решил отдать приоритет Принципу Четкость общения выше, чем педантичность нюансов.

Мне потребовалось много времени, чтобы добраться до этого момента.

В результате я лично использую «URL» в большинстве случаев , потому что это вряд ли вызовет путаницу , но если я слышу, что кто-то использует «URI», я часто сразу переключаюсь на его использование.

Примечания

3 мая 2019 г. — Я сделал серьезное обновление статьи, в том числе исправил некоторые ошибки, которые были в предыдущих версиях. А именно, у меня были такие фрагменты, как file.html , показанные как URN, что неверно. Эта версия статьи — лучшая версия, тем более что она полностью исследует противоречивый язык в RFC и то, как мало нам действительно следует обращать внимание на такой старый документ. Однако я определенно буду читать и следить за обновлениями.
RFC 3986 Link
Статья в Википедии о URI Link

Универсальные идентификаторы ресурсов в WWW

Универсальные идентификаторы ресурсов в WWW Этот документ определяет синтаксис используется инициативой World-Wide Web закодировать имена и адреса объектов в Интернете. В сеть считается включающей объекты доступ с помощью расширяемого номера протоколов, существующих, изобретенных для самой сети, или быть изобретенным в будущем. Инструкции по доступу для индивидуального объекта под данный протокол закодирован в формы адресной строки.Другие протоколы разрешить использование имен объектов различные формы. Чтобы абстрагироваться идея универсального объекта, Интернету нужны концепции универсального набор предметов, и универсальный набор наименований или адресов объектов.

Универсальный идентификатор ресурса (URI) является членом этого универсального набора имен в зарегистрированных пространствах имен и адреса, относящиеся к зарегистрированным протоколы или пространства имен. Униформа Указатель ресурса (URL), определенный в другом месте, это форма URI, которая выражает адрес, который отображается на доступ алгоритм с использованием сетевых протоколов.Существующие схемы URI, которые соответствуют к (все еще мутирующей) концепции Здесь перечислены URL-адреса IETF. Униформа Попытки обсуждения имени ресурса (URN) для определения пространства имен (и предположительно протоколы разрешения) для постоянных имена объектов. Эта область не адресована этим документом, в котором написано для документирования существующей практики и предоставить ориентир для Обсуждения URL и URN.

Поэтому этот документ должен быть выдается под «информационным RFC «отказ от ответственности.

Протоколы всемирной паутины обсуждается в списке рассылки www-talk-request @ info.cern.ch и группа новостей comp.infosystems.www предпочтительнее для вопросов новичков. Список рассылки [email protected] имеет обсуждение, особенно связанное с к проблеме URI. Автор может обращаться по адресу [email protected].

Этот документ доступен в гипертексте форма на http://www.w3.org/hypertext/WWW/Addressing/URL/URI_Overview.html

Статус этого меморандума

Этот документ является Интернет-черновиком. Интернет-проекты — это рабочие документы Интернет-инженерного задания Force (IETF), его области и Рабочие группы.Обратите внимание, что другие группы могут также распределять рабочие документы как Интернет-проекты.

Интернет-проекты — это рабочие документы действует максимум шесть месяцев. Интернет-проекты могут быть обновлены, заменены, или устарело другими документами на в любой момент. Это не подходит использовать интернет-черновики в качестве справочника материала или цитировать их кроме как «рабочий проект» или «работа в прогресс ».

Распространение этого документа безлимитный.

В этом разделе описывается концепция URI и не является частью спецификации.

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

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

Общая черта почти всех модели данных прошлых и предлагаемых системы — это то, что может быть отображается на понятие «объект» и какое-то имя, адрес или идентификатор этого объекта.Один поэтому можно определить набор имен пространства, в которых эти объекты могут можно сказать, что существует.

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

URI

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

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

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

URL

Для существующих протоколов доступа в Интернет, в большинстве случаев необходимо определить кодировку доступа алгоритм во что-то лаконичное достаточно, чтобы называться адресом. URI которые относятся к объектам, доступ к которым осуществляется с помощью существующие протоколы известны как «унифицированные» Указатели ресурсов »(URL) и являются перечисленные здесь как используемые в WWW, но для быть формально определенным в отдельном документ.

URN

В настоящее время существует привод, чтобы определить пространство более постоянных имен чем любые URL-адреса. Эти «Единый ресурс Имена »являются предметом обсуждения IETF. обсуждения в рабочей группе. (Видеть Соллинз и Масинтер, Функциональный Спецификации для URN, распространенные неофициально.)

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

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

Критерии проектирования

Синтаксис был разработан для

Расширяемый: Новые схемы именования могут будет добавлено позже.
Завершено: Возможно кодирование любая схема именования.
Для печати: Можно выразить любой URI, использующий 7-битные символы ASCII так что URI могут при необходимости быть прошло с помощью пера и туши.

Варианты универсального синтаксиса

Для самого синтаксиса мало выбор кроме порядка и знаков препинания элементов, и приемлемые символы и правила экранирования.

Требование расширяемости: встретится путем разрешения произвольного (но зарегистрированная) строка, которая будет использоваться как приставка. Префикс выбирается как синтаксический анализ слева направо более распространен чем справа налево. Выбор двоеточия как разделителя префикса от остальной части URI был произвольным.

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

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

Требование пригодности для печати могло были выполнены, требуя всех схем кодировать символы, не входящие в базовый набор. Это вызвало множество дискуссий какой должен быть базовый набор. Сложный случай, например, когда появляется строка ISO latin 1 в URL-адресе и в приложении с возможностью ISO Latin-1, он может обращаться в целости и сохранности.Однако для транспорт в целом, не-ASCII символы должны быть экранированы.

Решением было указать безопасный набор персонажей и общий схема экранирования, которая может быть использована для кодирования «небезопасных» символов. Этот «безопасный» набор подходит, для например, для использования в электронной почте. Это каноническая форма URI.

Выбор escape-символа для введение представлений о недопустимых персонажи также имеют тенденцию быть вопросом вкуса. Стандарт ANSI существует на языке C с использованием обратной косой черты персонаж «\».Использование этого персонажа однако в командной строке unix можно быть проблемой, как это интерпретируется многими программами оболочки и нужно самому сбежать. это также персонаж, которого нет в наличии на некоторых клавиатурах. Равные знак обычно используется в кодировке имен, имеющих пары атрибут = значение. В итоге был выбран знак процента как подходящий escape-символ.

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

Использование символов пробела опасно печатать URI или отправлено по электронной почте, а использование нескольких символов пробела очень рискованно. Это из-за частое внесение посторонних пробел при переносе строк такими системами, как почта, или просто необходимость узкой ширины столбца, и из-за взаимного преобразования различных форм белого пространства, которое происходит во время преобразования кода символа и передача текста между Приложения.Вот почему канонический форма для URI имеет все пробелы закодировано.

В этом разделе описан синтаксис для URI, используемых в WorldWide Интернет-инициатива. Общий синтаксис обеспечивает основу для новых схем для имен, которые будут разрешены, используя как пока не определены протоколы.

Синтаксис URI

Полный URI состоит из именования спецификатор схемы, за которым следует строка формат которого является функцией схема именования. Для локаторов информации в Интернете распространенный синтаксис используется для части IP-адреса.BNF-описание синтаксиса URL дается в более позднем разделе. В Компоненты следующие. Фрагмент идентификаторы и относительные URI не участвует в базовом определении URL.

Схема

В URI объекта первый element — название схемы, отделен от остальной части объекта двоеточием.

Путь

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

Зарезервированные символы

Путь в URI имеет значение определяется конкретной схемой. Обычно он используется для кодирования имя в заданном пространстве имен или алгоритм доступа к объекту. В любом случае кодировка может используйте те символы, которые разрешены Синтаксис BNF или шестнадцатеричное кодирование других персонажей.

Некоторые из зарезервированных персонажей имеют специальное использование, как определено здесь.

Знак процента

Знак процента («%», ASCII 25 шестнадцатеричный) используется как escape-символ в схема кодирования и никогда не разрешено все остальное.

Иерархические формы

Косая черта («/», шестнадцатеричный код ASCII 2F) зарезервировано для разграничения подстроки, отношение которых иерархический. Это позволяет частично формы URI. Подстроки, состоящие одинарных или двойных точек («.» или «..») также зарезервированы.

Значение косой черты между два сегмента — это то, что сегмент пути налево более значительна чем отрезок пути к верно. («Значение» в данном случае относится исключительно к близости к корень иерархической структуры и не делает никаких оценочных суждений!)

Note

Сходство с unix и другими соглашения об именах файлов операционной системы на диске следует рассматривать как чисто случайное совпадение, и не следует воспринимать как указание что URI следует интерпретировать как имена файлов.

Хэш для идентификаторов фрагментов

Хеш-символ («#», ASCII 23 шестнадцатеричный) зарезервирован как разделитель для разделения URI объекта из фрагмента идентификатор.

Строки запроса

Вопросительный знак («?», ASCII 3F hex) используется для обозначения границы между URI запрашиваемого объекта, и набор слов, используемых для выражения запрос по этому объекту. Когда это форма, объединенный URI стоит для объекта, который является результатом запрос, применяемый к исходному объект.

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

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

Другие зарезервированные символы

Звездочка («*», ASCII 2A шестнадцатеричный) и восклицательный знак («!», ASCII 21 hex) зарезервированы для использования как имеющие особая значимость в конкретных схемы.

Небезопасные символы

В канонической форме некоторые символы такие как пробелы, управляющие символы, некоторые символы, код ASCII которых используется по-разному в разных вариант национального символа 7 бит наборы, и все 8-битные символы сверх DEL (7F шестнадцатеричный) набора ISO Latin-1, не должны использоваться в незашифрованном виде. Этот это рекомендация для безотказной взаимообмен, и, как указано ниже, закодированный набор может быть расширен или уменьшенный. Когда система использует локальную адресацию схему, полезно предоставить отображение локальных адресов в URI, чтобы ссылки на объекты в рамках схемы адресации может упоминаться глобально, и, возможно, доступ через серверы шлюза.

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

Также рекомендуется, чтобы стандартная схема ниже будет использоваться во всех случаях кроме любой схемы который кодирует двоичные данные, а не в текст, и в этом случае более компактный кодирование, такое как чистый шестнадцатеричный или база 64 может быть более подходящей.Например, обычный URI метод кодирования используется для отображения Адреса WAIS, FTP, Prospero и Gopher в спецификации URI.

Обычная схема кодирования URI

Где используется локальная схема именования Запрещенные символы ASCII в URI они могут быть представлены в URL знаком процента «%» сразу после двух шестнадцатеричных цифры (0-9, A-F), дающие ISO Код Latin 1 для этого символа. Коды символов, отличные от этих разрешено синтаксисом не должно быть используется без кодирования в URI.

Пониженный или повышенный безопасный символ наборы

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

Прежде чем можно будет сравнить два URI, поэтому необходимо принести их к одному и тому же уровню кодирования.

Однако зарезервированные символы упомянутые выше имеют совершенно разные значимость при кодировании, и так НИКОГДА не могут быть закодированы и не закодированы этим способом.

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

Пример 1

URI

 http://www.w3.org/albert/bertram/marie-claude

 http://www.w3.org/albert/bertram/marie%2Dclaude

идентичны, так как% 2D кодирует символ дефиса.

Пример 2

URI

 http://www.w3.org/albert/bertram/marie-claude

 http://www.w3.org/albert/bertram%2Fmarie-claude

НЕ идентичны, как во втором если закодированная косая черта не имеет иерархическая значимость.

Пример 3

URI

 fxqn: / us / va / reston / cnri / ietf / 24 / asdf% *. Фред

 новости: 12345667123%[email protected]

недопустимы, так как все символы% подразумевают кодировки, и нет декодирование определено для «% *» или «% as» в этой рекомендации. Внутри объекта с правильным URI определен, URI другого объекта могут быть даны в сокращенной форме, где части двух URI являются такой же. Это позволяет объектам внутри группа, чтобы ссылаться друг на друга без требуя места для полного ссылка, и это, кстати, позволяет группа перемещаемых объектов без изменения каких-либо ссылок.Следует подчеркнуть, что когда ссылка передается в чем угодно кроме хорошо контролируемого контекста, всегда должна использоваться полная форма.

В приложениях World Wide Web контекстный URI — это URI документа или объект, содержащий ссылку. В этом случае частичные URI могут быть генерируется в виртуальных объектах или хранится в реальных объектах, без необходимости для кардинальных изменений, если высший части иерархической системы именования изменены. Помимо лаконичности, это придает большую надежность практические системы, предоставляя информацию прячется между компонентами системы.

Частичная форма опирается на свойство синтаксиса URI, что определенные символы («/») и определенные элементы пути («..», «.») имеют зарезервированное значение для представления иерархического пространства, и должен быть признан таковым как клиенты, так и серверы.

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

Правила использования частичного имя относительно URI контекст:

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

Примечание: завершающие косые черты

Если путь локатора контекста заканчивается косой чертой, обрабатываются частичные URI отличается от URI с тем же путь, но без косой черты в конце.Завершающая косая черта указывает на пустоту. отрезок пути.

Примечание: Gopher

Система Gopher не имеет концепция относительных URI и Сообщество сусликов в настоящее время позволяет / как символы данных в URI gopher без перехода в% 2F. Родственник формы вообще не могут быть использованы для документов, обслуживаемых серверами gopher. Если они используются, то программное обеспечение WWW предполагает, как правило, правильно, что на самом деле у них есть иерархические значение, несмотря на спецификации. Использование HTTP вместо gopher однако рекомендуется протокол.

Примеры

В контексте URI

 магия: // a / b / c // d / e / f

частичные URI будут расширяться как следует:

г: магия: // a / b / c // d / e / g
/ г: magic: // а / г
// г: магия: // г
../g: магия: // a / b / c // d / g
г: ч: г: ч

и в контексте URI

 магия: // a / b / c // d / e /

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

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

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

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

Идентификаторы фрагментов НЕ адресуются вопрос об объектах, которые разные варианты «живого» объект, ни выражения отношений между разными версиями и живой объект.

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

Отображение URI на некоторые существующие стандартные и экспериментальные протоколы изложено в определении синтаксиса BNF . Примечания к конкретным протоколам следить. Эти URI часто используются называются URL-адресами, хотя точный определение термина URL все еще в стадии обсуждения (март 1993 г.).В Охватываемые схемы:

http: Протокол передачи гипертекста (Примеры)
футов: Протокол передачи файлов
суслик: Протокол Gopher
mailto: Адрес электронной почты
новости: Новости Usenet
telnet, rlogin и tn3270: ссылку к интерактивным сессиям
Wais: Глобальные информационные серверы
файл: Доступ к локальным файлам

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

средний: Идентификаторы сообщений для электронных Почта
cid: Идентификаторы содержимого для MIME часть тела

Схемы для x.500, управление сетью база данных и whois ++ не были указан и может быть предметом дальнейшего изучения. Схемы для Просперо , и ограниченное использование NNTP не в настоящее время реализовано в автор в курсе.

Префикс «урна» зарезервирован для использовать при кодировании унифицированного ресурса Имя, когда это было разработано рабочей группой IETF.

Новые схемы можно зарегистрировать на позднее время.

HTTP

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

Детали хоста не передаются клиенту, когда URL-адрес http URL, который ссылается на сервер обсуждаемый. В этом случае строка отправлено начинается с косой черты, которая следует за деталями хоста. Однако, когда используется http-сервер в качестве шлюза (или «прокси»), тогда весь URI, будь то HTTP или какой-то другая схема, передается по HTTP командная строка. часть поиска, если есть, отправляется как часть команды HTTP, и может в этом отношении рассматриваться как часть пути.Отсутствие фрагментированной части WWW URI ( знак решетки и последующие) отправляется с просьбой. Пространства и контроль символы в URL должны быть экранированы для передачи в HTTP, как и должно другие запрещенные символы.

Примеры

Эти примеры не являются частью спецификация: они предоставляются только в качестве иллюстраций. URI страница «приветствия» на сервере условно

 http://www.my.work.com/

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

 http://www.my.uni.edu/info/matriculation/enroling.html

http://info.my.org/AboutUs/Phonebook

http://www.library.my.town.va.us/Catalogue/76523471236%2Fwen44--4.98

http://www.my.org/462F4F2D4241522A314159265358979323846

URL-адрес сервера на другом порт на 80 выглядит как

 http://www.w3.org:8000/imaginary/test

Ссылка на конкретную деталь документа может, в том числе идентификатор фрагмента, выглядит как

 http://www.myu.edu/org/admin/people#andy

, в этом случае строка «#andy» не отправляется на сервер, но сохраняется клиентом и используется, когда был получен весь объект.

Поиск в текстовой базе данных может выглядит как

 http://info.my.org/AboutUs/Index/Phonebook?dobbins

и в другой базе данных

 http://www.w3.org/RDB/EMP?*%20where%20name%%3Ddobbins

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

FTP

Префикс ftp: указывает, что Протокол FTP используется, как определено в RFC957 или любом его преемнике. Порт номер, если присутствует, дает порт FTP-сервера, если не FTP дефолт.

Имя пользователя и пароль

Синтаксис допускает включение имени пользователя и даже пароля для тех систем, которые не используют соглашение об анонимном FTP. В однако по умолчанию, если нет пользователя или пароля поставляется, будет использовать это конвенция, а именно. что имя пользователя является «анонимным», а пароль — адрес электронной почты пользователя в стиле Интернет .

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

Путь

Протокол FTP допускает последовательность команд CWD (сменить рабочий каталог) и команда TYPE перед обслуживанием такие команды, как RETR (получить) или NLIST (и т. д.), которые действительно имеют доступ файл.

Аргументы любых команд CWD являются последовательными частями сегмента URL-адрес разделен косой чертой, а последний сегмент подходит как имя файла аргумент команды RETR для поиск или аргумент каталога в NLIST.

Для некоторых файловых систем (в частности, Unix), «/» используется для обозначения иерархической структура URL соответствует к разделителю, используемому для построения иерархия имен файлов, и, таким образом, имя файла будет выглядеть так же, как URL-путь. Это НЕ означает что URL — это имя файла Unix.

Примечание. Получение последующих URL-адресов с того же хоста

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

Тип данных

Тип содержимого данных файла может только в общем случае FTP выводится из названия, обычно суффикс имени. Это не стандартизировано. Альтернативой является его передача в информации за пределами URL. А подходящий тип передачи по FTP (например, двоичный «I» или текст «A») должны в в свою очередь быть выведено из содержания данных тип. Рекомендуется, чтобы условные обозначения для суффиксов публичных архивов быть установлен, но он находится за пределами область применения этого стандарта.

URL-адрес FTP может дополнительно указывать тип передачи данных FTP, с помощью которого объект должен быть получен. Наиболее методов соответствуют FTP «Типы данных» ASCII и IMAGE для поиска документа, как указано в FTP командой TYPE . Один метод указывает каталог доступ.

Тип данных указывается суффиксом к URL-адресу. Возможные суффиксы:

; type = <код-типа>: Использовать тип FTP как дано для передачи данных.
/: Использовать команды списка каталогов FTP читать каталог

Код типа находится в определенном формате в RFC959, за исключением того, что ПРОСТРАНСТВО ЕСТЬ УДАЛЕНО ИЗ URL.

Режим передачи

Всегда используется потоковый режим.

Gopher

URL-адрес gopher указывает хост и, возможно, порт, к которому клиент должен подключиться. Этот следует косая черта и одиночный код типа суслика. Код этого типа используется клиентом для определения как интерпретировать ответ сервера и не предназначен для отправки на сервер. Командная строка, отправляемая в сервер сразу следует за персонаж типа суслик. Это состоит строки выбора суслика следует любым синтаксисом «Gopher plus», но всегда опускать тренировочный CR НЧ пара.

Когда командная строка gopher содержит символы (такой встроенный CR LF и символы HT) не разрешены в URL-адрес, они закодированы с использованием обычное кодирование.

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

Если закодированная командная строка (с завершающий CR LF удален) будет void, тогда персонаж типа суслика может быть атакован и «1» (ASCII 31 hex) предполагается.

Обратите внимание на косую черту «/» в селекторе суслика. строки могут не соответствовать уровень в иерархической структуре.

Mailto

Это позволяет URL-адресу указывать RFC822 адрес электронной почты, указанный в спецификации. Обратите внимание, что использование%, например, как используется в формирование почтового адреса со шлюзом, требует преобразования в% 25 в URL.

Новости

Локаторы новостей относятся к названия групп новостей или сообщение статьи идентификаторы, которые должны соответствовать правила для идентификатора сообщения RFC 1036 (Horton 1987).Сообщение идентификатор можно отличить от название группы новостей по присутствию рекламного ролика с символом «@». Эти правила подразумевают, что в пределах статья, ссылка на новостную группу или к другой статье будет действительной URL (в частичном виде).

URL-адрес новости может быть разыменован с помощью NNTP (RFC977, Kantor 86) (СТАТЬЯ командой message-id) или с помощью любой другой протокол перевозки новостных статей usenet или по ссылке к телу новостных статей уже получили.

Примечание 1:

Среди URL-адресов «новостные» URL являются аномальными. в том, что они не зависят от местоположения.Они не подходят в качестве кандидатов URN потому что архитектура NNTP полагается по истечении срока действия статей и, следовательно, небольшое количество статей доступны в любое время. Когда появляется новость: URL цитируется, предполагается что читатель получит статью или группа из его или ее местных новостей хозяин. Имена ведущих новостей НЕ являются частью URL-адресов новостей.

Примечание 2:

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

Telnet, rlogin, tn3270

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

URN

«Универсальное имя ресурса» в настоящее время (март 1993 г.) в разработке в IETF. Спецификация требований находится в стадии подготовки. В настоящее время выглядит как будто это будет короткая строка подходит для кодирования в синтаксисе URI, в этом случае префикс «urn:» зарезервировано. URN должен быть закодирован точно так, как определено в (будущем) Стандарт УРН, за исключением того:

Если официальное описание Синтаксис URN включает любую константу символы-обертки, тогда они должны не может быть исключен из кодировки URI УРН;
Если URN имеет иерархический характер, тогда разделитель косой черты должен быть используется в кодировке URI;
Если URN имеет иерархический характер, самая значительная часть должна быть закодировано слева в кодировке URI;
Любые символы с зарезервированными значениями в синтаксисе URI должно быть escape закодированный

Эти правила, конечно, применимы к любому Схема URI.Конечно возможно что будет выбран синтаксис URN так что кодировка URI будет транскрипция 1-1.

Примером может быть такое имя, как

 урна: / iana / dns / ch / cern / cn / techdoc / 94 / 1642-3

, но читателю следует обратиться к последние проекты или спецификации URN. Текущая реализация WAIS общедоступна домен требует, чтобы клиент знал «тип» объекта до извлечения. Это значение возвращается вместе с внутренний идентификатор объекта в поисковый ответ.Это было закодировано в части пути URL-адрес, чтобы URL-адрес был достаточным для поиска объекта. В мире WAIS имена не конечно, нужно использовать префикс «wais:» (по правилам частичной формы).

Wpath URL-адреса WAIS состоит из закодированных полей идентификатора WAIS, в том же порядке, что и в идентификаторе WAIS. Для каждого поля поле идентификатора число — это цифры перед равным знак, а затем следует содержимое поля, закодирован в обычной кодировке, прекращено «;».

файл

Другие схемы URI (кроме nntp) поделитесь собственностью, которой они являются одинаково действует в любом географическом место.

Однако существует реальная практическая требование иметь возможность генерировать URL-адрес объекта в машинном локальная файловая система.

Синтаксис похож на ftp синтаксис, но в данном случае косая черта используется для обозначения границ между уровни каталогов иерархической файловая система. Клиент» программное обеспечение преобразует URL-адрес файла в имя файла в локальном имени файла условности.Это позволяет локальным файлам рассматриваться как сетевые объекты без необходимости использовать сеть сервер для доступа. Это может быть использовано например, для определения пользователя «домашний» документ в WWW.

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

Специальное значение localhost — используется в поле хоста для обозначения что имя файла действительно должно быть используется на любом хосте. Этот например позволяет делать ссылки в файлы, которые распространяются на многие машины, или на «ваш локальный unix файл паролей «тема конечно к согласованности среди пользователей данные.

Пустое поле хоста эквивалентно «локальный хост».

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

Определены две схемы. Первый, «mid:» относится к идентификатору сообщения RFC822. почтового сообщения. Этот идентификатор уже используется в RFC822 для например Ссылки и In-Reply-to поле . Остальная часть URL-адреса после «mid:» — это идентификатор сообщения RFC822. с удаленной оберткой константы <>, оставив идентификатор, формат которого на самом деле это то же самое, что и формат addr-spec для почтовых ящиков (хотя семантика другая).

Использование «среднего» URL подразумевает доступ в уже полученное тело почты.Если сообщение было распространено с использованием NNTP или других протоколов usenet в системе новостей, затем «новости:» форма должна использоваться.

Content-Id

Вторая схема «cid:» аналогична на «mid:», но ссылается на часть тела сообщения MIME от значение его поля идентификатора содержимого. Это позволяет, например, мастеру документ, являющийся первой частью составное / связанное сообщение MIME для обозначения составных частей, которые передаются в одном сообщении.

Примечание

Однако помните, что идентификаторы содержимого только должны быть уникальными в пределах контекст данного сообщения MIME, и поэтому cid: URL имеет смысл только в контексте того же сообщения MIME.Для ссылки вне сообщения, его нужно будет добавить к идентификатор сообщения всего сообщения. Синтаксис для этого не определен.

Схемы для дальнейшего изучения

x500

Отображение имен x500 на URL-адреса здесь не определяется. Решение требуется относительно того, «выдающийся имена »или« удобные имена »(ufn), или оба, должны быть разрешены. Если есть необходимо преобразование знаков препинания из принятого представления x500 (например, использование косой черты между части ufn) они должны быть определены.Это предмет для изучения.

WHOIS

Этот префикс описывает доступ используя схему «whois ++» в процесс определения. Имя хоста часть такая же, как и для других IP схемы на основе. Часть пути может быть либо идентификатором whois для whois объект, или это может быть действительный whois Строка запроса. Это тема для дальнейшее изучение.

База данных сетевого управления

Это предмет для изучения.

NNTP

Это альтернативная форма ссылки для новостных статей, в частности использоваться с серверами NNTP, и особенно эти неполные серверные реализации которые не позволяют получить по сообщению идентификатор.Во всех остальных случаях Следует использовать «новостную» схему.

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

Примечание 1.

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

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

Справочник Просперо (Нойман, 1991) сервис используется для разрешения URL давая метод доступа для объект (который затем сам может быть представлен как URL-адрес, если переведен). Часть хоста содержит имя хоста или адрес в Интернете.Портовая часть не является обязательным.

Часть пути содержит специфичный для хоста имя объекта и необязательная версия номер. Если присутствует, номер версии отделен от конкретного хоста имя объекта символами «% 00» (процент ноль ноль), это экранированный терминатор строки (ноль). Представлены внешние ссылки Просперо как URL-адреса базового доступа метод и не представлены как Просперо URL.

Регистрация схем наименования

Может быть введена новая схема наименования путем определения отображения на соответствующий Синтаксис URL с новым префиксом.Экспериментальный префиксы могут использоваться по взаимной договоренности между сторонами и должен начинаться с символы «x-». Схема имя «urn:» зарезервировано для работы в процессе работы по схеме для получения дополнительной информации стойкие имена.

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

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

Это описание, похожее на BNF. синтаксис URI. на уровне, на котором конкретные схемы не рассматриваются.

Вертикальная линия «|» указывает альтернативы, и [скобки] указывают на необязательный части. Пространства представлены слово «пробел» и вертикаль строчный символ «vline». Одинокий буквы обозначают отдельные буквы. Все слова из более чем одной буквы ниже приведены сущности, описанные где-то в этом описании.

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

адрес фрагмента: uri [# fragmentid ]
ед.: схема: путь [? поиск ]
схема: ialpha
путь: пусто | xpalphas [/ path ]
поиск: xalphas [+ поиск]
фрагментид: xalphas
ксальфа: альфа | цифра | сейф | дополнительный | побег
xalphas: xalpha [xalphas]
xpalpha: xalpha | +
xpalphas: xpalpha [xpalpha]
ialpha: альфа [xalphas]
альфа: a | б | c | d | е | f | г | h | я | j | k | л | м | п | о | p | q | г | s | т | u | v | w | Икс | y | z | А | B | C | D | E | F | G | H | Я | J | K | L | M | N | O | P | Q | R | S | Т | U | V | W | X | Y | Z
цифра: 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
сейф: $ | — | _ | @ | .| ~
пунктуация: <| >
недействительно

(конец URI BNF) Это описание, похожее на BNF. синтаксис унифицированного указателя ресурсов. Вертикальная линия «|» указывает альтернативы, и [скобки] указывают на необязательный части. Пространства представлены слово «пробел» и вертикаль строчный символ «vline». Одинокий буквы обозначают отдельные буквы. Все слова из более чем одной буквы ниже приведены сущности, описанные где-то в этом описании.

Текущая рабочая группа IETF URI предпочтение отдается prefixedurl производство. (Ноябрь 1993 г., июль 93 г.: url).

«Национальная» и «пунктуация» персонажи не появляются ни в каких постановках и поэтому может не отображаться в URL-адресах.

«Afsaddress» оставлен как исторический. обратите внимание, но это не URL-адрес

prefixedurl: u r l: url
ур л: httpaddress | ftpaddress | адрес новостей | nntpaddress | prosperoaddress | telnetaddress | гофераддресс | waisaddress | mailtoaddress | средний адрес | cidaddress
схема: ialpha
httpaddress: h t t p: // хост-порт [ / дорожка ] [ ? поиск ]
ftpaddress: f t p: // логин / путь [ftptype]
afsaddress: a f s: / / cellname / дорожка
информационный адрес: новые: группа
nntpaddress: n n t p: группа / цифры
средний адрес: m i d: адрес-спецификация
cidaddress: c i d: идентификатор-содержимого
mailtoaddress: m a i l t o: xalphas @ имя хоста
waisадрес: waisindex | Waisdoc
waisindex: w a i s: // hostport / база данных [ ? поиск ]
waisdoc: w a i s: / / hostport / база данных / wtype / wpath
путь к wpath: цифра = путь; [wpath]
группа: * | группа | статья
группа: ialpha [.группа ]
артикул: xalphas @ хост
база данных: xalphas
wtype: xalphas
проспероадрес: Просперолинк
prosperolink: p r o s p e r o: / / hostport / hsoname [% 0 0 версия [атрибуты]]
hsoname: путь
версия: цифра
атрибутов: атрибут [атрибуты ]
атрибут: букв
telnetaddress: t e l n e t: // войти
гоферад платье: г о п е р: / / hostport [/ gtype [gcommand]]
логин: [пользователь [: пароль] @] порт хоста
хост-порт: хост [: порт]
хост: имя хоста | hostnumber
ftptype: Код формы | Код формы E | Я | L цифры
код формы: N | Т | C
имя ячейки: имя хоста
имя хоста: ialpha [.имя хоста]
номер хоста: цифр. цифры. цифры . цифры
порт: цифра
gcommand: путь
путь: пусто | сегмент [/ путь]
сегмент: xpalphas
поиск: xalphas [+ поиск]
пользователь: alphanum2 [пользователь]
пароль: alphanum2 [пароль]
фрагментид: xalphas
gtype: xalpha
букв2: альфа | цифра | — | _ | .| +
ксальфа: альфа | цифра | сейф | дополнительный | побег
xalphas: xalpha [xalphas]
xpalpha: xalpha | +
xpalphas: xpalpha [xpalphas]
ialpha: альфа [xalphas]
альфа: a | б | c | d | е | f | г | h | я | j | k | л | м | п | о | p | q | г | s | т | u | v | w | Икс | y | z | А | B | C | D | E | F | G | H | Я | J | K | L | M | N | O | P | Q | R | S | Т | U | V | W | X | Y | Z
цифра: 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
сейф: $ | — | _ | @ | .| ~
пунктуация: <| >
цифр: цифра [цифры]
букв: альфа | цифра
букв: alphanum [alphanums]
недействительно

(конец URL BNF)

Alberti, R., et.al. (1991): «Примечания по протоколу Internet Gopher » Университет Миннесоты, декабрь 1991 г., .См. Также
Бернерс-Ли, Т., (1991): «Гипертекст Протокол передачи (HTTP) », ЦЕРН, Декабрь 1991 г., с поправками по времени время,
Крокер: «Стандарт для ARPA Internet Текстовые сообщения «. Дэвид Х. Крокер, RFC822,
Дэвис, Ф. и др. (1990): «Интерфейс WAIS Протокол: функциональная спецификация прототипа », Thinking Machines Corporation, апрель 23 января 1990 г.
Международная организация по стандартизации, (1991): Информация и документация — Приложение для поиска и извлечения Спецификация протокола для открытого Взаимодействие систем, ISO-10163
Хортон (1987): М. Хортон, Р. Адамс, «Стандарт обмена USENET сообщения », Интернет RFC 1036, 01.12.1987.
Huitema, C., (1991): «Именование: стратегии и техника », Компьютерные сети и ISDN Systems 23 (1991) 107-110.
Кале, Брюстер, (1991): «Документ Идентификаторы, или международный стандарт Книжные номера для электронной эры »,
Кантор, Б., и Лэпсли, П., (1986): «Предлагаемый стандарт для потокового передача новостей », Интернет RFC-977, февраль 1986 г.
Кунце, 1994 г.: Дж. Кунце, Требования для URL-адресов, которые будут опубликованы.
Линч, К., Коалиция за сетевые Информация: (1991): «Мастерская на ID и справочные структуры для сетевых Информация », ноябрь 1991 г. См.
Mockapetris, P., (1987): «Доменные имена + концепции и возможности », RFC-1034, USC-ISI, ноябрь 1987 г.,
Нойман, Б. Клиффорд, (1992): «Просперо: Инструмент для организации интернет-ресурсов », Электронные сети: исследования, Приложения и политика, Том 1, № 2, Меклер Вестпорт, Коннектикут, США.Видеть также
Постел, Дж. И Рейнольдс, Дж. (1985): «Протокол передачи файлов (FTP)», Интернет RFC-959, октябрь 1985 г.
Соллинз 1994: К. Соллинз и Л. Масинтер, Требование публикации URN.
Yeong, W., (1991a): «На пути к сети Информационный поиск «, Технический отчет 91-06-25-01, июнь 1991 г. Systems International, Inc.
Yeong, W., (1991b),: «Представляющий Публичные архивы в каталоге », Internet Draft, ноябрь 1991 г., сейчас истекший.

 Тим Бернерс-Ли

 Адрес: Интернет-проект

 ЦЕРН,

 1211 Женева 23,

 Швейцария

 Телефон: +41 (22) 767 3755

 Факс: +41 (22) 767 7155

 Электронная почта: [email protected]

http — В чем разница между URI, URL и URN?

Содержит информацию о том, как получить ресурс из его местоположения.Например:

http://example.com/mypage.html
ftp://example.com/download.zip
mailto: [email protected]
файл: ///home/user/file.txt
http://example.com/resource?foo=bar#fragment
/other/link.html (относительный URL-адрес, полезен только в контексте другого URL-адреса)

URL-адреса всегда начинаются с протокола ( http ) и обычно содержат такую информацию, как имя сетевого хоста (пример .com ) и часто путь к документу ( /foo/mypage.html ). URL-адреса могут иметь параметры запроса и идентификаторы фрагментов.

Определяет ресурс по имени. Всегда начинается с префикса urn: Например:

urn: isbn: 0451450523 , чтобы идентифицировать книгу по ее номеру ISBN.
urn: uuid: 6e8bc430-9c3a-11d9-9669-0800200c9a66 глобальный уникальный идентификатор
urn: publishing: book — пространство имен XML, которое идентифицирует документ как тип книги.

URN могут идентифицировать идеи и концепции. Они не ограничиваются документами, удостоверяющими личность. Когда URN действительно представляет документ, он может быть переведен в URL-адрес с помощью «преобразователя». Затем документ можно загрузить по URL-адресу.

URI включают как URL, так и URN, а также другие способы указания ресурса.

Примером URI, который не является ни URL-адресом, ни URN, может быть URI данных, например data:, Hello% 20World . Это не URL-адрес или URN, потому что URI содержит данные.Он не называет его и не сообщает, как его найти в сети.

Существуют также унифицированные ссылки на ресурсы (URC), которые указывают на метаданные о документе, а не на сам документ. Примером URC может быть индикатор для просмотра исходного кода веб-страницы: view-source: http: //example.com/ . URC — это еще один тип URI, который не является ни URL-адресом, ни URN.

Я слышал, что мне больше не следует указывать URL, почему?

В спецификации w3 для HTML говорится, что href тега привязки может содержать URI, а не только URL.Вы должны иметь возможность ввести URN, например . Затем ваш браузер преобразует этот URN в URL-адрес и загрузит книгу для вас.

Какие-нибудь браузеры действительно знают, как получать документы по URN?

Не знаю, но современный веб-браузер реализует схему URI данных.

Может ли URI быть одновременно URL и URN?

Хороший вопрос. Я видел много мест в сети, где утверждается, что это правда. Мне не удалось найти никаких примеров того, что одновременно является URL-адресом и URN.Я не понимаю, как это возможно, потому что URN начинается с urn: , что не является допустимым сетевым протоколом.

Имеет ли разница между URL и URI какое-либо отношение к тому, является ли оно относительным или абсолютным?

Нет. И относительные, и абсолютные URL-адреса являются URL-адресами (и URI).

Имеет ли разница между URL и URI какое-либо отношение к тому, есть ли у него параметры запроса?

Нет. Оба URL-адреса с параметрами запроса и без них являются URL-адресами (и URI.)

Имеет ли разница между URL и URI какое-либо отношение к тому, есть ли у него идентификатор фрагмента?

Нет. Оба URL-адреса с идентификаторами фрагментов и без них являются URL-адресами (и URI).

Является ли URI

tel: URL-адресом или URN?

Например тел: 1-800-555-5555 . Он не начинается с urn: и имеет протокол для доступа к ресурсу по сети. Это должен быть URL.

Но разве теперь w3C не говорит, что URL-адреса и URI — это одно и то же?

Да.W3C понял, что по этому поводу существует масса путаницы. Они выпустили документ с разъяснением URI, в котором говорится, что теперь можно использовать URL и URI как взаимозаменяемые. Больше нет смысла строго сегментировать URI на разные типы, такие как URL, URN и URC.

http — В чем разница между URI, URL и URN?

Лучшее (техническое) резюме imo это

IRI, URI, URL, URN и их отличия от Jan Martin Keil:

IRI, URI, URL, URN и их различия

Каждый, кто имеет дело с Семантической паутиной, постоянно сталкивается с терминами IRI , URI , URL и URN .Тем не менее, я часто замечаю некоторую путаницу в их точном значении. И, конечно же, это заметили и другие (см., Например, RFC3305 или поиск в Google). Если честно, я даже сам вначале запутался. Но на самом деле вопрос не такой уж и сложный. Давайте посмотрим на определения упомянутых терминов, чтобы увидеть, в чем разница:

URI

Универсальный идентификатор ресурса — это компактная последовательность символов, которая идентифицирует абстрактный или физический ресурс.Набор символов ограничен US-ASCII, за исключением некоторых зарезервированных символов. Символы вне набора разрешенных символов могут быть представлены с использованием процентного кодирования. URI может использоваться как указатель, имя или и то, и другое. Если URI является указателем, он описывает основной механизм доступа к ресурсу. Если URI — это имя, он идентифицирует ресурс, давая ему уникальное имя. Точные спецификации синтаксиса и семантики URI зависят от используемой схемы, которая определяется символами перед первым двоеточием.[RFC3986]

URN

Унифицированное имя ресурса — это URI в урне схемы, предназначенный для использования в качестве постоянного, независимого от местоположения идентификатора ресурса. Исторически этот термин также относился к любому URI. [RFC3986] URN состоит из идентификатора пространства имен (NID) и специальной строки пространства имен (NSS): urn :: Синтаксис и семантика NSS специфичны для каждого NID. Помимо зарегистрированных NID, существует еще несколько NID, которые не прошли официальную регистрацию.[RFC2141]

URL

Унифицированный указатель ресурса — это URI, который, помимо идентификации ресурса, предоставляет средства определения местоположения ресурса путем описания его основного механизма доступа [RFC3986]. Поскольку не существует точного определения URL с помощью набора схем, «URL — полезная, но неформальная концепция», обычно относящаяся к подмножеству URI, которые не содержат URN [RFC3305].

IRI

Интернационализированный идентификатор ресурса определяется аналогично URI, но набор символов расширяется до универсального набора кодированных символов.Следовательно, он может содержать любые латинские и нелатинские символы, кроме зарезервированных символов. Вместо расширения определения URI был введен термин IRI, чтобы учесть четкое различие и избежать несовместимости. IRI предназначены для замены URI при идентификации ресурсов в ситуациях, когда поддерживается универсальный набор кодированных символов. По определению каждый URI — это IRI. Кроме того, существует определенное сюръективное сопоставление IRI с URI: каждый IRI может быть сопоставлен точно с одним URI, но разные IRI могут отображаться на один и тот же URI.Следовательно, обратное преобразование из URI в IRI может не дать исходный IRI. [RFC3987]

Обобщая можно сказать:

  IRI - это расширенный набор URI (IRI ⊃ URI)
URI - это надмножество URL (URI ⊃ URL)
URI - это надмножество URN (URI ⊃ URN)
URL и URN не пересекаются (URL ∩ URN = ∅)

Выводы по проблемам семантической паутины

RDF явно позволяет использовать IRI для именования объектов [RFC3987]. Это означает, что мы можем использовать почти каждый символ в именах сущностей.С другой стороны, нам часто приходится иметь дело с программным обеспечением раннего состояния. Таким образом, маловероятно, что возникнут проблемы с использованием символов, отличных от ASCII. Поэтому я предлагаю избегать имен объектов, отличных от URI, и рекомендовать использовать http URI [LINKED-DATA]. Короче говоря: используйте только URL-адреса для именования своих сущностей. Конечно, мы можем ссылаться на существующие сущности, названные URN. Однако нам следует избегать создания новых идентификаторов такого типа.

Пример HTML-документа

Network Working Group T.Бернерс-Ли Запрос комментариев: 2396 MIT / LCS Обновления: 1808, 1738 Р. Филдинг Категория: Стандарты Track U.C. Ирвин Л. Масинтер Xerox Corporation Август 1998 г. Универсальные идентификаторы ресурсов (URI): общий синтаксис Статус этого меморандума Этот документ определяет протокол отслеживания стандартов Интернета для Интернет-сообщество и просит обсуждения и предложения по улучшения.Пожалуйста, обратитесь к текущему выпуску «Интернет Официальные стандарты протокола »(STD 1) для состояния стандартизации и статус этого протокола. Распространение этой памятки не ограничено. Уведомление об авторских правах Авторское право (C) The Internet Society (1998). Все права защищены. Примечание IESG В этой статье описывается «надмножество» операций, которые могут быть применены в URI. Он состоит из грамматики и описания основных функциональность для URI. Чтобы понять, что такое действительный URI, оба грамматика и соответствующее описание должны быть изучены.Некоторые из описанная функциональность применима не ко всем схемам URI, и некоторые операции возможны только при определенных типах носителей. извлекается с использованием URI независимо от используемой схемы. Абстрактный Универсальный идентификатор ресурса (URI) — это компактная строка символов. для идентификации абстрактного или физического ресурса. Этот документ определяет общий синтаксис URI, включая как абсолютный, так и относительные формы и инструкции по их использованию; он пересматривает и заменяет общие определения в RFC 1738 и RFC 1808.Этот документ определяет грамматику, которая является надмножеством всех действительных URI, так что реализация может анализировать общие компоненты URI ссылку, не зная специфических для схемы требований каждого возможный тип идентификатора. Этот документ не определяет генеративную грамматика для URI; эту задачу будет выполнять человек спецификации каждой схемы URI. Бернерс-Ли и др. al. Standards Track [Страница 1] RFC 2396 Универсальный синтаксис URI, август 1998 г. 1.Вступление Унифицированные идентификаторы ресурсов (URI) обеспечивают простой и расширяемый средство для идентификации ресурса. Эта спецификация синтаксиса URI и семантика происходит от концепций, представленных Всемирной Глобальная информационная веб-инициатива, чье использование таких объектов датируется с 1990 г. и описан в «Универсальных идентификаторах ресурсов в WWW». [RFC1630]. Спецификация URI разработана с учетом рекомендации, изложенные в «Функциональных рекомендациях для Интернета» Указатели ресурсов »[RFC1736] и« Функциональные требования для унифицированных Имена ресурсов »[RFC1737].В этом документе обновлены и объединены «Унифицированные указатели ресурсов». [RFC1738] и «Относительные унифицированные указатели ресурсов» [RFC1808] по порядку чтобы определить единый общий синтаксис для всех URI. Это исключает те части RFC 1738, определяющие особый синтаксис отдельных Схемы URL; эти части будут обновлены как отдельные документы, так как будет процесс регистрации новых схем URI. Этот документ не обсуждает вопросы и рекомендации по устранению символы вне набора символов US-ASCII [ASCII]; те рекомендации обсуждаются в отдельном документе.Все существенные изменения по сравнению с предыдущими RFC указаны в Приложении G. 1.1 Обзор URI URI характеризуются следующими определениями: Униформа Единообразие дает несколько преимуществ: позволяет использовать разные типы идентификаторов ресурсов, которые будут использоваться в одном контексте, даже когда механизмы, используемые для доступа к этим ресурсам, могут отличаться; это позволяет единообразную семантическую интерпретацию общепринятых синтаксических соглашения по различным типам идентификаторов ресурсов; Это позволяет вводить новые типы идентификаторов ресурсов не вмешиваясь в способ, которым существующие идентификаторы использовал; и это позволяет повторно использовать идентификаторы во многих различные контексты, что позволяет создавать новые приложения или протоколы для использования уже существующих, больших и широко используемых набор идентификаторов ресурсов.Ресурс Ресурс может быть чем угодно, имеющим идентичность. Знакомые примеры включают электронный документ, изображение, услугу (например, «прогноз погоды на сегодня в Лос-Анджелесе») и сбор других ресурсов. Не все ресурсы являются сетевыми «извлекаемый»; например, люди, корпорации и связанные книги в библиотеке также можно считать ресурсами. Бернерс-Ли и др. al. Стандарты Track [Страница 2] RFC 2396 Универсальный синтаксис URI, август 1998 г. Ресурс — это концептуальное отображение сущности или набора сущности, не обязательно сущность, которая соответствует этому отображение в любой конкретный момент времени.Таким образом, ресурс может оставаться постоянным, даже если его содержимое — сущности для которому он соответствует в настоящее время — изменяется с течением времени, при условии что концептуальное отображение не изменяется в процессе. Идентификатор Идентификатор — это объект, который может действовать как ссылка на то, что имеет идентичность. В случае URI объект последовательность символов с ограниченным синтаксисом. Определив ресурс, система может выполнять множество операции над ресурсом, что можно охарактеризовать такими словами как «доступ», «обновление», «замена» или «поиск атрибутов».1.2. URI, URL и URN URI можно дополнительно классифицировать как указатель, имя или и то, и другое. В термин «унифицированный указатель ресурса» (URL) относится к подмножеству URI которые идентифицируют ресурсы через представление их первичного доступа механизм (например, их сетевое «местоположение»), а не определение ресурс по имени или каким-либо другим атрибутам этого ресурса. Термин «Унифицированное имя ресурса» (URN) относится к подмножеству URI. которые необходимы, чтобы оставаться глобально уникальными и постоянными, даже если ресурс перестает существовать или становится недоступным.Схема URI (раздел 3.1) определяет пространство имен URI, и таким образом может дополнительно ограничить синтаксис и семантику идентификаторов используя эту схему. Эта спецификация определяет эти элементы Синтаксис URI, который либо требуется для всех схем URI, либо является общим ко многим схемам URI. Таким образом, он определяет синтаксис и семантику, которые необходимы для реализации независимого от схемы механизма синтаксического анализа для Ссылки на URI, так что зависимая от схемы обработка URI может быть отложено до тех пор, пока не потребуется семантика, зависящая от схемы.Мы используем термин URL ниже при описании синтаксиса или семантики, которые только применить к локаторам. Хотя многие схемы URL-адресов названы в честь протоколов, это не подразумевают, что единственный способ получить доступ к ресурсу URL-адреса — через именованный протокол. Шлюзы, прокси, кеши и службы разрешения имен может использоваться для доступа к некоторым ресурсам, независимо от протокола их происхождения, а разрешение некоторых URL-адресов может потребовать использования более одного протокола (например, как правило, используются и DNS, и HTTP для доступа к ресурсу URL «http», когда он не может быть найден в локальном кеш).Бернерс-Ли и др. al. Стандарты Track [Страница 3] RFC 2396 Универсальный синтаксис URI, август 1998 г. URN отличается от URL-адреса тем, что его основная цель — постоянство. маркировка ресурса идентификатором. Этот идентификатор нарисован из одного из набора определенных пространств имен, каждое из которых имеет собственное установить структуру имени и порядок присвоения. Схема «урна» имеет зарезервировано для установления требований к стандартизированному URN пространство имен, как определено в «Синтаксисе URN» [RFC2141] и связанном с ним технические характеристики.Большинство примеров в этой спецификации демонстрируют URL, поскольку они допускают самое разнообразное использование синтаксиса и часто имеют иерархическое пространство имен. Парсер синтаксиса URI может синтаксический анализ ссылок URL и URN как универсального URI; однажды схема определен, синтаксический анализ схемы может быть выполнен на общие компоненты URI. Другими словами, синтаксис URI — это надмножество синтаксиса всех схем URI. 1.3. Пример URI Следующие примеры иллюстрируют широко используемые URI.ftp://ftp.is.co.za/rfc/rfc1808.txt — схема ftp для служб протокола передачи файлов суслик: //spinaltap.micro.umn.edu/00/Weather/California/Los%20Angeles — схема суслика для сервисов Gopher и Gopher + Protocol http://www.math.uio.no/faq/compression-faq/part1.html — схема http для служб протокола передачи гипертекста mailto: [email protected] — схема mailto для адресов электронной почты новости: comp.infosystems.www.servers.unix — схема новостей для новостных групп и статей USENET телнет: // мелвил.ucop.edu/ — схема telnet для интерактивных сервисов по протоколу TELNET 1.4. Иерархический URI и относительные формы Абсолютный идентификатор относится к ресурсу, независимому от контекст, в котором используется идентификатор. Напротив, родственник идентификатор относится к ресурсу, описывая разницу в иерархическое пространство имен между текущим контекстом и абсолютным идентификатор ресурса. Бернерс-Ли и др. al. Стандарты Track [Страница 4] RFC 2396 Универсальный синтаксис URI, август 1998 г. Некоторые схемы URI поддерживают иерархическую систему именования, в которой иерархия имени обозначается разделителем «/», разделяющим компоненты в схеме.Этот документ определяет независимую от схемы «относительная» форма ссылки URI, которая может использоваться вместе с «базовый» URI (иерархической схемы) для создания другого URI. В синтаксис иерархического URI описан в разделе 3; Относительная Расчет URI описан в разделе 5. 1.5. Транскрибируемость URI Синтаксис URI был разработан с учетом глобальной транскрибируемости как одного из его основные проблемы. URI — это последовательность символов из очень ограниченный набор, т.е. буквы основного латинского алфавита, цифры, и несколько специальных символов.URI может быть представлен в различных способов: например, чернила на бумаге, пиксели на экране или последовательность октеты в кодированном наборе символов. Интерпретация URI зависит от только на используемых персонажах, а не на том, как эти символы представлен в сетевом протоколе. Цель транскрибируемости может быть описана простым сценарием. Представьте себе двух коллег, Сэма и Ким, сидящих в пабе в международная конференция и обмен исследовательскими идеями. Сэм спрашивает Ким для местоположения, чтобы получить дополнительную информацию, поэтому Ким записывает URI для сайт исследования на салфетке.Вернувшись домой, Сэм достает салфетка и вводит URI в компьютер, который затем получает информация, на которую ссылается Ким. Сценарий выявил несколько конструктивных проблем: o URI — это последовательность символов, которая не всегда представлен как последовательность октетов. o URI может быть записан из несетевого источника и, следовательно, должен состоять из персонажей, которые, скорее всего, смогут быть введенным в компьютер в рамках ограничений, налагаемых клавиатуры (и связанные устройства ввода) на разных языках и локации.o URI часто нужно запоминать людям, и это проще чтобы люди запомнили URI, когда он состоит из значимых составные части. Эти дизайнерские проблемы не всегда совпадают. Например, это часто бывает, что наиболее значимое имя для компонента URI потребуются символы, которые нельзя ввести в некоторых системах. В возможность транскрибировать идентификатор ресурса с одного носителя на другой считался более важным, чем его URI, состоящий из самый значимый из компонентов.В местном и региональном контексте Бернерс-Ли и др. al. Стандарты Track [Страница 5] RFC 2396 Универсальный синтаксис URI, август 1998 г. а с улучшением технологий пользователи могут получить выгоду от возможности использовать более широкий набор символов; такое использование не определено в этом документ. 1.6. Обозначение синтаксиса и общие элементы В этом документе используются два соглашения для описания и определения синтаксиса. для URI. Первая, называемая формой макета, представляет собой общее описание. порядка компонентов и разделителей компонентов, как в / ;? Имена компонентов заключаются в угловые скобки и любые символы. внешние угловые скобки являются буквальными разделителями.Пробел должен быть игнорируется. Эти описания используются неформально и не определяют требования к синтаксису. Второе соглашение — это грамматика, подобная BNF, используемая для определения формальный синтаксис URI. Грамматика соответствует [RFC822], за исключением того, что «|» используется для обозначения альтернатив. Вкратце правила отделены от определения равным «=», отступ используется для продолжения правила определение занимает более одной строки, литералы заключаются в кавычки «», круглые скобки «(» и «)» используются для группировки элементов, необязательные элементы заключены в квадратные скобки «[» и «]», и перед элементами могут быть поставлены с * для обозначения n или более повторений следующего элемент; n по умолчанию 0.В отличие от многих спецификаций, которые используют грамматику, подобную BNF, для определения байтов (октетов), разрешенных протоколом, грамматика URI определяется в круг персонажей. Каждый литерал в грамматике соответствует символ, который он представляет, а не кодировку октета этого символ в любом конкретном кодированном наборе символов. Как устроен URI представлен в виде битов и байтов на проводе, зависит от кодировка символов протокола, используемого для его передачи, или кодировка документа, который его содержит.Следующие определения являются общими для многих элементов: альфа = низкая альфа | Упальфа lowalpha = «а» | «б» | «с» | «д» | «е» | «е» | «г» | «h» | «я» | «j» | «к» | «л» | «м» | «п» | «о» | «р» | «q» | «г» | «s» | «т» | «u» | «v» | «ш» | «х» | «у» | «z» upalpha = «А» | «Б» | «C» | «Д» | «E» | «F» | «G» | «H» | «Я» | «J» | «К» | «L» | «М» | «N» | «О» | «П» | «Q» | «R» | «S» | «Т» | «U» | «V» | «W» | «Х» | «Y» | «Z» Бернерс-Ли и др.al. Стандарты Track [Страница 6] RFC 2396 Универсальный синтаксис URI, август 1998 г. цифра = «0» | «1» | «2» | «3» | «4» | «5» | «6» | «7» | «8» | «9» алфавит = альфа | цифра Полный синтаксис URI собран в Приложении A. 2. Символы URI и escape-последовательности URI состоит из ограниченного набора символов, в основном выбранных для способствуют транскрибируемости и удобству использования как в компьютерных системах, так и в некомпьютерные коммуникации.Символы, обычно используемые как разделители вокруг URI были исключены. Ограниченный набор символы состоят из цифр, букв и нескольких графических символов были выбраны из тех, которые являются общими для большинства кодировок символов и средства ввода, доступные пользователям Интернета. uric = зарезервировано | безоговорочно | сбежал В URI символы используются либо как разделители, либо как представляют строки данных (октеты) в разделенных частях. Октеты либо представлены непосредственно символом (с использованием US- ASCII-символ для этого октета [ASCII]) или escape-кодировкой.Это представление подробно описано ниже. 2.1 URI и символы, отличные от ASCII Связь между URI и символами была источником путаница с символами, не входящими в US-ASCII. Описать отношения, полезно различать «характер» (как различимая семантическая сущность) и «октет» (8-битный байт). Есть два сопоставления, одно из символов URI в октеты и секунда от октетов до исходных символов: Последовательность символов URI-> последовательность октетов-> исходная последовательность символов URI представлен как последовательность символов, а не как последовательность октетов.Это потому, что URI может быть «транспортирован» с помощью не через компьютерную сеть, например, напечатаны на бумаге, прочитаны радио и т. д. Схема URI может определять отображение символов URI в октеты; будет ли это сделано, зависит от схемы. Обычно в пределах разделенный компонент URI, последовательность символов может использоваться для представляют собой последовательность октетов. Например, символ «а» представляет октет 97 (десятичный), а последовательность символов «%», «0», «a» представляет октет 10 (десятичный).Бернерс-Ли и др. al. Стандарты Track [Страница 7] RFC 2396 Универсальный синтаксис URI, август 1998 г. Для некоторых ресурсов есть второй перевод: последовательность октеты, определенные компонентом URI, впоследствии используются для представляют собой последовательность символов. «Кодировка» определяет это отображение. В Интернет-протоколах используется множество кодировок. Например, UTF-8 [UTF-8] определяет отображение последовательностей октетов в последовательности. персонажей в репертуаре ISO 10646.В простейшем случае исходная последовательность символов содержит только символы, определенные в US-ASCII, и два уровня отображение простое и легко обратимое: каждый «оригинальный символ» представлен как октет для кода US-ASCII для него, то есть в свою очередь, представлен либо как символ US-ASCII, либо как Управляющая последовательность «%» для этого октета. Для исходных последовательностей символов, содержащих символы, отличные от ASCII, однако ситуация сложнее.Интернет-протоколы, которые передавать последовательности октетов, предназначенные для представления последовательностей символов ожидается, что они предоставят способ определения используемой кодировки, если их может быть несколько [RFC2277]. Однако в настоящее время в универсальном синтаксисе URI нет условий для выполнения этого удостоверение личности. Для отдельной схемы URI может потребоваться один кодировку, определите кодировку по умолчанию или предоставьте способ указать используется кодировка. Ожидается, что систематическая обработка кодировки символов в URI будет разрабатываться как будущая модификация этого Спецификация.2.2. Зарезервированные персонажи Многие URI включают компоненты, состоящие из определенных специальные символы. Эти символы называются «зарезервированными», поскольку их использование в компоненте URI ограничено их зарезервированными цель. Если данные для компонента URI будут конфликтовать с зарезервированная цель, то конфликтующие данные должны быть экранированы перед формирование URI. зарезервировано = «;» | «/» | «?» | «:» | «@» | «&» | «=» | «+» | «$» | «,» Вышеупомянутый «зарезервированный» синтаксический класс относится к тем символам, которые разрешено в URI, но не может быть разрешено в пределах конкретный компонент универсального синтаксиса URI; они используются как разделители компонентов, описанных в разделе 3.Бернерс-Ли и др. al. Стандарты Track [Страница 8] RFC 2396 Универсальный синтаксис URI, август 1998 г. Символы в «зарезервированном» наборе зарезервированы не во всех контекстах. Набор символов, фактически зарезервированных в любом заданном URI компонент определяется этим компонентом. В общем, персонаж зарезервировано, если семантика URI изменяется, если символ заменено его экранированной кодировкой US-ASCII. 2.3. Незарезервированные персонажи Символы данных, которые разрешены в URI, но не имеют зарезервированного цели называются безоговорочными.К ним относятся верхний и нижний регистр буквы, десятичные цифры и ограниченный набор знаков препинания и символы. unreserved = буквенный | отметка mark = «-» | «_» | «.» | «!» | «~» | «*» | «‘» | «(» | «)» Незарезервированные символы можно экранировать без изменения семантики URI, но этого не следует делать, если URI не используется в контексте, который не позволяет появиться неэкранированному символу. 2.4. Последовательности побега Данные должны быть экранированы, если они не имеют представления с использованием безоговорочный характер; это включает данные, которые не соответствуют печатный символ из набора символов US-ASCII, или соответствует любому запрещенному символу US-ASCII, так как объяснено ниже.2.4.1. Экранированное кодирование Экранированный октет кодируется как тройка символов, состоящая из символ процента «%», за которым следуют две шестнадцатеричные цифры представляющий октетный код. Например, «% 20» — это экранированный кодировка символа пробела US-ASCII. escaped = «%» шестнадцатеричное шестнадцатеричное шестнадцатеричный = цифра | «А» | «Б» | «C» | «Д» | «E» | «F» | «а» | «б» | «с» | «д» | «е» | «е» 2.4.2. Когда бежать и не убегать URI всегда находится в «экранированной» форме, так как экранирование или отмену экранирования завершенный URI может изменить свою семантику.Обычно единственный раз escape-кодирование может быть безопасно выполнено, когда создается URI из его составных частей; каждый компонент может иметь свой собственный набор символы, которые зарезервированы, поэтому только механизм, отвечающий за создание или интерпретация этого компонента может определить, Бернерс-Ли и др. al. Стандарты Track [Страница 9] RFC 2396 Универсальный синтаксис URI, август 1998 г. отсутствие экранирования символа изменит его семантику.Аналогично, URI должны быть разделены на компоненты перед экранированными символами внутри этих компонентов можно безопасно декодировать. В некоторых случаях данные, которые могут быть представлены безоговорочным персонаж может казаться экранированным; например, некоторые из безоговорочных Некоторые системы автоматически экранируют символы «марки». Если данная схема URI определяет алгоритм канонизации, тогда Незарезервированные символы могут быть неэкранированы в соответствии с этим алгоритмом. Например, «% 7e» иногда используется вместо «~» в URL-адресе http. path, но они эквивалентны для URL-адреса http.Поскольку символ процента «%» всегда имеет зарезервированную цель будучи индикатором перехода, он должен быть экранирован как «% 25», чтобы использоваться как данные в URI. Разработчики должны быть осторожны, чтобы не экранировать или отменять экранирование одной и той же строки более одного раза, поскольку уже неэкранированная строка может привести к неправильной интерпретации процента символ данных как еще один экранированный символ, или наоборот в случай экранирования уже экранированной строки. 2.4.3. Исключенные символы US-ASCII Хотя они запрещены в синтаксисе URI, мы включаем сюда описание тех символов US-ASCII, которые были исключены, и причины их исключения.Управляющие символы в наборе кодированных символов US-ASCII не используются в URI, потому что они не печатаются и потому что они могут быть неправильно истолкованы некоторыми механизмами контроля. control = Пробел исключен, поскольку значимые пробелы могут исчезнут и незначащие пробелы могут быть введены, когда URI транскрибируется или набирается, или подвергается обработке слова- программы обработки. Пробелы также используются для разграничения URI во многих контексты.пробел = Угловая скобка «» и двойные кавычки («) являются исключены, потому что они часто используются в качестве разделителей URI в текстовые документы и поля протокола. Знак «#» исключен потому что он используется для отделения URI от идентификатора фрагмента в URI ссылки (Раздел 4). Знак процента «%» исключен, потому что он используется для кодирования экранированных символов. delims = «» | «#» | «%» | Бернерс-Ли и др. al. Стандарты Track [Страница 10] RFC 2396 Универсальный синтаксис URI, август 1998 г. Остальные символы исключены, потому что шлюзы и другой транспорт известно, что агенты иногда модифицируют такие символы, или они используется в качестве разделителей.»|» [«|»] «|» `» Данные, соответствующие исключенным символам, должны быть экранированы, чтобы быть правильно представленным в URI. 3. Синтаксические компоненты URI Синтаксис URI зависит от схемы. В общем, абсолютное URI записываются следующим образом: : Абсолютный URI содержит имя используемой схемы () за которым следует двоеточие («:»), а затем строка (), интерпретация которой зависит от схемы. Синтаксис URI не требует, чтобы часть, относящаяся к конкретной схеме, имела любая общая структура или набор семантики, которые являются общими для всех URI.Однако подмножество URI имеет общий синтаксис для представление иерархических отношений в пространстве имен. Этот Синтаксис «универсального URI» состоит из последовательности из четырех основных компонентов: : //? каждый из которых, кроме, может отсутствовать в конкретном URI. Например, некоторые схемы URI не позволяют использовать компонент, а другие не используют компонент. absoluteURI = схема «:» (hier_part | opaque_part) URI, которые являются иерархическими по своей природе, используют символ косой черты «/» для разделение иерархических компонентов.Для некоторых файловых систем знак «/» символ (используется для обозначения иерархической структуры URI) — это разделитель, используемый для построения иерархии имен файлов, и, следовательно, URI путь будет похож на путь к файлу. Это НЕ означает, что ресурс — это файл или то, что URI сопоставляется с реальной файловой системой путь. hier_part = (net_path | abs_path) [«?» запрос ] net_path = «//» авторитет [abs_path] abs_path = «/» path_segments Бернерс-Ли и др.al. Стандарты Track [стр. 11] RFC 2396 Универсальный синтаксис URI, август 1998 г. URI, в которых не используется косая черта «/» для разделения иерархические компоненты считаются непрозрачными по универсальному URI парсер. opaque_part = uric_no_slash * uric uric_no_slash = незарезервировано | сбежал | «;» | «?» | «:» | «@» | «&» | «=» | «+» | «$» | «,» Мы используем этот термин для обозначения как конструкции, поскольку они являются взаимоисключающими для любых заданный URI и может быть проанализирован как отдельный компонент.3.1. Компонент схемы Так же, как существует множество различных методов доступа к ресурсам, существует множество схем выявления таких ресурсов. В Синтаксис URI состоит из последовательности компонентов, разделенных зарезервированными символов, причем первый компонент определяет семантику для остаток строки URI. Имена схем состоят из последовательности символов, начинающихся с строчная буква, за которой следует любая комбинация строчных букв буквы, цифры, плюс («+»), точка («.») или дефис (» — «). Для отказоустойчивость, программы, интерпретирующие URI, должны обрабатывать буквы верхнего регистра как эквивалент нижнего регистра в именах схем (например, разрешить «HTTP» как а также «http»). схема = альфа * (альфа | цифра | «+» | «-» | «.») Относительные ссылки URI отличаются от абсолютных URI тем, что они не начинаются с названия схемы. Вместо этого схема наследуется от базового URI, как описано в Разделе 5.2. 3.2. Компонент полномочий Многие схемы URI включают в себя верхний иерархический элемент для именования. полномочия, так что пространство имен, определенное оставшейся частью URI регулируется этим органом.Этот авторитетный компонент обычно определяется сервером в Интернете или конкретной схемой реестр агентств по присвоению имен. авторитет = сервер | reg_name Компоненту полномочий предшествует двойная косая черта «//» и заканчивается следующей косой чертой «/», вопросительным знаком «?» или в конце URI. Внутри компонента полномочий символы «;», «:», «@», «?» и «/» зарезервированы. Бернерс-Ли и др. al. Стандарты Track [Страница 12] RFC 2396 Универсальный синтаксис URI, август 1998 г. Компонент полномочий не требуется для использования схемы URI относительных ссылок.Базовый URI без компонента полномочий подразумевает, что любая относительная ссылка также будет без авторитета компонент. 3.2.1. Администрация именования на основе реестра Структура центра именования на основе реестра специфична для Схема URI, но ограничена разрешенными символами для авторитетный компонент. reg_name = 1 * (незарезервировано | экранировано | «$» | «,» | «;» | «:» | «@» | «&» | «=» | «+») 3.2.2. Серверный орган управления именами Схемы URL, которые включают прямое использование протокола на основе IP для указанный сервер в Интернете использует общий синтаксис для сервера компонент данных схемы URI: @: где может состоять из имени пользователя и, необязательно, схемы- конкретная информация о том, как получить разрешение на доступ к сервер.Части «@» и «:» можно опустить. server = [[userinfo «@»] hostport] Информация о пользователе, если таковая присутствует, сопровождается рекламным знаком. «@». userinfo = * (незарезервировано | экранировано | «;» | «:» | «&» | «=» | «+» | «$» | «,») Некоторые схемы URL используют формат «пользователь: пароль» в информации о пользователе. поле. Эта практика НЕ РЕКОМЕНДУЕТСЯ, потому что прохождение информация аутентификации в виде открытого текста (например, URI) доказала свою эффективность представлять угрозу безопасности почти в каждом случае, когда он использовался.Хост — это доменное имя сетевого хоста или его IPv4-адрес в качестве набор из четырех групп десятичных цифр, разделенных знаком «.». Буквальный IPv6 адреса не поддерживаются. hostport = host [«:» порт] host = hostname | IPv4адрес hostname = * (domainlabel «.») toplabel [«.» ] domainlabel = alphanum | alphanum * (alphanum | «-«) alphanum toplabel = alpha | альфа * (alphanum | «-«) alphanum Бернерс-Ли и др. al. Стандарты Track [стр. 13] RFC 2396 Универсальный синтаксис URI, август 1998 г. IPv4address = 1 * цифра «.«1 * цифра». «1 * цифра». «1 * цифра порт = * цифра Имена хостов имеют форму, описанную в разделе 3 [RFC1034] и Раздел 2.1 [RFC1123]: последовательность меток доменов, разделенных «.», каждая метка домена начинается и заканчивается буквенно-цифровыми символ и, возможно, также содержащий символы «-«. Крайний правый метка домена полного доменного имени никогда не будет начинаться с цифра, таким образом, синтаксически отличая доменные имена от IPv4 адресов и может сопровождаться одним «.»если необходимо различать полное доменное имя и любой локальный домен. Чтобы действительно быть «унифицированным» в качестве указателя ресурсов, имя хоста URL должно быть полным доменным именем. Однако на практике хост компонент может быть литералом локального домена. Примечание. Подходящее представление для включения буквального IPv6. адрес в качестве хостовой части URL-адреса желателен, но еще не был определены или реализованы на практике. Порт — это номер сетевого порта для сервера.Большинство схем назначить протоколы, у которых есть номер порта по умолчанию. Другой порт число может быть дополнительно указано в десятичном виде, отделенном от host через двоеточие. Если порт не указан, по умолчанию используется номер порта. предполагается. 3.3. Компонент пути Компонент пути содержит данные, относящиеся к органу власти (или схема, если нет авторитетного компонента), идентифицирующий ресурс в рамках этой схемы и полномочий. путь = [abs_path | непрозрачная_часть] path_segments = сегмент * (сегмент «/») сегмент = * pchar * («;» параметр) param = * pchar pchar = незарезервировано | сбежал | «:» | «@» | «&» | «=» | «+» | «$» | «,» Путь может состоять из последовательности сегментов пути, разделенных символом одинарная косая черта «/».Внутри сегмента пути символы «/», «;», «=» и «?» зарезервированы. Каждый сегмент пути может включать последовательность параметров, обозначенная точкой с запятой «;» персонаж. Параметры не важны для анализа относительных использованная литература. Бернерс-Ли и др. al. Стандарты Track [стр. 14] RFC 2396 Универсальный синтаксис URI, август 1998 г. 3.4. Компонент запроса Компонент запроса — это строка информации, которую должен интерпретировать ресурс.query = * uric Внутри компонента запроса символы «;», «/», «?», «:», «@», «&», «=», «+», «,» и «$» зарезервированы. 4. Ссылки URI Термин «URI-ссылка» используется здесь для обозначения общего использования идентификатор ресурса. Ссылка URI может быть абсолютной или относительной, и может содержать дополнительную информацию в виде идентификатор фрагмента. Однако «URI», полученный в результате такого ссылка включает только абсолютный URI после фрагмента идентификатор (если есть) удаляется и после разрешения любого относительного URI в его абсолютной форме.Хотя можно ограничить обсуждение синтаксиса и семантики URI до абсолютного В результате URI чаще всего используется в общих ссылках URI, и это невозможно получить URI из такой ссылки без разбор фрагмента и разрешение относительной формы. URI-ссылка = [absoluteURI | relativeURI] [фрагмент «#»] Синтаксис относительного URI — это сокращенная форма синтаксиса абсолютного URI, где отсутствует какой-то префикс URI и определенный путь составные части («.»и» .. «) имеют особое значение тогда и только тогда, когда, интерпретация относительного пути. Относительный синтаксис URI определен в Раздел 5. 4.1. Идентификатор фрагмента Когда ссылка URI используется для выполнения действия извлечения на идентифицированный ресурс, необязательный идентификатор фрагмента, отделенный от URI, обозначенный символом штриховки («#»), состоит из дополнительных справочная информация, которую должен интерпретировать пользовательский агент после поисковое действие было успешно завершено.Таким образом, это не часть URI, но часто используется вместе с URI. фрагмент = * урик Семантика идентификатора фрагмента — это свойство данных. в результате действия извлечения, независимо от типа используемого URI в ссылке. Следовательно, формат и интерпретация идентификаторы фрагментов зависят от типа носителя [RFC2046] результат поиска. Ограничения по символам, описанные в разделе 2 Бернерс-Ли и др. al. Стандарты Track [Страница 15] RFC 2396 Универсальный синтаксис URI, август 1998 г. for URI также применяется к фрагменту в URI-ссылке.Физическое лицо типы носителей могут определять дополнительные ограничения или структуру внутри фрагмент для указания различных типов «частичных представлений», которые могут быть идентифицированы в этом типе носителя. Идентификатор фрагмента имеет смысл только тогда, когда ссылка URI предназначен для поиска, и результатом этого поиска является документ для которого последовательно определяется идентифицированный фрагмент. 4.2. Ссылки на тот же документ Ссылка URI, не содержащая URI, является ссылкой на текущий документ.Другими словами, пустая ссылка URI в документ интерпретируется как ссылка на начало этого документа, а ссылка, содержащая только идентификатор фрагмента, является ссылкой к идентифицированному фрагменту этого документа. Обход такого ссылка не должна приводить к дополнительным действиям по извлечению. Однако, если ссылка URI встречается в контексте, который всегда предназначен для создания нового запроса, как в случае HTML FORM элемент, то пустая ссылка URI представляет базовый URI текущий документ и должен быть заменен этим URI при преобразовании в запрос.4.3. Разбор ссылки URI Ссылка URI обычно анализируется в соответствии с четырьмя основными компоненты и идентификатор фрагмента, чтобы определить, что компоненты присутствуют и является ли ссылка относительной или абсолютный. Затем отдельные компоненты анализируются на предмет их части и, если они не непрозрачны, для проверки их действительности. Хотя BNF определяет, что разрешено в каждом компоненте, это неоднозначный с точки зрения разграничения авторитетного компонента и компонент пути, который начинается с двух символов косой черты.В жадный алгоритм используется для устранения неоднозначности: самое левое соответствие правило впитывает столько ссылочной строки URI, сколько может соответствие. Другими словами, побеждает авторитетная составляющая. Читателям, знакомым с регулярными выражениями, следует ознакомиться с Приложением B. конкретный пример парсинга и тестовый оракул. 5. Относительные ссылки на URI Часто бывает, что группа или «дерево» документов построены для общей цели; подавляющее большинство URI в эти документы указывают на ресурсы в дереве, а не на Бернерс-Ли и др.al. Стандарты Track [стр. 16] RFC 2396 Универсальный синтаксис URI, август 1998 г. вне его. Аналогичным образом документы, расположенные на определенном сайте, гораздо чаще будет ссылаться на другие ресурсы на этом сайте, чем на ресурсы на удаленных сайтах. Относительная адресация URI позволяет деревьям документов быть частично независимо от их расположения и схемы доступа. Например, это возможно одновременное использование одного набора гипертекстовых документов доступны и проходимы через каждый из «file», «http» и «ftp» схемы, если документы ссылаются друг на друга с использованием относительного URI.Кроме того, такие деревья документов можно перемещать целиком без изменение любых относительных ссылок. Опыт работы в WWW продемонстрировал, что способность выполнять относительные ссылки необходимо для долгосрочного использования встроенного URI. Синтаксис относительного URI использует преимущества синтаксиса из (Раздела 3), чтобы выразить ссылку, которая относительно пространства имен другого иерархического URI. relativeURI = (net_path | abs_path | rel_path) [«?» запрос ] Относительная ссылка, начинающаяся с двух символов косой черты, называется ссылка на сетевой путь, как определено в разделе 3.Такой ссылки используются редко. Относительная ссылка, начинающаяся с одного символа косой черты: называется ссылкой на абсолютный путь, как определено в Раздел 3. Относительная ссылка, которая не начинается с имени схемы или Косая черта называется ссылкой на относительный путь. rel_path = rel_segment [abs_path] rel_segment = 1 * (незарезервировано | экранировано | «;» | «@» | «&» | «=» | «+» | «$» | «,») В ссылке относительного пути — полные сегменты пути «.» и «..» имеют особое значение: «текущий уровень иерархии» и » уровень выше этого уровня иерархии «, соответственно. Хотя это очень похоже на их использование в файловых системах на основе Unix для обозначения уровни каталогов, эти компоненты пути считаются только специальными при разрешении ссылки относительного пути к ее абсолютной форме (Раздел 5.2). Авторы должны знать, что сегмент пути, содержащий двоеточие символ не может использоваться в качестве первого сегмента относительного пути URI (е.g., «this: that»), потому что это будет ошибочно принято за название схемы. Бернерс-Ли и др. al. Стандарты Track [стр. 17] RFC 2396 Универсальный синтаксис URI, август 1998 г. Поэтому перед такими сегментами необходимо ставить другие сегменты (например, «./this:that»), чтобы на них можно было ссылаться как относительный путь. Необязательно, чтобы все URI в данной схеме были ограничен синтаксисом, поскольку иерархическая свойства этого синтаксиса необходимы только тогда, когда относительный URI используется в конкретном документе.Документы можно использовать только относительный URI, когда их базовый URI вписывается в синтаксис. Предполагается, что любой документ, содержащий относительную ссылку также будет иметь базовый URI, подчиняющийся синтаксису. Другими словами, относительный URI не может использоваться в документе, который имеет неподходящий базовый URI. Некоторые схемы URI не позволяют использовать иерархический синтаксис, соответствующий синтаксис и, следовательно, не может использовать относительные ссылки. 5.1. Создание базового URI Термин «относительный URI» подразумевает, что существует некая абсолютная «база URI «, к которому применяется относительная ссылка.Действительно, базовый URI необходим для определения семантики любого относительного URI Справка; без него относительная ссылка бессмысленна. В целях чтобы относительный URI можно было использовать в документе, базовый URI этого документ должен быть известен синтаксическому анализатору. Базовый URI документа можно установить одним из четырех способов: перечислены ниже в порядке старшинства. Порядок приоритета может быть мыслится в терминах слоев, где самый внутренний определенный базовый URI имеет высший приоритет.Графически это можно представить как: .————————————————- ———. | .————————————————- —. | | | .———————————————-. | | | | | .—————————————-. | | | | | | | .———————————-. | | | | | | | | | | | | | | | | | | `———————————- ‘| | | | | | | | (5.1.1) Базовый URI, встроенный в | | | | | | | | содержание документа | | | | | | | `—————————————- ‘| | | | | | (5.1.2) Базовый URI инкапсулирующего объекта | | | | | | (сообщение, документ или ничего). | | | | | `———————————————- ‘| | | | (5.1.3) URI, используемый для получения объекта | | | `————————————————- — ‘| | (5.1.4) Базовый URI по умолчанию зависит от приложения | `————————————————- ——— ‘ Бернерс-Ли и др. al. Стандарты Track [стр. 18] RFC 2396 Универсальный синтаксис URI, август 1998 г. 5.1.1. Базовый URI в содержимом документа В определенных типах носителей документа базовый URI документа может быть встроенным в сам контент, чтобы его можно было легко получается парсером. Это может быть полезно для описательных документов, такие как таблицы содержания, которые могут быть переданы другим через протоколы, отличные от их обычного контекста поиска (например,g., электронная почта или Новости USENET). В задачу этого документа не входит определение того, как для каждого тип носителя, можно встроить базовый URI. Предполагается, что пользователь агенты, управляющие такими типами носителей, смогут получить соответствующий синтаксис из спецификации этого типа носителя. Пример о том, как базовый URI может быть встроен в язык гипертекстовой разметки (HTML) [RFC1866] приведен в Приложении D. Механизм встраивания базового URI в типы контейнеров MIME. (е.g., тип сообщения и составной части) определяется MHTML [RFC2110]. Протоколы, которые не используют синтаксис заголовка сообщения MIME, но которые позволяют включать некоторую форму помеченной метаинформации внутри сообщений могут определять свой собственный синтаксис для определения базового URI как часть сообщения. 5.1.2. Базовый URI от инкапсулирующего объекта Если базовый URI не встроен, базовый URI документа определяется как контекст поиска документа. Для документа, который прилагается внутри другого объекта (например, сообщения или другого документа), контекст поиска и есть та сущность; таким образом, базовый URI по умолчанию для документ — это базовый URI объекта, в котором находится документ. инкапсулированный.5.1.3. Базовый URI из полученного URI Если базовый URI не встроен и документ не инкапсулирован внутри некоторого другого объекта (например, верхнего уровня составного объекта), затем, если для получения базового документа использовался URI, этот URI должен считается базовым URI. Обратите внимание, что если извлечение было результат перенаправленного запроса, последний использованный URI (т. е. тот, который привело к фактическому извлечению документа) — это базовый URI. 5.1.4. Базовый URI по умолчанию Если ни одно из условий, описанных в разделах 5.1.1-5.1.3 применяются, тогда базовый URI определяется контекстом приложения. Поскольку это определение обязательно зависит от приложения, в противном случае Бернерс-Ли и др. al. Стандарты Track [стр. 19] RFC 2396 Универсальный синтаксис URI, август 1998 г. определение базового URI с помощью одного из других методов может привести к один и тот же контент по-разному интерпретируется разными типами применение. Это ответственность распространителя (ов) документа. содержащий относительный URI, чтобы гарантировать, что базовый URI для этого документа может быть установлено.Следует подчеркнуть, что относительный URI не может надежно использоваться в ситуациях, когда базовый URI документа не четко определенный. 5.2. Разрешение относительных ссылок на абсолютную форму В этом разделе описан пример алгоритма разрешения URI. ссылки, которые могут относиться к заданному базовому URI. Базовый URI устанавливается в соответствии с правилами Раздела 5.1 и разбирается на четыре основных компонента, как описано в разделе 3. Примечание. что только компонент схемы должен присутствовать в базе URI; другие компоненты могут быть пустыми или неопределенными.Компонент undefined, если его предыдущий разделитель не отображается в URI Справка; компонент пути никогда не бывает неопределенным, хотя он может быть пустой. Компонент запроса базового URI не используется разрешением алгоритм и может быть отброшен. Для каждой ссылки URI по порядку выполняются следующие шаги: 1) Ссылка URI разбирается на четыре потенциальных компонента и идентификатор фрагмента, как описано в разделе 4.3. 2) Если компонент пути пуст, а схема, полномочия и компоненты запроса не определены, то это ссылка на текущий документ, и все готово.В противном случае ссылочный URI компоненты запроса и фрагмента определены как найденные (или не найденные) внутри ссылки URI и не унаследован от базового URI. 3) Если компонент схемы определен, это означает, что ссылка начинается с названия схемы, тогда ссылка интерпретируется как абсолютный URI, и все готово. В противном случае ссылочный URI Схема унаследована от компонента схемы базового URI. Из-за лазейки в предыдущих спецификациях [RFC1630] некоторые синтаксические анализаторы разрешить присутствие имени схемы в относительном URI, если это то же, что и базовая схема URI.К сожалению, это может противоречить с правильным синтаксическим анализом неиерархического URI. В обратном направлении совместимость, реализация может обойти такие ссылки удалив схему, если она совпадает с базовым URI и схема, как известно, всегда использует синтаксис. Парсер Бернерс-Ли и др. al. Стандарты Track [стр. 20] RFC 2396 Универсальный синтаксис URI, август 1998 г. затем можно продолжить, следуя приведенным ниже инструкциям, для оставшейся части справочные компоненты.Проверяющие парсеры должны отмечать такой неверно сформированная относительная ссылка как ошибка. 4) Если компонент полномочий определен, то ссылка является сетевой путь, и мы переходим к шагу 7. В противном случае ссылка Полномочия URI наследуются от полномочий базового URI компонент, который также будет неопределенным, если схема URI не использовать авторитетный компонент. 5) Если компонент пути начинается с косой черты («/»), то ссылка — это абсолютный путь, и мы переходим к шагу 7.6) Если этот шаг достигнут, то мы решаем относительный путь Справка. Относительный путь нужно объединить с базовым Путь URI. Хотя есть много способов сделать это, мы описать простой метод с использованием отдельного строкового буфера. a) Все, кроме последнего сегмента компонента пути базового URI, являются скопировано в буфер. Другими словами, любые символы после последняя (самая правая) косая черта, если таковая имеется, исключается. б) Компонент пути ссылки добавляется в буфер нить.c) Все появления «./», где «.» это полный отрезок пути, удаляются из строки буфера. г) Если строка буфера заканчивается на «.» как полный отрезок пути, тот «.» удален. д) Все вхождения «/../», где — полный сегмент пути, не равный «..», удаляются из буферная строка. Удаление этих сегментов пути выполняется итеративно, удаляя крайний левый совпадающий шаблон на каждом итерация, пока не останется подходящего шаблона.е) Если строка буфера заканчивается на «/ ..», где — это полный отрезок пути, не равный «..», что «/..» удален. g) Если результирующая строка буфера все еще начинается с одного или нескольких полные сегменты пути «..», тогда ссылка считается ошибочным. Реализации могут справиться с этим ошибка, сохранив эти компоненты в разрешенном пути (т. е. обрабатывая их как часть окончательного URI), удаляя их из разрешенный путь (т.е., отбрасывая относительные уровни выше root) или избегая обхода ссылки. Бернерс-Ли и др. al. Standards Track [Страница 21] RFC 2396 Универсальный синтаксис URI, август 1998 г. h) Оставшаяся строка буфера — это новый путь ссылочного URI компонент. 7) Результирующие компоненты URI, включая любые унаследованные от базовый URI, рекомбинируются, чтобы дать абсолютную форму URI Справка. Используя псевдокод, это будет результат = «» если схема определена, то добавить схему к результату добавить «:» к результату если авторитет определен, то добавьте «//» к результату добавить авторитет к результату добавить путь к результату если запрос определен, то добавить «?» в результате добавить запрос к результату если фрагмент определен, то добавьте «#» к результату добавить фрагмент к результату вернуть результат Обратите внимание, что мы должны быть осторожны, чтобы сохранить различие между компонент, который не определен, что означает, что его разделитель не был присутствует в ссылке, а компонент пустой, что означает что разделитель присутствует и сразу за ним следует разделитель следующего компонента или конец ссылки.Вышеупомянутый алгоритм предназначен для того, чтобы предоставить пример, с помощью которого вывод реализаций может быть протестирован — реализация Сам алгоритм не требуется. Например, некоторые системы могут найти более эффективно реализовать шаг 6 как пару стеков сегментов будут объединены, а не как серия замен строковых шаблонов. Примечание. Некоторые клиентские приложения WWW не могут разделить компонент запроса ссылки из его компонента пути перед объединением базовый и опорный пути на шаге 6 выше.Это может привести к потеря информации, если компонент запроса содержит строки «/../» или «/./». Примеры разрешения приведены в Приложении C. Бернерс-Ли и др. al. Стандарты Track [стр. 22] RFC 2396 Универсальный синтаксис URI, август 1998 г. 6. Нормализация и эквивалентность URI Во многих случаях разные строки URI могут фактически идентифицировать идентичный ресурс. Например, имена хостов, используемые в URL, следующие: на самом деле регистр не учитывается, а URL-адрес эквивалентно.В общем, правила для эквивалентность и определение нормальной формы, если таковые имеются, являются схемой зависимый. Когда в схеме используются элементы общего синтаксиса, она будет также используйте общие правила эквивалентности синтаксиса, а именно, что схема и имя хоста не чувствительны к регистру, а URL-адрес с явным «: port», где порт является значением по умолчанию для схемы, эквивалентен одному где порт опущен. 7. Соображения безопасности URI сам по себе не представляет угрозы безопасности. Пользователям следует остерегаться что нет общей гарантии, что URL-адрес, который когда-то обнаружил данный ресурс, будет продолжать это делать.И нет никаких гарантировать, что URL-адрес не найдет другой ресурс в некоторых более поздний момент времени из-за отсутствия каких-либо ограничений на то, как данный власть распределяет свое пространство имен. Такая гарантия может быть только полученный от человека (ов), контролирующего это пространство имен и рассматриваемый ресурс. Конкретная схема URI может включать дополнительные семантика, такая как постоянство имени, если эта семантика требуется всех уполномоченных по присвоению имен для этой схемы. Иногда можно создать такой URL-адрес, чтобы попытка выполнить, казалось бы, безобидную идемпотентную операцию, такую как извлечение объекта, связанного с ресурсом, на самом деле будет вызвать возможное повреждение удаленного управления.Небезопасный URL обычно создается путем указания номера порта, отличного от этого зарезервировано для рассматриваемого сетевого протокола. Клиент невольно связывается с сайтом, на котором на самом деле работает другой протокол. Содержимое URL-адреса содержит инструкции, которые, когда интерпретируется в соответствии с этим другим протоколом, вызывает неожиданное операция. Примером может служить использование URL-адреса gopher, чтобы вызвать непреднамеренное или имитирующее сообщение, отправляемое через SMTP-сервер. Следует проявлять осторожность при использовании любого URL-адреса, который указывает порт. номер, отличный от значения по умолчанию для протокола, особенно когда это число в зарезервированном месте.Следует проявлять осторожность, если URL-адрес содержит экранированные разделители для заданный протокол (например, символы CR и LF для telnet протоколы), что они не отменяются перед передачей. Этот может нарушить протокол, но избегает возможности такого Бернерс-Ли и др. al. Стандарты Track [стр. 23] RFC 2396 Универсальный синтаксис URI, август 1998 г. символы, которые будут использоваться для имитации дополнительной операции или параметра в этот протокол, который может привести к неожиданному и, возможно, вредному удаленное выполнение операции.Совершенно неразумно использовать URL-адрес, содержащий пароль, который предназначено быть секретным. В частности, использование пароля в компонент «userinfo» URL-адреса категорически не рекомендуется, за исключением в тех редких случаях, когда параметр ‘пароль’ предназначен для общественные. 8. Благодарности Этот документ является производным от RFC 1738 [RFC1738] и RFC 1808. [RFC1808]; подтверждения в этих спецификациях по-прежнему остаются в силе. Кроме того, вклад Жизль Аас, Мартина Битта, Мартина Дюрста, Джим Геттис, Мартин Костер, Дэйв Кристол, Даниэль Лалиберте, Foteos Макридес, Джеймс Маршалл, Райан Моутс, Кейт Мур и Лорен Вуд признательны.9. Ссылки [RFC2277] Альвестранд, Х., «Политика IETF в отношении наборов символов и Языки », BCP 18, RFC 2277, январь 1998 г. [RFC1630] Бернерс-Ли, Т., «Универсальные идентификаторы ресурсов в WWW: A Унифицирующий синтаксис для выражения имен и адресов объектов в сети, используемых во всемирной паутине «, RFC 1630, июнь 1994 г. [RFC1738] Бернерс-Ли, Т., Масинтер, Л., и М. МакКахилл, редакторы, «Uniform Resource Locators (URL)», RFC 1738, декабрь 1994 г.[RFC1866] Бернерс-Ли Т. и Д. Коннолли, «Язык разметки гипертекста» Спецификация — 2.0 «, RFC 1866, ноябрь 1995 г. [RFC1123] Брейден Р., редактор, «Требования к хостам Интернета — Применение и поддержка », STD 3, RFC 1123, октябрь 1989 г. [RFC822] Крокер Д., «Стандарт формата Интернет-текста ARPA» Сообщения », STD 11, RFC 822, август 1982 г. [RFC1808] Филдинг, Р., «Относительные унифицированные указатели ресурсов», RFC 1808 г., июнь 1995 г.[RFC2046] Фрид, Н. и Н. Боренштейн, «Многоцелевая интернет-почта. Расширения (MIME), часть вторая: типы носителей », RFC 2046, Ноябрь 1996 г. Бернерс-Ли и др. al. Стандарты Track [стр. 24] RFC 2396 Универсальный синтаксис URI, август 1998 г. [RFC1736] Кунце, Дж., «Функциональные рекомендации для Интернета. Указатели ресурсов «, RFC 1736, февраль 1995 г. [RFC2141] Моутс, Р., «Синтаксис URN», RFC 2141, май 1997 г. [RFC1034] Мокапетрис, П., «Доменные имена — концепции и возможности», STD 13, RFC 1034, ноябрь 1987 г. [RFC2110] Пальме, Дж. И А. Хопманн, «Инкапсуляция электронной почты MIME Сводные документы, такие как HTML (MHTML) », RFC 2110, март 1997 г. [RFC1737] Sollins, K., and L. Masinter, «Функциональные требования для Uniform Resource Names », RFC 1737, декабрь 1994 г. [ASCII] US-ASCII. «Набор кодированных символов — 7-битный американский стандарт Код для обмена информацией », ANSI X3.4-1986. [UTF-8] Йерго, Ф., «UTF-8, формат преобразования ISO 10646», RFC 2279, январь 1998 г. Бернерс-Ли и др. al. Стандарты Track [Страница 25] RFC 2396 Универсальный синтаксис URI, август 1998 г. 10. Адреса авторов. Тим Бернерс-Ли Консорциум World Wide Web Лаборатория компьютерных наук Массачусетского технологического института, NE43-356 545 Площадь Технологий Кембридж, Массачусетс 02139 Факс: +1(617)258-8682 Электронная почта: timbl @ w3.org Рой Т. Филдинг Департамент информации и компьютерных наук Калифорнийский университет в Ирвине Ирвин, Калифорния 92697-3425 Факс: +1(949)824-1715 Электронная почта: [email protected] Ларри Масинтер Xerox PARC 3333 Coyote Hill Road Пало-Альто, Калифорния 94034 Факс: +1(415)812-4333 Электронная почта: [email protected] Бернерс-Ли и др. al. Стандарты Track [стр. 26] RFC 2396 Универсальный синтаксис URI, август 1998 г. А.Собран BNF для URI URI-ссылка = [absoluteURI | relativeURI] [фрагмент «#»] absoluteURI = схема «:» (hier_part | opaque_part) relativeURI = (net_path | abs_path | rel_path) [«?» запрос ] hier_part = (net_path | abs_path) [«?» запрос ] opaque_part = uric_no_slash * uric uric_no_slash = незарезервировано | сбежал | «;» | «?» | «:» | «@» | «&» | «=» | «+» | «$» | «,» net_path = «//» авторитет [abs_path] abs_path = «/» path_segments rel_path = rel_segment [abs_path] rel_segment = 1 * (незарезервировано | экранировано | «;» | «@» | «&» | «=» | «+» | «$» | «,») схема = альфа * (альфа | цифра | «+» | «-» | «.») авторитет = сервер | reg_name reg_name = 1 * (незарезервировано | экранировано | «$» | «,» | «;» | «:» | «@» | «&» | «=» | «+») server = [[userinfo «@»] hostport] userinfo = * (незарезервировано | экранировано | «;» | «:» | «&» | «=» | «+» | «$» | «,») hostport = host [«:» порт] host = hostname | IPv4адрес hostname = * (domainlabel «.») toplabel [«.» ] domainlabel = alphanum | alphanum * (alphanum | «-«) alphanum toplabel = alpha | альфа * (alphanum | «-«) alphanum IPv4address = 1 * цифра «.«1 * цифра». «1 * цифра». «1 * цифра порт = * цифра путь = [abs_path | непрозрачная_часть] path_segments = сегмент * (сегмент «/») сегмент = * pchar * («;» параметр) param = * pchar pchar = незарезервировано | сбежал | «:» | «@» | «&» | «=» | «+» | «$» | «,» query = * uric фрагмент = * урик Бернерс-Ли и др. al. Стандарты Track [стр. 27] RFC 2396 Универсальный синтаксис URI, август 1998 г. uric = зарезервировано | безоговорочно | сбежал зарезервировано = «;» | «/» | «?» | «:» | «@» | «&» | «=» | «+» | «$» | «,» unreserved = буквенный | отметка mark = «-» | «_» | «.»|»! «|» ~ «|» * «|» ‘»| «(» | «)» escaped = «%» шестнадцатеричный шестнадцатеричный = цифра | «А» | «Б» | «C» | «Д» | «E» | «F» | «а» | «б» | «с» | «д» | «е» | «е» алфавит = альфа | цифра альфа = низкая альфа | Упальфа lowalpha = «а» | «б» | «с» | «д» | «е» | «е» | «г» | «h» | «я» | «j» | «к» | «л» | «м» | «п» | «о» | «р» | «q» | «г» | «s» | «т» | «u» | «v» | «ш» | «х» | «у» | «z» upalpha = «А» | «Б» | «C» | «Д» | «E» | «F» | «G» | «H» | «Я» | «J» | «К» | «L» | «М» | «N» | «О» | «П» | «Q» | «R» | «S» | «Т» | «U» | «V» | «W» | «Х» | «Y» | «Z» цифра = «0» | «1» | «2» | «3» | «4» | «5» | «6» | «7» | «8» | «9» Бернерс-Ли и др.al. Стандарты Track [стр. 28] RFC 2396 Универсальный синтаксис URI, август 1998 г. Б. Анализ ссылки URI с помощью регулярного выражения Как описано в Разделе 4.3, универсального синтаксиса URI недостаточно. для устранения неоднозначности компонентов некоторых форм URI. Поскольку «жадный алгоритм», описанный в этом разделе, идентичен метод устранения неоднозначности, используемый регулярными выражениями POSIX, это естественно и банально использовать регулярное выражение для разбора возможные четыре компонента и идентификатор фрагмента ссылки URI.#] *))? (# (. *))? 12 3 4 5 6 7 8 9 Цифры во второй строке выше предназначены только для облегчения чтения; они указывают опорные точки для каждого подвыражения (т. е. каждого парные скобки). Мы ссылаемся на значение, соответствующее подвыражению как $. Например, сопоставление приведенного выше выражения с http://www.ics.uci.edu/pub/ietf/uri/#Related приводит к следующим совпадениям подвыражения: $ 1 = http: $ 2 = http $ 3 = // www.ics.uci.edu 4 доллара = www.ics.uci.edu 5 долларов = / pub / ietf / uri / 6 долларов = 7 долларов = $ 8 = # Связано $ 9 = Связанные где означает, что компонент отсутствует, как и случай для компонента запроса в приведенном выше примере. Поэтому мы можно определить значение четырех компонентов и фрагмента как схема = 2 $ авторитет = 4 доллара путь = 5 долларов США query = 7 долларов США фрагмент = 9 $ и, идя в противоположном направлении, мы можем воссоздать ссылку URI из его компонентов, используя алгоритм из шага 7 раздела 5.2. Бернерс-Ли и др. al. Стандарты Track [стр. 29] RFC 2396 Универсальный синтаксис URI, август 1998 г. C. Примеры разрешения относительных ссылок URI Внутри объекта с четко определенным базовым URI http: // a / b / c / d; p? q относительный URI будет разрешен следующим образом: С.1. Нормальные примеры г: ч = г: ч g = http: // a / b / c / g ./g = http: // a / b / c / g g / = http: // a / b / c / g / / g = http: // a / g // г = http: // г ? y = http: // a / b / c /? y g? y = http: // a / b / c / g? y #s = (текущий документ) #s g # s = http: // a / b / c / g # s g? y # s = http: // a / b / c / g? y # s ; x = http: // a / b / c /; x g; x = http: // a / b / c / g; x g; x? y # s = http: // a / b / c / g; x? y # s .= http: // a / b / c / ./ = http: // a / b / c / .. = http: // a / b / ../ = http: // a / b / ../g = http: // a / b / g ../ .. = http: // a / ../../ = http: // a / ../../g = http: // a / g С.2. Аномальные примеры Хотя следующие аномальные примеры маловероятны в обычная практика, все парсеры URI должны уметь их разрешать последовательно. В каждом примере используется та же основа, что и выше. Пустая ссылка относится к началу текущего документа.= (текущий документ) Парсеры должны быть осторожны в случае, если есть больше относительный путь «..» сегментов, чем иерархических уровней в путь базового URI. Обратите внимание, что синтаксис «..» нельзя использовать для изменения авторитетный компонент URI. Бернерс-Ли и др. al. Standards Track [Страница 30] RFC 2396 Универсальный синтаксис URI, август 1998 г. ../../../g = http: //a/../g ../../../ ../ g = http: //a/../../g На практике некоторые реализации удаляют начальные относительные символические символы. элементы («.», «..») после применения вычисления относительного URI на основе по теории, что лучше компенсировать очевидные ошибки автора чем позволить запросу потерпеть неудачу. Таким образом, две приведенные выше ссылки будет интерпретироваться некоторыми реализациями как «http: // a / g». Точно так же синтаксические анализаторы должны избегать обработки «.» и «..» как особенное, когда они не являются полными компонентами относительного пути. /./ g = http: //a/./g /../g = http: //a/../g г. = http: // a / b / c / g. .g = http: //a/b/c/.g g .. = http: // a / b / c / g .. ..g = http: //a/b/c/..g Менее вероятны случаи, когда относительный URI использует ненужные или бессмысленные формы символа «.» и «..» полные сегменты пути. ./../g = http: // a / b / g ./г/. = http: // a / b / c / g / g /./ h = http: // a / b / c / g / h g /../ h = http: // a / b / c / h г; х = 1 /./ y = http: // a / b / c / g; x = 1 / y g; x = 1 /../ y = http: // a / b / c / y Все клиентские приложения удаляют компонент запроса из базового URI перед разрешением относительного URI. Однако некоторые приложения не могут отделить ссылочный запрос и / или компоненты фрагмента от относительный путь перед объединением его с базовым путем. Эта ошибка редко замечают, поскольку типичное использование фрагмента никогда не включает иерархии («/»), и компонент запроса обычно не используется в относительных ссылках.g? y /./ x = http: // a / b / c / g? y /./ x g? y /../ x = http: // a / b / c / g? y /../ x g # s /./ x = http: //a/b/c/g#s/./x g # s /../ x = http: //a/b/c/g#s/../x Бернерс-Ли и др. al. Стандарты Track [стр. 31] RFC 2396 Универсальный синтаксис URI, август 1998 г. Некоторые парсеры позволяют использовать имя схемы в относительном URI, если это то же самое, что и базовая схема URI. Это считается лазейка в предыдущих спецификациях частичного URI [RFC1630].Его использование следует избегать. http: g = http: g; для проверки парсеров | http: // a / b / c / g; для обратной совместимости Бернерс-Ли и др. al. Стандарты Track [стр. 32] RFC 2396 Универсальный синтаксис URI, август 1998 г. D. Встраивание базового URI в HTML-документы Полезно рассмотреть пример того, как базовый URI документа могут быть встроены в содержимое документа.В этом приложении мы описывать, как документы написаны на языке гипертекстовой разметки (HTML) [RFC1866] может включать встроенный базовый URI. Это приложение не является частью спецификации URI и не должен быть рассматривается как нечто большее, чем описательный пример. HTML определяет специальный элемент «BASE», который, если он присутствует в «HEAD» часть документа сигнализирует, что синтаксический анализатор должен использовать Атрибут «HREF» элемента BASE в качестве базового URI для разрешения любых относительный URI.Атрибут «HREF» должен быть абсолютным URI. Примечание что в HTML имена элементов и атрибутов нечувствительны к регистру. Для пример: Пример HTML-документа … гипертекстовый якорь … Анализатор, читающий пример документа, должен интерпретировать данный относительный URI «../x» как представляющий абсолютный URI независимо от контекста, в котором был получен образец документа. Бернерс-Ли и др. al. Стандарты Track [стр. 33] RFC 2396 Универсальный синтаксис URI, август 1998 г. Э.Рекомендации по разграничению URI в контексте URI часто передаются в форматах, не обеспечивающих четкого контекст для их интерпретации. Например, есть много случаи, когда URI включаются в обычный текст; примеры включают текст отправлено по электронной почте, новостным сообщениям USENET и, что наиболее важно, напечатаны на бумаге. В таких случаях важно уметь отделять URI от остального текста и, в частности, от знаки препинания, которые могут быть ошибочно приняты за часть URI.На практике URI разграничиваются разными способами, но обычно в двойных кавычках «http://test.com/», угловые скобки , или просто используя пробел http://test.com/ Эти оболочки не являются частью URI. В случае, когда идентификатор фрагмента связан с URI ссылка, фрагмент также будет помещен в скобки (отделяется от URI символом «#»). В некоторых случаях лишние пробелы (пробелы, разрывы строк, табуляции и т. Д.) май необходимо добавить, чтобы разбить длинный URI на строки. Пробел следует игнорировать при извлечении URI. После символа дефиса («-«) не должно быть пробелов. Поскольку некоторые наборщики и принтеры могут (ошибочно) вводить дефис в конце строки при разрыве строки, интерпретатор URI, содержащий разрыв строки сразу после дефиса, следует игнорировать все неэкранированные пробелы вокруг разрыва строки, и следует помнить что дефис может быть, а может и не быть частью URI.Особенно рекомендуется использовать угловые скобки вокруг каждого URI, поскольку стиль разделителей для URI, содержащих пробелы. Рекомендуется использовать префикс «URL:» (с пробелом в конце или без него). как способ отличить URL от других заключенных в квадратные скобки позиционные обозначения, хотя на практике это не является обычным явлением. Для надежности программное обеспечение, которое принимает вводимый пользователем URI, должно пытаться для распознавания и удаления разделителей и встроенных пробелов. Например, текст: Бернерс-Ли и др.al. Стандарты Track [стр. 34] RFC 2396 Универсальный синтаксис URI, август 1998 г. Да, Джим, я нашел его по адресу «http://www.w3.org/Addressing/», но вы, вероятно, можете забрать его из. Обратите внимание на предупреждение в. содержит ссылки URI http://www.w3.org/Addressing/ ftp://ds.internic.net/rfc/ http://www.ics.uci.edu/pub/ietf/uri/historical.html#WARNING Бернерс-Ли и др. al. Стандарты Track [стр. 35] RFC 2396 Универсальный синтаксис URI, август 1998 г. Ф.Сокращенные URL Синтаксис URL-адреса был разработан для однозначной ссылки на сеть ресурсы и расширяемость через схему URL. Однако, поскольку URL идентификация и использование стали обычным явлением, традиционные средства массовой информации (телевидение, радио, газеты, рекламные щиты и т. д.) использовались сокращенные URL-ссылки. То есть ссылка, состоящая из только части полномочий и пути идентифицированного ресурса, такие в виде www.w3.org/Addressing/ или просто имя хоста DNS.Такие ссылки в первую очередь предназначенный для интерпретации человеком, а не машиной, с предположение, что контекстная эвристика достаточна для завершения URL-адрес (например, большинство имен хостов, начинающихся с «www», скорее всего, будут иметь префикс URL «http: //»). Хотя стандартного набора эвристика для устранения неоднозначности сокращенных URL-ссылок, многие клиенты реализации позволяют вводить их пользователем и эвристически разрешено. Следует отметить, что такая эвристика может со временем меняются, особенно когда вводятся новые схемы URL.Поскольку сокращенный URL-адрес имеет тот же синтаксис, что и относительный URL-путь, сокращенные ссылки URL не могут использоваться в контекстах, где относительные Ожидаются URL-адреса. Это ограничивает использование сокращенных URL-адресов местами где нет определенного базового URL-адреса, например диалоговых окон и автономных реклама. Бернерс-Ли и др. al. Стандарты Track [стр. 36] RFC 2396 Универсальный синтаксис URI, август 1998 г. Ж. Сводка нередакционных изменений Г.1. Дополнения Раздел 4 (Ссылки URI) был добавлен, чтобы избежать путаницы в отношении «что такое URI» и как описывать идентификаторы фрагментов, учитывая, что они не являются частью URI, но являются частью синтаксиса URI и анализ проблем. Кроме того, он дает справочное определение для использования другими спецификациями IETF (HTML, HTTP и т. д.), которые имеют ранее пытались переопределить синтаксис URI, чтобы учесть на наличие идентификаторов фрагментов в ссылках URI. Раздел 2.4 был переписан, чтобы прояснить ряд неверных интерпретаций. и оставить место для полностью интернационализированного URI. Приложение F о сокращенных URL-адресах было добавлено для описания сокращенных ссылки, которые часто можно увидеть в рекламе на телевидении и в журналах, и объясните, почему они не используются в других контекстах. G.2. Изменения как из RFC 1738, так и из RFC 1808 Изменен синтаксис URI, а не только URL. Путаница относительно терминов «кодировка символов», URI «набор символов» и экранирование символов с помощью% эквиваленты (надеюсь) были сокращены.Многие из названий правил BNF относительно наборов символов были изменены на более точные описать их цель и охватить всех «персонажей», а не только октеты US-ASCII. Если здесь не указано иное, эти модификации не влияют на синтаксис URI. И RFC 1738, и RFC 1808 относятся к «зарезервированному» набору символов. как если бы программное обеспечение для интерпретации URI было ограничено одним набором символы с зарезервированной целью (т. е. означающие что-то другое чем данные, которым соответствуют символы), и что этот набор было исправлено схемой URI.Однако это не было правдой в упражняться; любой символ, который интерпретируется по-другому, когда он escaped фактически зарезервировано. Кроме того, интерпретация движок на HTTP-сервере часто зависит от ресурса, а не только схема URI. Описание зарезервированных символов было соответственно изменился. Добавлены символы плюса «+», доллара «$» и запятой «,» те, что находятся в «зарезервированном» наборе, поскольку они рассматриваются как зарезервированные в компоненте запроса.Бернерс-Ли и др. al. Стандарты Track [стр. 37] RFC 2396 Универсальный синтаксис URI, август 1998 г. Символ тильды «~» был добавлен к тем, что в наборе «unreserved», поскольку он широко используется в Интернете, несмотря на трудности с его расшифровкой с помощью некоторых клавиатур. Синтаксис схемы URI был изменен, чтобы требовать, чтобы все схемы начинаются с буквенного символа. Форма «пользователь: пароль» в предыдущем BNF была изменена на токен «userinfo» и возможность того, что это может быть «пользователь: пароль» делает схему конкретной.В частности, использование пароли в открытом виде даже не подсказывает синтаксис. Знак вопроса «?» персонаж был удален из набора разрешенных символы для информации о пользователе в компоненте полномочий, так как тестирование показал, что многие приложения рассматривают его как зарезервированный для разделения компонент запроса из остальной части URI. Точка с запятой «;» персонаж был добавлен к тем, которые заявлены как зарезервировано внутри компонента полномочий, поскольку несколько новых схем используют его как разделитель в пользовательской информации, чтобы указать тип аутентификация пользователя.RFC 1738 указал, что путь был отделен от полномочий часть URI с помощью косой черты. RFC 1808 последовал его примеру, но с выдумка носить с собой разделитель в качестве «префикса», чтобы описать алгоритм разбора. RFC 1630 никогда не имел этой проблемы, поскольку он считал косую черту частью пути. На письме этой спецификации оказалось невозможным точно описать и сохранить разницу между двумя URI и не считая косую черту частью пути (как соответствует реальной практике) или создание отдельного компонента просто удерживать косую черту.Мы выбрали первое. G.3. Изменения из RFC 1738 Определение конкретных схем URL и их конкретных схем синтаксис и семантика вынесены в отдельные документы. Хост URL был определен как полное доменное имя. Однако, многие URL-адреса используются без полных доменных имен (в контекстах для которых полная квалификация не требуется), без какого-либо хоста (как в некоторых URL-адресах файлов) или с хостом «localhost». Порт URL-адреса теперь * цифра вместо 1 * цифры, поскольку системы ожидается, что он будет обрабатывать случай, когда разделитель «:» между хостом и порт поставляется без порта.Бернерс-Ли и др. al. Стандарты Track [стр. 38] RFC 2396 Универсальный синтаксис URI, август 1998 г. Рекомендации по разграничению URI в контексте (Приложение E) имеют были скорректированы с учетом текущей практики. G.4. Изменения из RFC 1808 RFC 1808 (раздел 4) определил пустой URL-адрес (ссылка не содержащий ничего, кроме идентификатора фрагмента) как ссылка на базовый URL. К сожалению, это определение могло быть интерпретируется при выборе такой ссылки как новый поиск действие на этом ресурсе.Поскольку обычное намерение таких ссылок для пользовательского агента, чтобы изменить свой вид текущего документа на начало указанного фрагмента в этом документе, а не сделать дополнительный запрос ресурса, описание как правильно интерпретировать пустую ссылку было добавлено в разделе 4. Заменено описание мифического поля заголовка Base. со ссылкой на поле заголовка Content-Location, определенное MHTML [RFC2110]. RFC 1808 описывает различные схемы как имеющие или не имеющие свойства универсального синтаксиса URI.Однако единственное требование заключается в том, что конкретный документ, содержащий относительные ссылки иметь базовый URI, который соответствует синтаксису универсального URI, независимо от схема URI, поэтому связанное описание было обновлено до отражать это. Термин BNF был заменен на, поскольку последний более точно описывает его использование и назначение. Точно так же полномочия больше не ограничиваются синтаксисом IP-сервера. Обширное тестирование текущих клиентских приложений продемонстрировало, что в большинстве развернутых систем символ «;» не используется. характер для указывают информацию о конечных параметрах, и что наличие точка с запятой в сегменте пути не влияет на относительный анализ этот сегмент.Поэтому параметры были удалены как отдельный компонент и теперь может появиться в любом сегменте пути. Их влияние был удален из алгоритма разрешения относительного URI Справка. Примеры разрешения в Приложении C были изменены. чтобы отразить это изменение. Реализациям теперь разрешено обходить неверно сформированный относительный ссылки с префиксом по той же схеме, что и базовый URI, но только для схем, в которых известен синтаксис. Бернерс-Ли и др.al. Стандарты Track [стр. 39] RFC 2396 Универсальный синтаксис URI, август 1998 г. H. Полное заявление об авторских правах Авторское право (C) The Internet Society (1998). Все права защищены. Этот документ и его переводы могут быть скопированы и предоставлены другие и производные работы, которые комментируют или иным образом объясняют это или помочь в его реализации могут быть подготовлены, скопированы, опубликованы и распространяется, полностью или частично, без ограничения каких-либо любезно, при условии, что указанное выше уведомление об авторских правах и этот абзац являются включены во все такие копии и производные работы.Однако это сам документ не может быть изменен каким-либо образом, например, путем удаления уведомление об авторских правах или ссылки на Internet Society или другие Интернет-организации, за исключением случаев, когда это необходимо для разработки Интернет-стандартов, в этом случае процедуры для авторские права, определенные в процессе разработки стандартов Интернета, должны быть следовать, или, если требуется, перевести его на другие языки, кроме Английский. Ограниченные разрешения, предоставленные выше, являются бессрочными и не будут аннулировано Интернет-сообществом, его правопреемниками или правопреемниками.Этот документ и содержащаяся в нем информация размещены на Основа «КАК ЕСТЬ» и ИНТЕРНЕТ-ОБЩЕСТВО И ИНТЕРНЕТ-ИНЖИНИРИНГ TASK FORCE ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ НО НЕ ОГРАНИЧИВАЕТСЯ НИКАКОЙ ГАРАНТИЕЙ, ЧТО ИСПОЛЬЗОВАНИЕ ИНФОРМАЦИИ ЗДЕСЬ НЕ НАРУШАЕТ НИКАКИХ ПРАВ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ КОММЕРЧЕСКАЯ ЦЕННОСТЬ ИЛИ ПРИГОДНОСТЬ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ. Бернерс-Ли и др. al. Стандарты Track [стр. 40]

Разница между URL-адресом и URI

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

Протокол описан в URL-адресе, который используется для получения ресурса и имени ресурса. URL-адрес содержит http / https в начале, если ресурс может быть ресурсом веб-типа. Точно так же он начинается с ftp, если ресурс может быть файлом, и mailto, если ресурс является адресом электронной почты.Синтаксис URL-адреса показан ниже, где основная часть используется для протокола, а оставшаяся часть используется для ресурса, который состоит из имени веб-сайта или имени программы.

 https://www.geeksforgeeks.org/minimum-cost-graph

Здесь имя домена описывает сервер (веб-службу) и имя программы (путь к каталогу и файлу на сервере).

URI (унифицированный идентификатор ресурса):
Подобно URL-адресу, URI (унифицированный идентификатор ресурса) также представляет собой строку символов, которая идентифицирует ресурс в Интернете по местоположению, имени или обоим.Это позволяет единообразно идентифицировать ресурсы. URI дополнительно группируется как указатель, имя или и то, и другое, что предполагает, что он может описывать URL, URN или и то, и другое. Термин «идентификатор» в URI относится к значимости ресурсов, несмотря на используемый метод.

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

Разница между URL и URI:

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

Вниманию читателя! Не прекращайте учиться сейчас. Получите все важные концепции теории CS для собеседований SDE с помощью курса CS Theory Course по приемлемой для студентов цене и будьте готовы к работе в отрасли.

Основы работы в сети: в чем разница между URI, URL и URN?

Если вы работаете в Интернете или зарабатываете на жизнь сетевым подключением, вы обязательно встретите аббревиатуры — URI, URL, возможно, даже URN. Бывают случаи, когда эти термины используются как синонимы.

Итак, есть ли разница между этими терминами?

Ну да. Иначе зачем было бы использовать три разных термина для описания одного и того же? Описание различий — это совсем другое дело, но есть простой способ взглянуть на это.

Давайте определим URI, URL-адреса и URN

Подписки и ресурсы Azure

Связанное обучение от CBT Nuggets

URI (унифицированный идентификатор ресурса) — это последовательность символов, которая идентифицирует логический или физический ресурс. Существует два типа URI: универсальные указатели ресурсов (URL) и универсальные имена ресурсов (URN).

Все три из них предназначены для ссылки на некоторый сетевой ресурс, будь то статическая веб-страница HTML или документ PDF.Эти условия создают единый способ ссылки на имя, местонахождение или и то, и другое этого ресурса. Для построения информационных сетей необходим единый способ называть и находить ресурс. Для отдельных ресурсов это назначение URI, URN или URL.

Каждый URL-адрес — это URI. Все URL-адреса являются URI, но не все URI являются URL-адресами.

URI — это обозначение, которое служит наиболее общим способом ссылки на сетевой ресурс. URI — это идентификатор.URL-адрес — это местоположение.

Согласно RFC, URL объединяет имя и метод доступа.

Например, попробуем найти книгу в библиотеке. Давайте найдем классический Gone with the Wind . Название идентифицирует книгу (или ресурс), но как вы его нашли? Вы идете в компьютер-справочник, чтобы найти десятичное число Дьюи. Поскольку число Дьюи указывает, где искать заголовок, он похож на URL-адрес.

Итак, URI не сообщает вам, как найти ресурс.Это общий идентификатор (название книги).

URL-адрес — это местоположение, например десятичное число Дьюи. В URL-адресах есть заголовок и префикс протокола, который обеспечивает метод доступа. Вы, возможно, знаете различные механизмы доступа, включая https: //, mailto: или ftp: //. Таким образом, у нас есть полный путь к поиску этого ресурса. Вся эта строка служит для однозначной идентификации имени и местоположения этого объекта в сети.

Есть много мест, где вы можете найти более подробное определение этих терминов.Вы можете сразу перейти к исходным документам, которые впервые обнаружат их в Консорциуме World Wide Web (W3C). Вы также можете проверить библиотеки запроса комментариев (RFC) в IETF.

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

Что такое URN?

Люди часто описывают URI и URN с помощью имени. Возьмем, к примеру, имя человека, например Джо Смит. Это имя может служить чем-то вроде URI, поскольку оно идентифицирует человека.Но он не говорит вам, где именно на этом земном шаре найти конкретного Джо Смита. Или даже о том, о каком Джо Смит мы говорим.

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

В сети URN легко обнаружить. Обычно они формируются так:

urn: oasis: names: спецификация: docbook: dtd: xml: 4.1.2

Заключение

Подводя итог, URI являются идентификаторами, и это может означать либо имя, либо местоположение, либо и то, и другое. Все URN и URL технически также являются URI, но обратное неверно. Часть, которая делает что-то URL-адресом, представляет собой комбинацию имени и способа доступа к нему, например https: // или mailto :.

Все эти биты являются URI, так что это всегда технически верно. Но если вы обсуждаете что-то, что является одновременно полным URL-адресом и URI (каковыми являются все URL-адреса), лучше всего называть это «URL-адресом», потому что он более конкретен.

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

Кейт Баркер может подробнее узнать об этих условиях здесь:

Скачать

Не являетесь подписчиком CBT Nuggets? Начни бесплатную неделю прямо сейчас.

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