Единый идентификатор ресурса

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

Не путать с URL .

Единый идентификатор ресурса

Сокращение	ТИП
Родное имя	РФК 3986
Положение дел	Активный
Год начался	2005
Впервые опубликовано	Январь 2005 г. ( 2005-01 )
Организация	RFC
Авторы	Тим Бернерс-Ли ; Рой Томас Филдинг ; Ларри Масинтер
Домен	Всемирная паутина
Веб-сайт	https://datatracker.ietf.org/doc/html/rfc3986#section-1.1

Унифицированный идентификатор ресурса ( URI ), ранее известный как Универсальный идентификатор ресурса , представляет собой уникальную последовательность символов, которая идентифицирует абстрактный или физический ресурс. например ресурсы на веб-странице, адрес электронной почты, номер телефона, книги, объекты реального мира, такие как люди и места, концепции. URI используются для идентификации всего, что описано с использованием структуры описания ресурсов (RDF), например, концепций, которые являются частью онтологии , определенной с использованием языка веб-онтологий (OWL), и люди, которые описаны с использованием словаря друга друга, будут каждый иметь индивидуальный URI.

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

История

Концепция

URI и URL-адреса имеют общую историю. В 1990 году Тима Бернерса-Ли предложения по гипертексту неявно представили идею URL-адреса как короткой строки, представляющей ресурс, являющийся целью гиперссылки . В то время люди называли это «гипертекстовым именем». или «имя документа».

В течение следующих трех с половиной лет, по мере развития основных технологий Всемирной паутины, таких как HTML, HTTP и веб-браузеры, возникла необходимость отличать строку, которая предоставляла адрес ресурса, от строки, которая просто называла ресурс. Хотя термин «Единый указатель ресурса» еще не определен формально, он стал обозначать первый, а более спорное «Единое имя ресурса» — второе. В июле 1992 года в отчете Бернерса-Ли о IETF «UDI (универсальные идентификаторы документов) BOF » упоминаются URL-адреса (как унифицированные указатели ресурсов), URN (первоначально как уникальные номера ресурсов) и необходимость создания новой рабочей группы. В ноябре 1992 года «Рабочая группа URI» IETF встретилась впервые.

В ходе дебатов по поводу определения URL-адресов и URN стало очевидно, что концепции, воплощенные в этих двух терминах, являются всего лишь аспектами фундаментального, всеобъемлющего понятия идентификации ресурса . В июне 1994 года IETF опубликовала первый запрос Бернерса-Ли на комментарии , в котором признавалось существование URL-адресов и URN. Самое главное, он определил формальный синтаксис для универсальных идентификаторов ресурсов (т.е. строк, подобных URL-адресам, точный синтаксис и семантика которых зависели от их схем). В дополнение В RFC   1630 была предпринята попытка обобщить синтаксис схем URL, использовавшихся в то время. Он признал, но не стандартизировал , существование относительных URL-адресов и идентификаторов фрагментов.

Уточнение

В декабре 1994 года RFC   1738 формально определил относительные и абсолютные URL-адреса, уточнил общий синтаксис URL-адресов, определил, как преобразовать относительные URL-адреса в абсолютную форму, и лучше перечислил используемые тогда схемы URL-адресов. Согласованному определению и синтаксису URN пришлось подождать до публикации IETF RFC 2141. в мае 1997 года.

Публикация IETF RFC 2396. в августе 1998 года синтаксис URI стал отдельной спецификацией. и большинство частей RFC 1630 и 1738, касающихся URI и URL-адресов в целом, были пересмотрены и расширены IETF . В новом RFC значение U в URI изменено с «Universal» на «Uniform».

В декабре 1999 года RFC   2732 предоставил небольшое обновление RFC 2396, позволяющее использовать URI для адресов IPv6 . Ряд недостатков, обнаруженных в двух спецификациях, привел к усилиям сообщества, координируемым соавтором RFC 2396 Роем Филдингом , которые завершились публикацией IETF RFC 3986. в январе 2005 года. Хотя предыдущий стандарт устарел, он не сделал устаревшими детали существующих схем URL-адресов; RFC 1738 продолжает регулировать такие схемы, если иное не заменено. IETF RFC 2616. например, уточняет httpсхема. Одновременно IETF опубликовал содержание RFC 3986 как полный стандарт STD 66, что отражает установление общего синтаксиса URI в качестве официального протокола Интернета.

В 2001 году группа технической архитектуры (TAG) W3C опубликовала руководство по лучшим практикам и каноническим URI для публикации нескольких версий данного ресурса. Например, контент может отличаться в зависимости от языка или размера, чтобы соответствовать емкости или настройкам устройства, используемого для доступа к этому контенту.

