Идентификатор uri что это

Идентификатор uri что это

Присвоение имен и проблема постоянства

Интернет включает три вида технологий: форматы данных, протоколы и указатели, которые связывают первые два элемента. Связь между такими форматами данных, как XML и HTML, достаточно очевидна, также как и между протоколами HTTP и FTP. Но с указателями дело обстоит несколько сложнее.

Еще лет десять назад интернет-адреса были довольно загадочным предметом, а сегодня их можно видеть уже не только в Web-браузерах, но и на визитках и в брошюрах, на рекламных щитах и автобусах и даже на футболках. Они известны под названием унифицированных указателей информационных ресурсов или URL. Обычно они выглядят следующим образом: http://www.cisco.com/en/US/partners/index.html. Но как быть с более короткой формой, например, www.yahoo.com/sports? Является ли она также URL? А ../noarch/config.xsd? Или guide/glossary#octothorpe?

Для того чтобы правильно использовать URL в пространствах имен и схемах XML, а также в расширяемом языке преобразования стилей (Extensible Stylesheet Language Transformations — XSLT), нужно знать некоторые правила. Но семейство спецификаций XML оперирует такими понятиями, как URI и URN. Чем же они отличаются от URL? Этот вопрос имеет довольно долгую историю.

В 1990 г. пионер компьютерных сетей и гипертекста Дуглас Энгелбарт (Douglas Engelbart) среди прочих требований к открытой системе гипердокументов называл и необходимость того, чтобы "каждый объект, на который кто-либо захочет или должен будет сослаться, имел однозначный адрес". Тим Бёнез-Ли (Tim Berners-Lee), изобретатель интернета, в 1991 г. указывал в своем конструкторском документе о присвоении имен:

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

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

Стандарт URI

Документ RFC3986, "Универсальный идентификатор ресурсов (URI): общий синтаксис" — это стандарт интернета. Так называемая серия "Запросы на комментарии" (Request for Comments — RFC) — это известная серия архивных документов, которая является основой процесса разработки стандартов в Проблемной группе проектирования Internet (Internet Engineering Task Force — IETF). Только несколько из тысяч документов RFC, такие как протокол управления передачей (Transmission Control Protocol — TCP) и почтовый формат (RFC821) и протокол (RFC822) интернета получили полный статус стандартов интернета. RFC3986 получил этот статус в январе 2005 г.

Согласно стандарту URI, первый из вышеприведенных примеров — http://www.cisco.com/en/US/partners/index.html является настоящим URI и включает несколько составляющих его частей:

  • имя схемы ( http )
  • имя домена ( www.cisco.com )
  • путь ( /en/US/partners/index.html )

Непротиворечивый процесс IETF управляет схемами. Официальный реестр схем URI Агентства по выделению имен и уникальных параметров протоколов Internet (Internet Assigned Numbers Authority — IANA) включает как общеизвестные схемы, такие как http , https и mailto , так и множество других, менее знакомых широкому кругу пользователей.

URI-путь выглядит как типичный путь доступа к файлу. URI унаследовали левую косую черту ( a/b/c ) из традиций UNIX®, поскольку в конце 1980-х годов, когда они разрабатывались, в интернете преобладала культура UNIX, а не PC. Тогда существовало несколько распространенных представлений для доступа к удаленным файлам. Одно из них — это Ange-ftp, расширение emacs для редактирования удаленных файлов. Оно сводило воедино имена хост-узла и пользователя с путем доступа к файлу, и в результате получалась конструкция такого типа: /jbrown@freddie.ucla.edu:

mblack/ . Синтаксис URI, разработанный для интернета, использовал двойную левую косую черту для перекрестного обращения к машинам (это унаследовано из диалекта Apollo Domain UNIX). Помимо этого, он ввел в обращение синтаксис схем для того, чтобы можно было унифицировать соглашения о присвоении имен из любого количества различных протоколов. Вот несколько примеров:

Второй пример во введении, www.yahoo.com/sports, на самом деле не является настоящим URI. Это удобное сокращение для http://www.yahoo.com/sports. Такой формат поддерживается пользовательскими интерфейсами распространенных Web-браузеров. Но если схема XSLT записана следующим образом:

