stringtranslate.com

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

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

История

Концепция

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

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

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

Уточнение

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

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

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

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

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

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

Дизайн

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/URI_scheme/Main_Pageотносится к ресурсу, обозначенному как /wiki/URI_scheme/Main_Page, представление которого можно получить через протокол передачи гипертекста ( http: ) от сетевого узла с доменным именем example.org. (В этом случае HTTP обычно подразумевает, что он представлен в форме HTML и связанного с ним кода. На практике это не обязательно так, поскольку HTTP позволяет указывать произвольные форматы в своем заголовке.)

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

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

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

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

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

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

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

Синтаксис

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

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


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

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

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

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

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

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

Синтаксическая диаграмма URI

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

По соглашению в URI http и https последняя часть пути называетсяpathinfo , и это необязательно. Он состоит из нуля или более сегментов пути, которые относятся не к существующему имени физического ресурса (например, файлу, программе внутреннего модуля или исполняемой программе), а к логической части (например, команде или части квалификатора), которая должна передаваться отдельно в первую часть пути, которая идентифицирует исполняемый модуль или программу, управляемуювеб-сервером; это часто используется для выбора динамического контента (документа и т. д.) или для его адаптации по запросу (см. также:CGIи PATH_INFO и т. д.).
Пример:
URI:"http://www.example.com/questions/3456/my-document"
где: "/questions"— первая часть пути ( исполняемый модуль или программа) и "/3456/my-document"вторая часть пути с именем pathinfo , который передается исполняемому модулю или программе с указанным именем "/questions"для выбора запрошенного документа.
URI http или https , содержащий часть pathinfo без части запроса, также может называться « чистым URL », последняя часть которого может быть « слагом ».

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

Примеры URI

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

 userinfo  порт хоста  ┌──┴───┐ ┌─────┴──────┐ ┌┴┐    https://[email protected]:123/forum/questions/?tag=networking&order=newest#top └─┬─┘  └────────────┬────────────┘ └───────┬───────┘  └────────────┬────────────┘  └┬┘  фрагмент запроса пути к полномочиям схемы     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, либо относительной ссылкой, если она не начинается с компонента схемы, за которым следует двоеточие ( :). [34] Сегмент пути, содержащий символ двоеточия (например, foo:bar), не может использоваться в качестве первого сегмента пути относительной ссылки, если его компонент пути не начинается с косой черты ( /), поскольку его можно принять за компонент схемы. Такому сегменту пути должен предшествовать сегмент пути с точкой (например, ./foo:bar). [35]

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

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 можно получить в порядке приоритета из: [37]

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

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

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

«г:ч» -> «г:ч»"г" -> "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 . Например, в системе управления версиями команда «checkout» добавляется к URL-адресу и записывается как http://editing.com/resource/file.php?command=checkout. Его преимущество заключается в том, что он удобен для анализаторов CGI , а также в данном случае выступает в качестве посредника между HTTP и базовым ресурсом. [39]

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

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

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

Смотрите также

Примечания

  1. ^ Отчет, опубликованный в 2002 году совместной рабочей группой W3C/IETF, был направлен на нормализацию расхождений во взглядах внутри IETF и W3C на взаимосвязь между различными терминами и стандартами «UR*». Хотя ни одна организация не опубликовала его в качестве полного стандарта, он стал основой для вышеуказанного общего понимания и с тех пор лег в основу многих стандартов.
  2. ^ Процедуры регистрации новых схем URI были первоначально определены в 1999 году в RFC  2717, а теперь определяются в RFC 7595, опубликованном в июне 2015 года. [28]
  3. ^ Для URI, относящихся к ресурсам во Всемирной паутине, некоторые веб-браузеры позволяют .0отбрасывать части точечно-десятичного представления или использовать необработанные целочисленные IP-адреса. [30]
  4. ^ Исторический RFC  1866 (устаревший из-за RFC 2854) призывает авторов CGI поддерживать ';' в дополнение к '&'. [32]