В августе 2002 года IETF RFC   3305 отметил, что термин «URL», несмотря на широкое публичное использование, практически устарел и служит лишь напоминанием о том, что некоторые URI действуют как адреса, имея схемы, предполагающие доступность сети, независимо от любого такого фактического использования. Как показывают стандарты, основанные на URI, такие как Resource Description Framework , идентификация ресурсов не обязательно предполагает получение представлений ресурсов через Интернет и вообще не обязательно подразумевает сетевые ресурсы.

Семантическая сеть использует схему HTTP URI для идентификации как документов, так и концепций для практического использования, и это различие привело к путанице в том, как их различать. В 2005 году TAG опубликовал электронное письмо с решением проблемы, которое стало известно как резолюция httpRange-14 . Впоследствии W3C опубликовал заметку группы по интересам под названием Cool URI для семантической сети объяснялось использование согласования контента и кода ответа HTTP 303 для перенаправления. , в которой более подробно

Дизайн

URL-адреса и URN

Единое имя ресурса (URN) — это URI, который идентифицирует ресурс по имени в определенном пространстве имен. URN может использоваться для описания ресурса, не подразумевая его местонахождение или способ доступа к нему. Например, в системе Международного стандартного номера книги (ISBN) ISBN 0-486-27557-4 идентифицирует конкретное издание пьесы Шекспира «Ромео и Джульетта» . URN для этого издания будет urn:isbn:0-486-27557-4 . Однако он не дает никакой информации о том, где найти копию этой книги.

Унифицированный указатель ресурса (URL) — это URI, который определяет средства воздействия на ресурс или получения его представления, т. е. указывает как его основной механизм доступа, так и сетевое расположение. Например, URL-адрес http://example.org/wiki/Main_Page относится к ресурсу, определенному как /wiki/Main_Page, представление которого можно получить через протокол передачи гипертекста ( http: ) от сетевого узла, чье доменное имя example.org. (В этом случае HTTP обычно подразумевает, что он представлен в форме HTML и связанного с ним кода. На практике это не обязательно так, поскольку HTTP позволяет указывать произвольные форматы в своем заголовке.)

URN аналогичен имени человека, а URL-адрес аналогичен его почтовому адресу. Другими словами, URN идентифицирует элемент, а URL-адрес предоставляет метод его поиска.

Технические публикации, особенно стандарты, выпускаемые IETF и W3C , обычно отражают точку зрения, изложенную в Рекомендации W3C от 30 июля 2001 г., которая признает приоритет термина URI, а не одобряет какое-либо формальное подразделение на URL и URN.

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

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

Спецификации, разработанные WHATWG, отдают предпочтение URL-адресу , а не URI , поэтому новые API HTML5 используют URL-адрес , а не URI .

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

Хотя большинство схем URI изначально были разработаны для использования с определенным протоколом и часто имеют одно и то же имя, они семантически отличаются от протоколов. Например, схема http обычно используется для взаимодействия с веб-ресурсами схемы по протоколу HTTP, но файл не имеет протокола.

Синтаксис

См. также: Список схем URI.

URI имеет схему, которая ссылается на спецификацию назначения идентификаторов в этой схеме. По сути, синтаксис URI представляет собой объединенную и расширяемую систему именования, в которой спецификация каждой схемы может дополнительно ограничивать синтаксис и семантику идентификаторов, использующих эту схему. Общий синтаксис URI является расширенным набором синтаксиса всех схем URI. Впервые оно было определено в RFC   2396 , опубликованный в августе 1998 г., и завершено в RFC   3986 , опубликованный в январе 2005 г.