то она не будет работать, как ожидается, если только это выражение не является обращением к файлу в директории exslt.org , находящейся рядом с таблицей стилей XSLT. Атрибут href в XSLT означает URI-ссылку, которая может быть абсолютной или относительной. Если URI-ссылка начинается со схемы и двоеточия, то она является абсолютной, в противном случае — относительной. Относительная URI-ссылка очень похожа на путь доступа к файлу. Например, ../noarch/config.xsd — это относительная URI-ссылка.

Международные идентификаторы ресурсов

Сказать, что атрибут href в HTML означает URI-ссылку, — это несколько упростить ситуацию. URI и URI-ссылки создаются из ограниченного набора символов ASCII, а HTML является более интернациональным образованием. Запрос на комментарии, который последовал за запросом RFC3986, — это запрос RFC3987 "Международные идентификаторы ресурсов (IRI)" (Internationalized Resource Identifiers (IRIs) ( см. раздел Ресурсы ). Эта спецификация не является единственной в процессе разработки IETF-стандартов, в отличие от своей предшественницы, но данная технология уже достаточно зрелая и широко используется. IRI очень похожи на URI с тем исключением, что в них может использоваться весь набор символов Unicode, а не только ASCII. Для каждого IRI существует соответствующая кодировка в формате URI на тот случай, если идентификатор нужно будет использовать в протоколе (например, HTTP), который может работать только с URI.

Читайте также:  Сколько можно заработать на ютубе за месяц

Xml:base перекрывает базовый URI

Обычно ссылка URI является относительной для любого документа, в котором она найдена. Если, например, просматривается документ с базовым URI http://exslt.org/math/min/math.min.template.xsl , и в нем обнаруживается URI-ссылка ../../random/random.xml , то она приведет к документу с адресом http://exslt.org/random/random.xml . В формате HTML есть возможность вынести базовый элемент в заголовок документа, чтобы перекрыть базовый URI. Базовая спецификация XML (XML Base) (см. раздел Ресурсы ) обеспечивает эквивалентную форму в XML.

Рассмотрим документ, доступ к которому может быть осуществлен двумя путями: file:/my/doc или http://my.domain/doc . Если доступ выполняется через файловую систему, то ссылки типа #part2 расширяются до формата file:/my/doc#part2 . В случае доступа через HTTP данная ссылка расширится до формата http://my.domain/doc#part2 . Но в схеме описания ресурсов (Resource Description Framework — RDF) расширенная форма не должна изменяться для того, чтобы обеспечить выполнение ряда задач. Спецификация XML Base облегчает выполнение расширения (см. Листинг 1).

Листинг 1. Расширенная форма в RDF

В этом примере ссылка #Nothing расширяется до http://www.w3.org/2002/07/owl#Nothing независимо от места нахождения документа.

Теперь перейдем к URL и URN.

URL и URN

URI разработаны таким образом, чтобы выполнять функции и имени, и адреса. После того, как они поступили в IETF для стандартизации, их стали именовать унифицированными указателями информационных ресурсов (Uniform Resource Locators); одновременно началась работа над разработкой унифицированных имен ресурсов (Uniform Resource Names).

Для имен и ресурсов интернет-хостов существуют отдельные стандарты. Синтаксис имен хостов такой же, как и имен доменов (например, zork1.example.edu ). Эти имена связаны с адресами типа 192.168.300.21 с помощью протокола системы имен домена (Domain Name System — DNS). Такая непрямая связь позволяет именам оставаться стабильными, когда хосты перемещаются в сети и их нумерация изменяется.

Случайные неработающие ссылки в интернете приводят к тому, что Web-адреса становятся больше похожими на указатели, а не на имена, поэтому в сообществе IETF возникли различные предложения:

  • URI: запрос RFC1630, выпущенный в июне 1994 г., был назван "Универсальные идентификаторы ресурсов в WWW: единый синтаксис для выражения имен и адресов объектов в сети, используемый во Всемирной сети Интернет" (Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web) ( см. раздел Ресурсы ). Это был информационный запрос, т.е. он не получил общего одобрения IT-сообщества;
  • URL: запрос RFC1738, выпущенный в декабре 1994 г., был назван "Унифицированные указатели информационных ресурсов" (Uniform Resource Locators) ( см. раздел Ресурсы ). Это был предлагаемый стандарт, т.е. он являлся результатом согласований, хотя еще и не был в достаточной степени проверенным и зрелым, чтобы стать стандартом для всего интернета;
  • URN: запрос RFC1737, выпущенный в декабре 1994 г., был назван "Функциональные требования для унифицированных имен ресурсов" (Functional Requirements for Uniform Resource Names) ( см. раздел Ресурсы ).

В 1997 г. за запросом RFC1737 последовал предлагаемый стандарт RFC2141 — "Синтаксис URN", который описывал спецификацию еще одной схемы — urn: , в дополнение к уже существовавшим http: , ftp: и другим.

Окончательный стандарт URI RFC3986 объясняет различие между этими понятиями в секции 1.1.3 — "URI, URL и URN":

URI может далее рассматриваться как указатель, имя или и то, и другое. Термин "унифицированный указатель информационных ресурсов" (URL) относится к подмножеству URI, которые, помимо идентификации ресурса, указывают способ его нахождения путем описания основных механизмов доступа к нему (т.е. его "положение" в сети). Термин "унифицированное имя ресурса" (URN) исторически использовался как для URI в пределах схемы urn (запрос RFC2141), которые должны оставаться уникальными в мировом масштабе и оставаться стабильными, даже если ресурс прекращает существование или становится недоступным, так и для любых других URI со свойствами имени.

Отдельная схема не обязательно должна рассматриваться только как "имя" или "указатель". Конкретные URI из любой схемы могут иметь характеристики как имен, так и указателей, или обоих этих понятий. Часто это зависит от постоянства и тщательности в распределении идентификаторов полномочным органом по присвоению имен, а не от качества схемы. В будущих спецификациях и связанных с ними документах должен использоваться общий термин URI, а не более узкие понятия URL и URN (запрос RFC3305).

Постоянство на практике

Между постоянством и доступностью существует естественное противоречие. Предположим, на каком-то хосте, связанном с интернетом, есть некий файл. Самый простой способ сделать этот файл доступным — подключить к хосту Web-сервер и предоставить пользователю URI, который состоит из имени хоста и файла (например, http://dhcp324.coolISP.net/drafts/freeLunch.wsdl ). Такая схема будет отлично работать, пока не закончится срок лицензии протокола динамической конфигурации хоста (Dynamic Host Configuration Protocol — DHCP), не изменится провайдер или файл не будет перемещен в другую директорию. А если сервис станет популярным и за пользование им будут взимать плату? Чем менее достаточную информацию содержит имя, тем ниже его шансы уцелеть при изменениях.

Читайте также:  Как форматировать флешку если она не форматируется

Но хорошее постоянное имя, подобное http://xyzpdq.org/2005/ls434 , не так легко поддерживать. Необходимо зарегистрировать домен, осуществлять отображение имени домена на адрес хоста и либо держать в памяти, что ls434 — это файл с описанием предложений ланча, либо сделать таблицу отображения файлов на Web-сервере.

Проект PURL и система идентификации цифровых объектов (Digital Object Identifier — DOI) ( см. раздел Ресурсы ) представляют другие подходы к проблеме постоянства. Постоянный URL (persistent URL — PURL) — это обыкновенный HTTP URI домена, который обеспечивается серьезной поддержкой его постоянства. Например, домен purl.org поддерживается Центром интерактивной компьютерной библиотеки (Online Computer Library Center — OCLC) — всемирным библиотечным кооперативом. Любой может подать заявление о выделении адреса и управлять своим собственным набором PURL. Желающий помещает свои материалы на обыкновенный Web-сервер, а затем связывает его со своим PURL путем перенаправления с помощью HTTP. Перенаправление от PURL на менее постоянные HTTP URI во многом похоже на аналогичный процесс, обеспечиваемый DNS. Разница состоит в том, что в этом случае и источник, и место назначения перенаправления относятся к одной и той же категории. Любой PURL, например, http://purl.org/net/dajobe/ , может использоваться как обыкновенный HTTP URI. И что еще более важно, те люди, с которыми необходимо установить сообщение, также могут использовать его как обыкновенный HTTP URI; при этом не требуется никаких подключаемых программ или расширений.

Система DOI использует свою собственную схему, например, doi:10.123/456 . Web-браузеры могут быть приспособлены к поддержке этой схемы с помощью подключаемой программы. Фонд DOI обеспечивает стандарты, регистрацию и услуги по перенаправлению HTTP, подобно тому, как это делают провайдеры PURL, например, OCLC. Хотя Фонд DOI поддерживает специальное имя для каждого DOI в форме http://dx.doi.org/10.123/456 , в руководстве по DOI ( см. раздел Ресурсы ) утверждается, что эта система имеет "существенные недостатки по сравнению с подключаемой программой распознавателя". Но с точки зрения автора статьи, гораздо более существенный недостаток — это необходимость поддержки двух разных имен для каждого объекта.

Творческие проблемы в управлении информацией

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

Сторонники схемы urn: утверждают, что данное противоречие нельзя устранить в рамках HTTP и DNS. Проблемные области, безусловно, существуют, но с этими вопросами сталкивается любой Web-мастер, и постепенно вырабатываются принципы управления информацией, которые помогают справляться с ними. Мир постоянно меняется, и чтобы успевать за этими изменениями, необходимо работать.

В большинстве случаев иерархическая природа системы присвоения имен DNS достаточно удобна, но это приводит к концентрации большого количества энергии в одном месте и вызывает существенные управленческие проблемы. Системы соединения равноправных узлов, такие как распределенные равнодозированные таблицы (хэш-таблицы — hash tables), могут решить некоторые вопросы централизации, свойственные DNS, но никто не знает, к каким проблемам управления может привести их использование. Различные передовые разработки показывают, как новые протоколы могут использоваться для обслуживания уже имеющихся имен типа http://. , повышая ценность существующей сети гипермедиа. Эти технологии кажутся более перспективными, чем разработка новых схем для любых действий, отдаленно напоминающих операции HTTP типа GET/PUT/POST/DELETE (доставить/поместить/вывесить/убрать). По прогнозу автора статьи, современная передовая практика в управлении информацией, а также дальнейшее улучшение протоколов обеспечат продолжительное существование URI на основе HTTP и DNS.

Ресурсы для скачивания

Похожие темы

  • Оригинал статьи: "Untangle URIs, URLs, and URNs"
  • Дуглас Энгелбарт (Douglas Engelbart). 1990. Совместимость областей знаний и система открытых гипердокументов. Обзор исследований возможностей совместной работы с помощью компьютеров (computer-supported cooperative work — CSCW). "Knowledge-Domain Interoperability and an Open Hyperdocument System."
  • Присвоение имен документам Document Naming. Тим Бёнез-Ли (Tim Berners-Lee). Вопросы проектирования Design Issues. Серия, начатая в 1991 г. и продолжающаяся по сегодняшний день.
  • Проблемная группа проектирования Internet Internet Engineering Task Force (IETF). Запросы на комментарии, изданные IETF и обсуждаемые в настоящей статье:
  • RFC1630 — Универсальные идентификаторы ресурсов в WWW RFC1630 — "Universal Resource Identifiers in WWW"
  • RFC1737 — Функциональные требования для унифицированных имен ресурсов RFC1737 — "Functional Requirements for Uniform Resource Names"
  • RFC1738 — Унифицированные указатели информационных ресурсов RFC1738 — "Uniform Resource Locators" (Версиягипертекстаможет быть найдена на сайте W3C)
  • RFC2141 — Синтаксис URN RFC2141 — "URN Syntax"
  • RFC3305 — Отчет специальной совместной группы W3C и IETF по планированию URI: URI, URL и URN RFC3305 — "Report from the Joint W3C/IETF URI Planning Interest Group: URIs, URLs, and URNs"
  • RFC3986 — Базовый синтаксис унифицированных указателей информационных ресурсов RFC3986 — "Uniform Resource Identifier (URI): Generic Syntax". Также доступна версия гипертекстовая версия Роя Филдина (Roy Fielding);
  • RFC3987 — Международные указатели информационных ресурсов RFC3987 — "Internationalized Resource Identifiers (IRIs)"
Читайте также:  Когда выйдет новый fallout
  • Агентство по выделению имен и уникальных параметров протоколов Internet Internet Assigned Numbers Authority (IANA) и его официальный список схем URI.
  • сайт проекта PURL и его страница PURL FAQ.
  • Система DOI The DOI System и глава из "Руководства по DOI", посвященная разрешающей способности.
  • Разделы сайта W3C, посвященные XML-схеме, пространству имен XML и основе XML.
  • Статья Уче Огбуйи (Uche Ogbuji) "Принципы XML-дизайна: осторожность при использовании пространства имен XML" и его "Начальный обзор XML-стандартов" .
  • Дополнительные ресурсы на сайте IBM в разделе XML developerWorks Россия .
  • Книги по этой теме и другим Developer Bookstore
  • Информация о том, как стать Сертифицированным разработчиком IBM в области XML и других смежных технологий IBM Certified Developer in XML and related technologies.
  • Комментарии

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

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

    URI расшифровывается как Uniform Resource Identifier, что переводится на русский язык как "унифицированный идентификатор ресурса". Зачастую не совсем корректно эту аббревиатуру расшифровывают как Universal Resource Identifier, то есть, универсальный идентификатор ресурса. Нельзя сказать, что такая расшифровка является в корне неверной — скорее, её можно считать устаревшей. URI — это некоторая строка, которая позволяет однозначно идентифицировать какой-то ресурс, не важно, является он виртуальным или реальным. Примерами виртуальных ресурсов являются web-страницы, электронные почтовые ящики; реальных — книги, которые идентифицируются номером ISBN.

    Идея URI возникла, в основном, как развитие и расширение системы URL. В связи с этим основные принципы URI были сформулированы таким образом, чтобы обеспечить полную совместимость со стандартами URL. Соответственно, URI "в наследство" достались и такие недостатки URL, как невозможность записи адреса с помощью символов национальных алфавитов и символов в кодировке Unicode, которые должны кодироваться строками вида "%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D0%BA%D1%80%D0%B5%D0%B4%D0%B8%D1%82". Эту проблему призван решить новый стандарт — IRI, International Resource Identifier, или международный идентификаторов ресурсов. Идентификаторы IRI должны решить вопрос применения символов национальных алфавитов в идентификаторах, хотя многие эксперты высказывают сомнения по поводу возможности глобальной замены одних идентификаторов на другие, постепенный переход на международный формат все-таки осуществляется.

    В отличие от классического URL, URI не описывает, как получить ресурс, а только идентифицирует его. Дело в том, что, в отличие от URL, который сразу ведет к какому-то web-ресурсу, URI может идентифицировать и такие объекты, как дома, автомобили и другие вещи, которые невозможно получить через Интернет. Такие ресурсы, тем не менее, можно описывать с использованием RDF и получать к ним доступ через URI.

    Отличие URI от URL
    URI не всегда указывает то, как получить ресурс, в отличие от URL, а только идентифицирует его.

    URL (URL частный случай URI прим. мну)
    Единый указатель ресурсов (англ. URL — Uniform Resource Locator) — единообразный локатор (определитель местонахождения) ресурса. Ранее назывался Universal Resource Locator — универсальный локатор ресурса. URL — это стандартизированный способ записи адреса ресурса в сети Интернет.

    Общепринятые схемы (протоколы) URL включают:
    ftp — Протокол передачи файлов FTP
    http — Протокол передачи гипертекста HTTP
    https — Специальная реализация протокола HTTP, использующая шифрование (как правило, SSL или TLS)
    gopher — Протокол Gopher
    mailto — Адрес электронной почты
    news — Новости Usenet
    nntp — Новости Usenet через протокол NNTP
    irc — Протокол IRC
    prospero — Служба каталогов Prospero Directory Service
    telnet — Ссылка на интерактивную сессию Telnet
    wais — База данных системы WAIS
    xmpp — Протокол XMPP (часть Jabber)
    file — Имя локального файла
    data — Непосредственные данные (Data: URL)

    Ссылка на основную публикацию
    Звуковая карта с usb выходом
    Please complete the security check to access www.bigtv.ru Why do I have to complete a CAPTCHA? Completing the CAPTCHA proves...
    Задача числа фибоначчи python
    Ряд чисел Фибоначчи представляет собой последовательность. Первый и второй элементы последовательности равны единице. Каждый последующий элемент равен сумме двух предыдущих....
    Задачи на вращательное движение с решениями
    Поскольку угловое перемещение φ, угловая скоростьи угловое ускорение связаны между собой так же, как и соответствующие им линейные величины,,, то...
    Звуковой генератор для андроид
    Простой и удобный генератор звуковых сигналов (частотный генератор) для Андроид. При помощи этого приложения вы сможете проверить динамики своего телефона,...
    Adblock detector