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

Привет хабр!

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

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

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

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

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

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

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

ОГЛАВЛЕНИЕ

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

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

1. URI

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

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

Например:

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

В современном интернете, чаще всего используется две разновидности 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, эта компонента служит непосредственно для передачи каких-либо данных.
  Разрешенные символы:
  

  латинские буквы, цифры, процентно-кодированные, "(", ")", "+", ",", "-", ".", ":", "=", "@", ";", "$", "_", "!", "*", "'"

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

  "%", "/", "?", "#"

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

  октеты 0-32 (0-20 hex), "\", """, "&", "<", ">", "[", "]", "^", "`", "{", "|", "}", "~", октеты 127-255 (7F-FF hex)

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

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

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

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

habr.com

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

Пост из серии: всегда хотел это понять, но значимость его была настолько мала, что всегда находился повод этого не делать 🙂

А вы задавались вопросом: URL — что это?

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

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

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

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

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

Определение

URI: Обозначает имя и адрес ресурса в сети. Как правило, делится на URL и URN, поэтому URL и URN это составляющие URI.
URL: Адрес некоторого ресурса в веб. URL определяет местонахождение ресурса и способ обращения к нему.
URN: Имя некоторого ресурса в веб. Смысл URN в том, что он определяет только название конкретного предмета, который может находится во множестве конкретных мест.

Итак, мы можем считать, что:
URI = URL или URI = URN или URI = URL + URN

Нет ничего лучше, чем конкретный пример

URI = http://handynotes.ru/2009/09/uri-url-urn.html
URL = http://handynotes.ru
URN = /2009/09/uri-url-urn.html

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

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

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

handynotes.ru

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 вышеуказанных групп шаблона дадут следующие результаты соответственно:

1. http:
2. http
3. //www.ics.uci.edu
4. www.ics.uci.edu
5. /pub/ietf/uri/
6. нет результата
7. нет результата
8. #Related
9. 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 дней]}

См. также

Ссылки

Примечания

dic.academic.ru

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

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

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

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

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

URI

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

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

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

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

URL

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

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

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

URN

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

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

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

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

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

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

habr.com

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

Разбор структуры 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 вышеуказанных групп шаблона дадут следующие результаты соответственно:

1. http:
2. http
3. //www.ics.uci.edu
4. www.ics.uci.edu
5. /pub/ietf/uri/
6. нет результата
7. нет результата
8. #Related
9. Related

Отличие URI от URL

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

Примеры 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%fg%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
[пустая строка]

См. также

Ссылки

Примечания

1. ↑ Рекомендуется в RFC 3986.

dic.academic.ru

URI — Википедия. Что такое URI

URI (/ˌjuː ɑːr ˈaɪ/ англ. Uniform Resource Identifier) — унифицированный (единообразный) идентификатор ресурса. По-русски иногда говорят [у́ри]. URI — последовательность символов, идентифицирующая абстрактный или физический ресурс. Ранее назывался Universal Resource Identifier — универсальный идентификатор ресурса.

Основы

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 с символами Юникода. Например, строка вида:

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

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

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

Поскольку такому преобразованию подвергаются буквы всех алфавитов, кроме используемой в английском языке латиницы, то URI со словами на других языках (даже европейских) утрачивают способность восприниматься людьми. А это входит в грубое противоречие с принципом интернационализма, провозглашаемого всеми ведущими организациями Интернета, включая W3C и ISOC. Эту проблему призван решить стандарт IRI (англ. Internationalized 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 в стандарте RFC 3986 рекомендуется использовать следующий шаблон:

^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
 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 вышеуказанных групп шаблона дадут следующие результаты соответственно:

1. http:
2. http
3. //www.ics.uci.edu
4. www.ics.uci.edu
5. /pub/ietf/uri/
6. нет результата
7. нет результата
8. #Related
9. Related

Примеры URI

Абсолютные URI

• https://ru.wikipedia.org/wikipedia/URI
• ftp://ftp.is.co.za/rfc/rfc1808.txt
• file://C:\UserName.HostName\Projects\Wikipedia_Articles\URI.xml
• file:///C:/file.wsdl
• file:///Users/John/Documents/Projects/Web/MyWebsite/about.html
• 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%be%be
• tel:+1-816-555-1212
• telnet://192.0.2.16:80/
• urn:oasis:names:specification:docbook:dtd:xml:4.1.2
• urn:oid:1.2.840.113549.1.1.1

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

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

//example.org/scheme-relative/URI/with/absolute/path/to/resource.txt

relative/path/to/resource.txt

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

resource.txt

/resource.txt#frag01

#frag01

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

См. также

Ссылки

wiki.sc

uri Википедия

URI (/ˌjuː ɑːr ˈaɪ/ англ. Uniform Resource Identifier) — унифицированный (единообразный) идентификатор ресурса. По-русски иногда говорят [у́ри]. URI — последовательность символов, идентифицирующая абстрактный или физический ресурс. Ранее назывался Universal Resource Identifier — универсальный идентификатор ресурса.

Основы[ | ]

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 регули

ru-wiki.ru