Рекомендации

  1. ^ Палмер, Шон. «Ранняя история HTML». infomesh.net . Проверено 6 декабря 2020 г.
  2. ^ «Схемы именования W3» . www.w3.org . 1992 год . Проверено 06 декабря 2020 г.
  3. ^ «Материалы двадцать четвертой рабочей группы по интернет-инжинирингу» (PDF) . п. 193 . Проверено 27 июля 2021 г.
  4. ^ «Материалы двадцать пятой рабочей группы по интернет-инжинирингу» (PDF) . п. 501 . Проверено 27 июля 2021 г.
  5. ^ Бернерс-Ли, Тим (июнь 1994 г.). «Универсальные идентификаторы ресурсов в WWW». Сетевая рабочая группа. дои : 10.17487/RFC1630 . Проверено 06 декабря 2020 г. {{cite journal}}: Требуется цитировать журнал |journal=( помощь )
  6. ^ Бернерс-Ли, Тим (декабрь 1994 г.). «Запрос комментариев: 1738: унифицированные указатели ресурсов (URL)». инструменты.ietf.org/html . дои : 10.17487/RFC1738 . Проверено 6 декабря 2020 г.
  7. ^ Моутс, Р. (май 1997 г.). «Запрос комментариев: 2141: Синтаксис URN». www.tools.ietf.org . дои : 10.17487/RFC2141 . Проверено 6 декабря 2020 г.
  8. ^ Бернерс-Ли, Тим (август 1998 г.). «RFC 2396: унифицированные идентификаторы ресурсов (URI): общий синтаксис». www.tools.ietf.org . дои : 10.17487/RFC2396 . Проверено 6 декабря 2020 г.
  9. ^ ab RFC 2396 (1998).
  10. ^ Хинден, Р. (декабрь 1999 г.). «RFC 2732: Формат буквальных адресов IPv6 в URL-адресах». www.tools.ietf.org . дои : 10.17487/RFC2732 . Проверено 06 декабря 2020 г.
  11. ^ Бернерс-Ли, Тим (январь 2005 г.). «RFC 3986: унифицированный идентификатор ресурса (URI): общий синтаксис». www.tools.ietf.org . дои : 10.17487/RFC3986 . Проверено 6 декабря 2020 г.
  12. ^ Филдинг, Р. (июнь 1999 г.). «RFC 2616: Протокол передачи гипертекста — HTTP/1.1». www.tools.ietf.org . дои : 10.17487/RFC2616 . Проверено 6 декабря 2020 г.
  13. ^ Раман, ТВ (11 ноября 2006 г.). «О связывании альтернативных представлений для обеспечения обнаружения и публикации». www.w3.org . Проверено 06 декабря 2020 г.
  14. ^ Миллинг, М. (август 2002 г.). Миллинг, М; Дененберг, Р. (ред.). «RFC 3305: унифицированные идентификаторы ресурсов (URI), URL-адреса и унифицированные имена ресурсов». www.tools.ietf.org . дои : 10.17487/RFC3305 . Проверено 06 декабря 2020 г.
  15. ^ Филдинг, Рой (18 июня 2005 г.). «[httpRange-14] Решено». lists.w3.org . Проверено 6 декабря 2020 г.
  16. ^ Зауэрманн, Лео (декабрь 2008 г.). «Крутые URI для семантической сети». www.w3.org . Проверено 06 декабря 2020 г.
  17. ^ Группа по планированию URI, W3C/IETF (сентябрь 2001 г.). «URI, URL-адреса и URN: разъяснения и рекомендации 1.0». www.w3.org . W3C/IETF . Проверено 8 декабря 2020 г.{{cite web}}: CS1 maint: числовые имена: список авторов ( ссылка )
  18. ^ Объединенная группа по планированию URI W3C/IETF (2002).
  19. ^ «Стандарт URL: 6.3. API-интерфейсы URL-адресов в других местах» .
  20. ^ «Стандарт URL: цели» .
  21. ^ RFC 3986 (2005).
  22. ^ RFC 3986 (2005), §2.2.
  23. ^ RFC 3986 (2005), §2.3.
  24. ^ ab RFC 3986 (2005), §2.1.
  25. ^ RFC 3986 (2005), §2.
  26. ^ ab RFC 3986 (2005), §3.
  27. ^ RFC 3986 (2005), §5.2.1.
  28. ^ IETF (2015).
  29. ^ RFC 3986 (2005), §3.2.2.
  30. ^ Лоуренс (2014).
  31. ^ RFC 2396 (1998), §3.3.
  32. ^ RFC 1866 (1995), §8.2.1.
  33. ^ RFC 3986 (2005), §A.
  34. ^ RFC 3986 (2005), §4.1.
  35. ^ RFC 3986 (2005), §4.2.
  36. ^ RFC 3986 (2005), §4.4.
  37. ^ RFC 3986 (2005), §5.1.
  38. ^ RFC 3986 (2005), §5.4.
  39. ^ Уайтхед 1998, с. 38.
  40. ^ Моррисон (2006).
  41. ^ Гарольд (2004).
  42. ^ W3C (2009).
  43. ^ W3C (2006).

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

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