URI состоит из разрешенного набора символов ASCII , состоящего из зарезервированных символов (gen-delims: :, /, ?, #, [, ], и @; подразделители: !, $, &, ', (, ), *, +, ,, ;, и =), незарезервированные символы ( прописные и строчные буквы , десятичные цифры , -, ., _, и ~), и персонаж %. Компоненты и подкомпоненты синтаксиса отделяются разделителями от зарезервированных символов (только от общих зарезервированных символов для компонентов) и определяют идентифицирующие данные , представленные в виде незарезервированных символов, зарезервированных символов, которые не действуют как разделители в компоненте и подкомпоненте соответственно. и процентное кодирование, когда соответствующий символ находится за пределами разрешенного набора или используется в качестве разделителя компонента или внутри него. Процентное кодирование октета идентифицирующих данных представляет собой последовательность из трех символов, состоящую из символа % за которыми следуют две шестнадцатеричные цифры, представляющие числовое значение этого октета.

Общий синтаксис URI состоит из пяти компонентов , организованных иерархически в порядке убывания значимости слева направо:

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

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

Компонент полномочий состоит из подкомпонентов :

полномочия = [информация пользователя "@"] хост [":" порт]
 

это представлено На синтаксической диаграмме как:

URI включает в себя:

• Непустой компонент схемы , за которым следует двоеточие ( :), состоящий из последовательности символов, начинающейся с буквы и сопровождаемой любой комбинацией букв, цифр плюс ( +), период ( .) или дефис ( -). Хотя схемы нечувствительны к регистру, каноническая форма — строчные, и документы, в которых указаны схемы, должны писаться строчными буквами. Примеры популярных схем включают в себя http, https, ftp, mailto, file, data и irc. Схемы URI должны быть зарегистрированы в Управлении по присвоению номеров Интернета (IANA) , хотя на практике используются незарегистрированные схемы.
• Дополнительный компоненту полномочий , которому предшествуют две косые черты ( //), включающий:
  • Дополнительный подкомпонент userinfo , за которым следует символ at ( @), который может состоять из имени пользователя и необязательного пароля , которым предшествует двоеточие ( :). Использование формата username:passwordв подкомпоненте userinfo устарел по соображениям безопасности. Приложения не должны отображать в виде открытого текста любые данные после первого двоеточия ( :), найденный в подкомпоненте userinfo, если только данные после двоеточия не являются пустой строкой (означающей отсутствие пароля).
  • А Подкомпонент хоста , состоящий либо из зарегистрированного имени (включая, помимо прочего, имя хоста ), либо из IP-адреса . IPv4 Адреса должны быть записаны в десятичном формате , а адреса IPv6 должны быть заключены в скобки ( []).
  • Дополнительный подкомпонент порта , которому предшествует двоеточие ( :), состоящее из десятичных цифр.
• А компонент пути , состоящий из последовательности сегментов пути, разделенных косой чертой ( /). Для URI всегда определяется путь, хотя определенный путь может быть пустым (нулевая длина). Сегмент также может быть пустым, что приводит к двум последовательным косым чертам ( //) в компоненте пути. Компонент пути может напоминать или точно соответствовать пути файловой системы , но не всегда подразумевает связь с ним. Если определен компонент полномочий, то компонент пути должен быть либо пустым, либо начинаться с косой черты ( /). Если компонент полномочий не определен, то путь не может начинаться с пустого сегмента, то есть с двух косых черт ( //) — поскольку следующие символы будут интерпретироваться как авторитетный компонент.

По соглашению в URI http и https последняя часть пути называется pathinfo , и это необязательно. Он состоит из нуля или более сегментов пути, которые относятся не к существующему имени физического ресурса (например, файлу, программе внутреннего модуля или исполняемой программе), а к логической части (например, команде или части квалификатора), которая должна передаваться отдельно в первую часть пути, которая идентифицирует исполняемый модуль или программу, управляемую веб-сервером ; это часто используется для выбора динамического контента (документа и т. д.) или для его адаптации по запросу (см. также: CGI и PATH_INFO и т. д.).

Пример:

ТИП: "http://www.example.com/questions/3456/my-document"

где: "/questions" это первая часть пути ( исполняемый модуль или программа) и "/3456/my-document" — это вторая часть пути с именем pathinfo , которая передается исполняемому модулю или программе с именем "/questions" выбрать требуемый документ.

URI http или https , содержащий часть pathinfo без части запроса , также может называться « чистым URL », последняя часть которого может быть « слагом ».

Разделитель запроса	Пример
Амперсанд ( &)	key1=value1&key2=value2
Точка с запятой ( ;)	key1=value1;key2=value2

• Дополнительный компонент запроса , которому предшествует вопросительный знак ( ?), состоящий из строки запроса неиерархических данных. Его синтаксис не очень четко определен, но по соглашению чаще всего представляет собой последовательность пар атрибут-значение, разделенных разделителем .
• Дополнительный компонент фрагмента , которому предшествует хэш ( #). Фрагмент содержит идентификатор фрагмента , указывающий направление к вторичному ресурсу, например заголовок раздела в статье, идентифицируемый остатком URI. Если первичным ресурсом является документ HTML , фрагмент часто представляет собой id атрибут определенного элемента, и веб-браузеры будут прокручивать этот элемент в поле зрения.

Зарезервированный символ, зависящий от схемы или реализации. + может использоваться в схеме, информации о пользователе, хосте, пути, запросе и фрагменте, а также в зарезервированных символах, специфичных для схемы или реализации. !, $, &, ', (, ), *, ,, ;, и =может использоваться в информации о пользователе, хосте, пути, запросе и фрагменте. Кроме того, общий зарезервированный символ : может использоваться в информации о пользователе, пути, запросе и фрагменте, общих зарезервированных символах @ и / может использоваться в пути, запросе и фрагменте, а также в общем зарезервированном символе ? может использоваться в запросе и фрагменте.

Примеры URI

На следующем рисунке показаны примеры URI и их составные части.

          информация о пользователе        хозяин       порт 
          ┌──┴───┐  ┌──────┴──────┐  ┌┴─┐ 
    https://[email protected]:1234/forum/questions/?tag=networking&order=newest#top 
   └─┬─┘    └─────────────┬─────────────┘ └───────┬───────┘  └────────────┬────────────┘  └┬┘ 
  схема             власть                 путь                    запрос           фрагмент 
          информация о пользователе        хозяин       порт 
          ┌──┴───┐  ┌──────┴──────┐  ┌┴─┐ 
    https://[email protected]:1234/forum/questions/?tag=networking&order=newest#:~:text=whatever 
   └─┬─┘    └─────────────┬─────────────┘ └───────┬───────┘  └────────────┬────────────┘  └───────┬───────┘ 
  схема             власть                 путь                    запрос                  фрагмент 

    ldap://[2001:db8::7]/c=GB?objectClass?one 
   └┬─┘    └─────┬─────┘ └─┬─┘  └──────┬──────┘ 
  схема    власть    путь       запрос 

    почта: [email protected] 
   └─┬──┘  └────┬─────────────┘ 
  схема      путь 

    новости:comp.infosystems.www.servers.unix 
   └┬─┘  └─────────────┬─────────────────┘ 
  схема             путь 

    тел:+1-816-555-1212 
   └┬┘  └──────┬──────┘ 
  схема     путь 

    телнет://192.0.2.16:80/ 
   └─┬──┘    └─────┬─────┘ │ 
  схема      власть   путь 

    урна:оазис:имена:спецификация:docbook:dtd:xml:4.1.2 
   └┬┘  └──────────────────────┬──────────────────────┘ 
  схема                     путь 

DOI ( идентификаторы цифровых объектов ) вписываются в систему дескрипторов и в систему URI, чему способствует соответствующий синтаксис .

Ссылки URI

Ссылка URI является либо URI, либо относительной ссылкой , если она не начинается с компонента схемы, за которым следует двоеточие ( :). Сегмент пути, содержащий символ двоеточия (например, foo:bar) нельзя использовать в качестве первого сегмента пути относительной ссылки, если ее компонент пути не начинается с косой черты ( /), так как его можно было бы принять за компонент схемы. Такому сегменту пути должен предшествовать сегмент пути с точкой (например, ./foo:bar).

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

• в HTML значение src атрибут img элемент предоставляет ссылку URI, как и значение href атрибут a или link элемент;
• в XML — системный идентификатор , появляющийся после SYSTEM Ключевое слово в DTD представляет собой ссылку на URI без фрагментов;
• в XSLT значение href атрибут xsl:importэлемент/инструкция является ссылкой URI; аналогично первый аргумент document() функция.

https://example.com/path/resource.txt#fragment
 //example.com/path/resource.txt
 /путь/resource.txt
 путь/resource.txt
 ../resource.txt
 ./resource.txt
 ресурс.txt
 #фрагмент
 

Разрешение

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

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

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

http://a/b/c/d;p?q
 

относительная ссылка разрешается на целевой URI следующим образом:

«г:ч» -> «г:ч»
 "г" -> "http://a/b/c/g"
 "./g" -> "http://a/b/c/g"
 "г/" -> "http://a/b/c/g/"
 "/г" -> "http://a/g"
 "//г" -> "http://г"
 "?y" -> "http://a/b/c/d;p?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"
 

URL-адрес манинга

Обработка URL-адресов — это метод, при котором команда добавляется к URL-адресу, обычно в конце, после знака "?" жетон . Он обычно используется в WebDAV как механизм добавления функциональности к HTTP . Например, в системе управления версиями для добавления команды «извлечение» к URL-адресу она записывается как http://editing.com/resource/file.php?command=checkout. Его преимущество заключается в том, что он удобен для анализаторов CGI , а также в данном случае выступает в качестве посредника между HTTP и базовым ресурсом.

Связь с пространствами имен XML

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

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

См. также

• КЮРИ
• Связанные данные
• Расширяемый идентификатор ресурса
• Интернационализированный идентификатор ресурса (IRI)
• Поиск интернет-ресурсов
• Постоянный универсальный указатель ресурсов
• Единое соглашение об именах
• Язык описания каталога ресурсов
• Универсальный уникальный идентификатор
• Список схем URI

Ссылки

Цитируемые работы

• Бернерс-Ли, Тим ; Филдинг, Рой Т .; Масинтер, Ларри (январь 2005 г.). RFC 3986 Единый идентификатор ресурса (URI): общий синтаксис . Рабочая группа по интернет-инжинирингу. Архивировано из оригинала 9 июня 2011 г. Проверено 16 февраля 2024 г. {{cite book}}: CS1 maint: несколько имен: список авторов ( ссылка )

Дальнейшее чтение

• Гарольд, Эллиотт Расти (2004). XML 1.1 Библия (Третье изд.). Издательство Уайли . п. 291. ИСБН  978-0-7645-4986-1 .
• Хансен, Тони; Харди, Тед (июнь 2015 г.). Талер, Дэйв (ред.). «Руководство и процедуры регистрации схем URI» . Страницы запроса комментариев IETF (RFC) — тест . Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC7595 . ISSN   2070-1721 .
• Моррисон, Майкл Уэйн (2006). «Час 5: Использование пространств имен ». Сэмс: Изучите XML самостоятельно . Издательство Самс . п. 91.
• Группа по планированию URI, W3C/IETF (21 сентября 2001 г.). «URI, URL-адреса и URN: Разъяснения и рекомендации 1.0» . Проверено 27 июля 2009 г. {{cite web}}: CS1 maint: числовые имена: список авторов ( ссылка )
• «О связывании альтернативных представлений для обеспечения обнаружения и публикации» . Консорциум Всемирной паутины . 2006 [2001] . Проверено 3 апреля 2012 г.
• Брэй, Тим ; Холландер, Дэйв; Лейман, Эндрю; Тобин, Ричард, ред. (16 августа 2006 г.). «Пространства имен в XML 1.1 (второе издание)» . Консорциум Всемирной паутины . 2.2 Использование URI в качестве имен пространств имен . Проверено 31 августа 2015 г.
• Айерс, Дэнни; Фелькель, Макс (3 декабря 2008 г.). Зауэрманн, Лео; Циганиак, Ричард (ред.). «Крутые URI для семантической сети» . Консорциум Всемирной паутины . Проверено 3 апреля 2012 г.
• Брэй, Тим ; Холландер, Дэйв; Лейман, Эндрю; Тобин, Ричард; Томпсон, Генри С., ред. (08.12.2009). «Пространства имен в XML 1.0 (третье издание)» . Консорциум Всемирной паутины . 2.2 Использование URI в качестве имен пространств имен . Проверено 31 августа 2015 г.
• Бернерс-Ли, Тим ; Коннолли, Дэниел «Дэн» (ноябрь 1995 г.). «Язык гипертекстовой разметки – 2.0» . Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC1866 . S2CID   6628570 . Проверено 13 сентября 2015 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
• Бернерс-Ли, Тим ; Филдинг, Рой Т .; Масинтер, Ларри (август 1998 г.). Единые идентификаторы ресурсов (URI): общий синтаксис . Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC2396 . РФК 2396 . Проверено 31 августа 2015 г.
• Бернерс-Ли, Тим ; Филдинг, Рой Т .; Масинтер, Ларри (январь 2005 г.). Единые идентификаторы ресурсов (URI): общий синтаксис . Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC3986 . РФК 3986 . Проверено 31 августа 2015 г.
• Бернерс-Ли, Тим ; Филдинг, Рой Т .; Масинтер, Ларри (январь 2005 г.). Единые идентификаторы ресурсов (URI): Общий синтаксис, раздел 3, Компоненты синтаксиса . Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC3986 . РФК 3986 . Проверено 31 августа 2015 г.
• Лоуренс, Эрик (6 марта 2014 г.). «Тайны браузера: IP-литералы в URL-адресах» . IEInternals . Майкрософт . Проверено 25 апреля 2016 г.

• Уайтхед, Э.Дж. (1998). «WebDAV: стандарт IEFT для совместной разработки в Интернете» . IEEE Интернет-вычисления . 2 (5): 34–40. дои : 10.1109/4236.722228 . ISSN   1941-0131 . Проверено 12 октября 2021 г.

Внешние ссылки

• Схемы URI - IANA. реестр схем URI, поддерживаемый
• Схемы URI в вики W3C
• Архитектура Всемирной паутины, Том первый, §2: Идентификация – W3C
• Разъяснение URI W3C