Унифицированный идентификатор ресурса ( URI ) представляет собой уникальную последовательность символов , которая идентифицирует логический или физический ресурс , используемый веб - технологий. URI могут использоваться для идентификации чего угодно, включая объекты реального мира, такие как люди и места, концепции или информационные ресурсы, такие как веб-страницы и книги. Некоторые URI предоставляют средства поиска и извлечения информационных ресурсов в сети (либо в Интернете, либо в другой частной сети, такой как компьютерная файловая система или интранет), это универсальные указатели ресурсов.(URL-адреса). URL-адрес указывает расположение ресурса. URI идентифицирует ресурс по имени в указанном месте или URL-адресе. Другие URI предоставляют только уникальное имя, без возможности поиска или извлечения ресурса или информации о нем, это универсальные имена ресурсов (URN). Веб-технологии, использующие URI, не ограничиваются веб-браузерами. URI используются для идентификации всего, что описано с помощью Resource Description Framework (RDF), например, концепции, которые являются частью онтологии, определенной с помощью языка веб-онтологий (OWL), и люди, описанные с использованием словаря Friend of a Friend, будут каждый иметь индивидуальный URI.
Домен | Всемирная сеть |
---|---|
Сокращение | URI |
История
Зачатие
URI и URL имеют общую историю. В 1990 году предложения Тима Бернерса-Ли относительно гипертекста неявно вводили идею URL-адреса как короткой строки, представляющей ресурс, являющийся целью гиперссылки . [1] В то время люди называли это «гипертекстовым именем» [2] или «названием документа».
В течение следующих трех с половиной лет, по мере развития основных технологий Всемирной паутины, таких как HTML, HTTP и веб-браузеры, возникла необходимость отличать строку, предоставляющую адрес для ресурса, от строки, которая просто называет ресурс. Хотя формально он еще не определен, термин Uniform Resource Locator стал обозначать первое, а более спорное Uniform Resource Name стало представлять второе.
Во время дебатов по поводу определения URL-адресов и URN стало очевидно, что концепции, воплощенные в этих двух терминах, были просто аспектами фундаментального, всеобъемлющего понятия идентификации ресурсов . В июне 1994 года IETF опубликовала первый запрос Бернерса-Ли на комментарии, в котором признавалось существование URL-адресов и URN. Что наиболее важно, он определил формальный синтаксис для универсальных идентификаторов ресурсов (т. Е. URL-подобных строк, точный синтаксис и семантика которых зависели от их схем). Кроме того, RFC 1630 попытался обобщить синтаксис схем URL, используемых в то время. Он признал - но не стандартизировал - существование относительных URL-адресов и идентификаторов фрагментов. [3]
Уточнение
В декабре 1994 г. RFC 1738 формально определил относительные и абсолютные URL-адреса, уточнил общий синтаксис URL-адресов, определил, как преобразовать относительные URL-адреса в абсолютную форму, и более точно перечислил используемые в то время схемы URL-адресов. [4] Согласованное определение и синтаксис URN пришлось ждать до публикации IETF RFC 2141 [5] в мае 1997 года.
В публикации IETF RFC 2396 [6] в августе 1998 года синтаксис URI стал отдельной спецификацией [7], а большинство частей RFC 1630 и 1738, относящихся к URI и URL в целом, были пересмотрены и расширены IETF . Новый RFC изменил значение «U» в «URI» на «Uniform» с «Universal».
В декабре 1999 г. RFC 2732 [8] предоставил незначительное обновление RFC 2396, позволяя URI использовать адреса IPv6 . Ряд недостатков, обнаруженных в этих двух спецификациях, привел к усилиям сообщества, координировавшимся соавтором RFC 2396 Роем Филдингом , которые завершились публикацией IETF RFC 3986 [9] в январе 2005 года. сделать детали существующих схем URL устаревшими; RFC 1738 продолжает управлять такими схемами, если иное не отменено. Например, IETF RFC 2616 [10] уточняет http
схему. Одновременно IETF опубликовала содержание RFC 3986 в виде полного стандартного STD 66, отражающего создание универсального синтаксиса URI в качестве официального Интернет-протокола.
В 2001 году группа технической архитектуры W3C (TAG) опубликовала руководство по передовым методам и каноническим URI для публикации нескольких версий данного ресурса. [11] Например, контент может отличаться по языку или размеру, чтобы регулировать емкость или настройки устройства, используемого для доступа к этому контенту.
В августе 2002 г. IETF В RFC 3305 [12] указано, что термин «URL», несмотря на широкое публичное использование, практически устарел и служит только напоминанием о том, что некоторые URI действуют как адреса, имея схемы, предполагающие доступ к сети, независимо от любого такого фактического использования. . Стандарты на основе URI, такие как Resource Description Framework, очевидны, идентификация ресурсов не обязательно должна предполагать получение представлений ресурсов через Интернет, и при этом они не обязательно должны подразумевать сетевые ресурсы вообще.
Semantic Web использует схему HTTP URI для идентификации обоих документов и понятий в реальном мире, различие , которое вызвало путаницу о том , как отличить два. В 2005 году TAG опубликовал электронное письмо о том, как решить проблему, которое стало известно как разрешение httpRange-14 . [13] W3C впоследствии опубликовал заметку группы интересов под названием Cool URIs for Semantic Web , в которой более подробно объяснялось использование согласования контента и кода ответа HTTP 303 для перенаправления. [14]
Дизайн
URL-адреса и URN
Равномерное Имя ресурса (URN) является URI , который идентифицирует ресурс с помощью имени в определенном пространстве имен. URN может использоваться, чтобы говорить о ресурсе, не подразумевая его местоположение или способ доступа к нему. Например, в системе Международного стандартного книжного номера (ISBN) ISBN 0-486-27557-4 идентифицирует конкретное издание пьесы Шекспира « Ромео и Джульетта» . URN для этого издания будет urn: isbn: 0-486-27557-4 . Однако в нем нет информации о том, где найти копию этой книги.
Uniform Resource Locator (URL) является URI , который определяет средства воздействуя на или получения представления ресурса, то есть с указанием как его механизм первичного доступа и сетевого расположения. Например, URL-адрес http://example.org/wiki/Main_Page
относится к ресурсу, обозначенному как /wiki/Main_Page
, представление которого в форме HTML и связанного кода можно получить через протокол передачи гипертекста ( http:) с сетевого хоста, доменное имя которого example.org
.
URN можно сравнить с именем человека, а URL-адрес - с его почтовым адресом. Другими словами, URN идентифицирует элемент, а URL-адрес предоставляет метод для его поиска.
Технические публикации, особенно стандарты, разработанные IETF и W3C , обычно отражают точку зрения, изложенную в Рекомендации W3C от 2001 г., которая признает приоритет термина URI, а не поддерживает какое-либо формальное разделение на URL и URN.
URL-адрес - полезная, но неформальная концепция: URL-адрес - это тип URI, который идентифицирует ресурс через представление его основного механизма доступа (например, его сетевое «местоположение»), а не с помощью некоторых других атрибутов, которые он может иметь. [15]
Таким образом, URL-адрес - это просто URI, который указывает на ресурс в сети. [a] [16] Однако в нетехнических контекстах и в программном обеспечении для World Wide Web термин «URL» по-прежнему широко используется. Кроме того, термин «веб-адрес» (не имеющий формального определения) часто встречается в нетехнических публикациях как синоним URI, который использует схемы http или https . Такие предположения могут привести к путанице, например, в случае пространств имен XML, которые имеют визуальное сходство с разрешаемыми URI .
Характеристики , полученные в WHATWG предпочитают URL через URI , и поэтому новый API , HTML5 использовать URL через URI . [17]
Стандартизируйте термин URL. URI и IRI [международный идентификатор ресурса] просто сбивают с толку. На практике для обоих используется один алгоритм, поэтому сохранение их различий никому не помогает. URL также легко побеждает в конкурсе на популярность в результатах поиска. [18]
Хотя большинство схем URI изначально были разработаны для использования с определенным протоколом и часто имеют одно и то же имя, они семантически отличаются от протоколов. Например, схема http обычно используется для взаимодействия с веб-ресурсами по протоколу HTTP, но файл схемы не имеет протокола.
Синтаксис
Каждый URI начинается с имени схемы, которое относится к спецификации для присвоения идентификаторов в этой схеме. Таким образом, синтаксис URI представляет собой объединенную и расширяемую систему именования, в которой спецификация каждой схемы может дополнительно ограничивать синтаксис и семантику идентификаторов, использующих эту схему. Общий синтаксис URI - это надмножество синтаксиса всех схем URI. Впервые он был определен в RFC 2396 , опубликованный в августе 1998 г. [7] и завершенный в RFC 3986 , опубликованный в январе 2005 г. [19]
Общий синтаксис URI состоит из иерархической последовательности из пяти компонентов : [20]
URI = scheme: [// авторитет] путь [? Запрос] [# фрагмент]
где компонент полномочий делится на три подкомпонента :
авторитет = [информация пользователя @] хост [: порт]
Это представлено на синтаксической диаграмме как:
URI включает:
- Непустой компонент схемы, за которым следует двоеточие (
:
), состоящее из последовательности символов, начинающейся с буквы, за которой следует любая комбинация букв, цифр, плюс (+
), точка (.
) или дефис (-
). Хотя в схемах регистр не учитывается, в канонической форме используются строчные буквы, и в документах, в которых указаны схемы, должны использоваться строчные буквы. Примеры популярных схем включаютhttp
,https
,ftp
,mailto
,file
,data
, иirc
. Схемы URI должны быть зарегистрированы вInternet Assigned Numbers Authority (IANA), хотя на практике используются незарегистрированные схемы. [b] - Необязательный компонент полномочий, которому предшествуют две косые черты (
//
), включая:- Необязательный Подкомпонент userinfo, который может состоять изимени пользователяи необязательногопароля,которому предшествует двоеточие (
:
), за которым следует символ at (@
). Использование форматаusername:password
в подкомпоненте userinfo не рекомендуется по соображениям безопасности. Приложения не должны отображать:
в виде открытоготекста любые данные после первого двоеточия (), найденные в подкомпоненте userinfo, если только данные после двоеточия не являются пустой строкой (указывающей на отсутствие пароля). - А Подкомпонент хоста , состоящий либо из зарегистрированного имени (включая, помимо прочего,имя хоста), либо изIP-адреса. АдресаIPv4должны быть вдесятичном формате с точками, аадресаIPv6должны быть заключены в квадратные скобки (
[]
). [22] [c] - Необязательный подкомпонент порта, которому предшествует двоеточие (
:
).
- Необязательный Подкомпонент userinfo, который может состоять изимени пользователяи необязательногопароля,которому предшествует двоеточие (
- А Компонент пути , состоящий из последовательности сегментов пути, разделенных косой чертой (
/
). Путь всегда определяется для URI, хотя указанный путь может быть пустым (нулевой длины). Сегмент также может быть пустым, что приводит//
к появлениюдвух последовательных косых черт () в компоненте пути. Компонент пути может напоминать или точно соответствоватьпути файловой системы, но не всегда подразумевает связь с ним. Если присутствует компонент полномочий, то компонент пути должен быть пустым или начинаться с косой черты (/
). Если компонент полномочий отсутствует, то путь не может начинаться с пустого сегмента, то есть с двух косых//
черт(), поскольку следующие символы будут интерпретироваться как компонент полномочий. [24] Последний сегмент пути может называться «пробкой».
Разделитель запроса | Пример |
---|---|
Амперсанд ( & ) | key1=value1&key2=value2 |
Точка с запятой ( ; ) [d] | key1=value1;key2=value2 |
- Необязательный компонент запроса, которому предшествует вопросительный знак (
?
), содержащийстроку запросанеиерархических данных. Его синтаксис четко не определен, но по соглашению чаще всего представляет собой последовательностьпар атрибут-значение,разделенныхразделителем. - Необязательный компонент фрагмента, которому предшествуетhash(
#
). Фрагмент содержитидентификатор фрагмента, указывающийнаправление к вторичному ресурсу, например заголовок раздела в статье, идентифицируемый остальной частью URI. Когда основным ресурсом являетсядокументHTML, фрагмент часто являетсяidатрибутомопределенного элемента, и веб-браузеры будут прокручивать этот элемент для просмотра.
Строки октетов данных в URI представлены в виде символов. Разрешенные символы в URI - это символы ASCII для строчных и прописных букв современного английского алфавита , арабские цифры , дефис , точка , подчеркивание и тильда . [26] Октеты, представленные любым другим символом, должны быть закодированы в процентах .
Из набора символов ASCII символы : / ? # [ ] @
зарезервированы для использования в качестве разделителей общих компонентов URI и должны быть закодированы в процентах - например, %3F
для вопросительного знака. [27]! $ & ' ( ) * + , ; =
Общий синтаксис URI позволяет использовать символы без кодирования в информации о пользователе, хосте и пути в качестве разделителей. [22] [28] Кроме того, :
и @
может отображаться незакодированным в пути, запросе и фрагменте; и ?
и /
могут появляться незакодированной в качестве данных в рамках запроса или фрагмента. [28] [29]
На следующем рисунке показаны примеры URI и их составные части.
UserInfo хост - порт ┌──┴───┐ ┌──────┴──────┐ ┌┴┐ https: //[email protected]: 123 / forum / questions /? tag = network & order = newest # top └─┬─┘ └───────────┬──────────────┘ └───────┬───────┘ └───────────┬─────────────┘ └┬┘ схема полномочие пути запрос фрагмент ldap: // [2001: db8 :: 7] / c = GB? objectClass? one └┬─┘ └──────────┘└─┬─┘ └──────┬────── запрос пути авторизации схемы mailto: [email protected] └─┬──┘ └────┬──────────────┘ схема путь новости: comp.infosystems.www.servers.unix └┬─ └─────────────┬────────────────── схема путь тел: + 1-816-555-1212 └┬┘ └──────────── схема путь telnet: //192.0.2.16: 80 / └─┬──┘ └─────┬─────┘│ схема авторитетного пути урна: оазис: имена: спецификация: docbook: dtd: xml: 4.1.2 └┬┘ └───────────────────────┬─────────────────────── схема путь
Ссылки URI
URI ссылка является либо URI, или относительная ссылка , когда она не начинается с компонентом схемы следует двоеточие ( :
). [30] Сегмент пути, содержащий символ двоеточия (например, foo:bar
), не может использоваться в качестве первого сегмента пути относительной ссылки, если его компонент пути не начинается с косой черты ( /
), поскольку это было бы ошибочно принято за компонент схемы. Такому сегменту пути должен предшествовать точечный сегмент пути (например, ./foo:bar
). [31]
Языки разметки веб-документов часто используют ссылки URI для указания на другие ресурсы, такие как внешние документы или определенные части того же логического документа: [32]
- в HTML значение
src
атрибутаimg
элемента предоставляет ссылку на URI, как и значениеhref
атрибута элементаa
илиlink
; - в XML , то системный идентификатор появляется после
SYSTEM
ключевого слова в DTD является fragmentless URI - ссылка; - в XSLT значение
href
атрибутаxsl:import
элемента / инструкции является ссылкой URI; аналогично первый аргументdocument()
функции.
https://example.com/path/resource.txt#fragment//example.com/path/resource.txt/path/resource.txtпуть / resource.txt../resource.txt./resource.txtresource.txt#фрагмент
разрешение
Сопоставление ссылки URI с базовым URI приводит к целевому URI . Это означает, что базовый URI существует и является абсолютным URI (URI без компонента фрагмента). Базовый URI может быть получен в порядке приоритета из: [33]
- сам ссылочный URI, если это URI;
- содержание представления;
- сущность, инкапсулирующая представление;
- URI, используемый для фактического извлечения представления;
- контекст приложения.
Внутри представления с четко определенным базовым URI
http: // a / b / c / d; p? q
относительная ссылка разрешается к своему целевому URI следующим образом: [34]
"g: h" -> "g: h""g" -> "http: // a / b / c / g""./g" -> "http: // a / b / c / g""g /" -> "http: // a / b / c / g /""/ g" -> "http: // a / g""// g" -> "http: // g""? y" -> "http: // a / b / c / d; p? y""g? y" -> "http: // a / b / c / g? y""#s" -> "http: // a / b / c / d; p? q # 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 / d; p? q""." -> "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"
Связь с пространствами имен XML
В XML пространство имен - это абстрактный домен, которому может быть назначен набор имен элементов и атрибутов. Имя пространства имен - это символьная строка, которая должна соответствовать общему синтаксису URI. [35] Однако имя обычно не считается URI, [36] потому что спецификация URI основывает решение не только на лексических компонентах, но и на их предполагаемом использовании. Имя пространства имен не обязательно подразумевает какую-либо семантику схем URI; например, имя пространства имен, начинающееся с http:, может не иметь никакого отношения к использованию HTTP .
Первоначально имя пространства имен могло соответствовать синтаксису любой непустой ссылки URI, но использование относительных ссылок URI не рекомендовалось консорциумом W3C. [37] Отдельная спецификация W3C для пространств имен в XML 1.1 позволяет ссылкам на интернационализированные идентификаторы ресурсов (IRI) служить основой для имен пространств имен в дополнение к ссылкам URI. [38]
Смотрите также
- КЮРИ
- Разыменяемый унифицированный идентификатор ресурса
- Расширяемый идентификатор ресурса
- Интернационализированный идентификатор ресурса (IRI)
- Указатель Интернет-ресурсов
- Постоянный универсальный указатель ресурсов
- Единое соглашение об именах
- Язык описания каталога ресурсов
- Универсальный уникальный идентификатор
- Список схем URI
Заметки
- ^ Отчет, опубликованный в 2002 году совместной рабочей группой W3C / IETF, был направлен на нормализацию разногласий, существующих в IETF и W3C по поводу взаимосвязи между различными терминами и стандартами «UR *». Хотя он не был опубликован в качестве полного стандарта ни одной из организаций, он стал основой для вышеупомянутого общего понимания и с тех пор послужил основой для многих стандартов.
- ^ Процедуры регистрации новых схем URI были первоначально определены в 1999 г. RFC 2717 и теперь определяются RFC 7595 , опубликованный в июне 2015 г. [21]
- ^ Для URI, относящихся к ресурсам во всемирной паутине, некоторые веб-браузеры позволяют
.0
отбрасывать части десятичной записи с точками или использовать необработанные целочисленные IP-адреса. [23] - ^ Исторический RFC 1866 (устарело RFC 2854 ) призывает авторов CGI поддерживать ';' в дополнение к '&'. [25]
Рекомендации
- ^ Палмер, Шон. «Ранняя история HTML» . infomesh.net . Проверено 6 декабря 2020 .
- ^ «Схемы именования W3» . www.w3.org . 1992 . Проверено 6 декабря 2020 .
- ^ Бернерс-Ли, Тим (июнь 1994). «Универсальные идентификаторы ресурсов в WWW» . Сетевая рабочая группа . Проверено 6 декабря 2020 .
- ^ Бернерс-Ли, Тим (декабрь 1994). «Запрос комментариев: 1738: унифицированные указатели ресурсов (URL)» . tools.ietf.org/html . Проверено 6 декабря 2020 .
- ^ Моутс, Р. (май 1997 г.). «Запрос комментариев: 2141: Синтаксис URN» . tools.ietf.org . Проверено 6 декабря 2020 .
- ^ Бернерс-Ли, Тим (август 1998 г.). «RFC 2396: унифицированные идентификаторы ресурсов (URI): общий синтаксис» . tools.ietf.org . Проверено 6 декабря 2020 .
- ^ а б RFC 2396 (1998) .
- ^ Хинден, Р. (декабрь 1999 г.). «RFC 2732: формат для буквальных адресов IPv6 в URL» . tools.ietf.org . Проверено 6 декабря 2020 .
- ^ Бернерс-Ли, Тим (январь 2005 г.). «RFC 3986: унифицированный идентификатор ресурса (URI): общий синтаксис» . tools.ietf.org . Проверено 6 декабря 2020 .
- ^ Филдинг, Р. (июнь 1999 г.). «RFC 2616: протокол передачи гипертекста - HTTP / 1.1» . tools.ietf.org . Проверено 6 декабря 2020 .
- ^ Раман, ТВ (01.11.2006). «О связывании альтернативных представлений для открытия и публикации» . www.w3.org . Проверено 6 декабря 2020 .
- ^ Миллинг, М. (август 2002 г.). «RFC 3305: универсальные идентификаторы ресурсов (URI), URL-адреса и универсальные имена ресурсов» . tools.ietf.org . Проверено 6 декабря 2020 .
- ^ Филдинг, Рой (18.06.2005). "[httpRange-14] Решено" . lists.w3.org . Проверено 6 декабря 2020 .
- ^ Зауэрманн, Лео (декабрь 2008 г.). «Классные URI для семантической сети» . www.w3.org . Проверено 6 декабря 2020 .
- ^ Группа по планированию URI, W3C / IETF (сентябрь 2001 г.). «URI, URL-адреса и URN: пояснения и рекомендации 1.0» . www.w3.org . W3C / IETF . Проверено 8 декабря 2020 .
- ^ Объединенная группа по планированию URI W3C / IETF (2002) .
- ^ «Стандарт URL: 6.3. API URL в другом месте» .
- ^ «Стандарт URL: цели» .
- ↑ RFC 3986 (2005) .
- ^ RFC 3986, раздел 3 (2005) .
- ^ IETF (2015) .
- ^ a b RFC 3986 (2005) , §3.2.2.
- ^ Лоуренс (2014) .
- ^ RFC 2396 (1998) , §3.3.
- ^ RFC 1866 (1995) , §8.2.1.
- ↑ RFC 3986 (2005) , §2.
- ^ RFC 3986 (2005) , §2.2.
- ^ a b RFC 3986 (2005) , §3.3.
- ↑ RFC 3986 (2005) , §3.4.
- ↑ RFC 3986 (2005) , §4.1.
- ↑ RFC 3986 (2005) , §4.2.
- ↑ RFC 3986 (2005) , §4.4.
- ^ RFC 3986 (2005) , §5.1.
- ↑ RFC 3986 (2005) , §5.4.
- ^ Моррисон (2006) .
- ^ Гарольд (2004) .
- ↑ W3C (2009) .
- ^ W3C (2006) .
дальнейшее чтение
- Гарольд, Эллиотт Расти (2004). XML 1.1 Библия (Третье изд.). Wiley Publishing . п. 291. ISBN. 978-0-7645-4986-1.
- Хансен, Тони; Харди, Тед (июнь 2015 г.). Талер, Дэйв (ред.). «Рекомендации и процедуры регистрации для схем URI» . Страницы запроса комментариев (RFC) Ietf - Тест . Инженерная группа Интернета . ISSN 2070-1721 .
- Моррисон, Майкл Уэйн (2006). «Час 5: Использование пространств имен ». Самс учись XML . Самс Паблишинг . п. 91.
- Группа интересов по планированию URI, W3C / IETF (21 сентября 2001 г.). «URI, URL-адреса и URN: пояснения и рекомендации 1.0» . Проверено 27 июля 2009 .
- «О связывании альтернативных представлений для открытия и публикации» . Консорциум World Wide Web . 2006 [2001] . Проверено 3 апреля 2012 .
- Брей, Тим ; Холландер, Дэйв; Обыватель, Андрей; Тобин, Ричард, ред. (16 августа 2006 г.). «Пространства имен в XML 1.1 (второе издание)» . Консорциум World Wide Web . 2.2 Использование URI в качестве имен пространств имен . Проверено 31 августа 2015 .
- Айерс, Дэнни; Фёлькель, Макс (2008-12-03). Зауэрманн, Лео; Cyganiak, Ричард (ред.). «Классные URI для семантической сети» . Консорциум World Wide Web . Проверено 3 апреля 2012 .
- Брей, Тим ; Холландер, Дэйв; Обыватель, Андрей; Тобин, Ричард; Томпсон, Генри С., ред. (2009-12-08). «Пространства имен в XML 1.0 (третье издание)» . Консорциум World Wide Web . 2.2 Использование URI в качестве имен пространств имен . Проверено 31 августа 2015 .
- Бернерс-Ли, Тим ; Коннолли, Дэниел «Дэн» (ноябрь 1995 г.). «Язык разметки гипертекста - 2.0» . Инженерная группа Интернета . Проверено 13 сентября 2015 .
- Бернерс-Ли, Тим ; Филдинг, Рой Т .; Масинтер, Ларри (август 1998). Универсальные идентификаторы ресурсов (URI): общий синтаксис . Инженерная группа Интернета . DOI : 10,17487 / RFC2396 . RFC 2396 . Проверено 31 августа 2015 .
- Бернерс-Ли, Тим ; Филдинг, Рой Т .; Масинтер, Ларри (январь 2005 г.). Универсальные идентификаторы ресурсов (URI): общий синтаксис . Инженерная группа Интернета . DOI : 10,17487 / RFC3986 . RFC 3986 . Проверено 31 августа 2015 .
- Бернерс-Ли, Тим ; Филдинг, Рой Т .; Масинтер, Ларри (январь 2005 г.). Унифицированные идентификаторы ресурсов (URI): Общий синтаксис, раздел 3, Компоненты синтаксиса . Инженерная группа Интернета . DOI : 10,17487 / RFC3986 . RFC 3986 . Проверено 31 августа 2015 .
- Лоуренс, Эрик (2014-03-06). «Браузерные арканы: литералы IP в URL-адресах» . IEInternals . Microsoft . Проверено 25 апреля 2016 .
Внешние ссылки
- Схемы URI - поддерживаемый IANA реестр схем URI
- Схемы URI в вики W3C
- Архитектура всемирной паутины, Том первый, §2: Идентификация - от W3C
- Разъяснение W3C URI