URN

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

URN (англ. Uniform Resource Name) — единообразное название (имя) ресурса. На английский манер произносится как слово earn, по-русски чаще говорят [у-эр-э́н]. URN — это постоянная последовательность символов, идентифицирующая абстрактный или физический ресурс. URN является частью концепции URI (англ. Uniform Resource Identifier) — единообразных идентификаторов ресурса. Имена URN призваны в будущем заменить локаторы URL (англ. Uniform Resource Locator) — единообразные определители местонахождения ресурсов. Но имена URN, в отличие от URL, не включают в себя указания на местонахождение и способ обращения к ресурсу. Стандарт URN специально разработан так, чтобы он мог включать в себя другие пространства имён.

Основная идея

[править | править код]

Идея URN возникла из-за существенных недостатков системы URL. Ресурсы во Всемирной паутине и Интернете перемещаются, а ссылки в виде URL остаются, указывая на уже отсутствующие ресурсы. Старые URL также делаются бесполезными при реструктуризации ресурсов, переименовании, удалении, перемещении в другой домен DNS. Для решения этой проблемы была разработана эффективная система PURL (англ. Persistent Uniform Resource Locator — постоянный URL), сейчас широко используемая, а также система DOI (англ. Digital Object Identifier — идентификатор цифрового объекта). Но это всё же лишь частичные решения проблемы. Принципиальным же решением должен стать стандарт единообразного именования ресурсов URN.

URN указывает неизменное имя ресурса без указания его местонахождения и способа обращения. В результате URN-имена постоянны, они не зависят от конкретных серверов и протоколов. Другими словами, URN концептуально обозначает сам ресурс, а не место, где находится какой-то ресурс (а может, уже не находится), как это делает URL. Допустим, есть человек по имени Михаил Петров, который живёт в Москве по адресу ул. Земляной вал, 14. Если кто-то спросит его: «Вы кто?», он, разумеется, ответит «Я — Михаил Петров». Он ведь не скажет: «Я человек, живущий на Земляном валу, 14». Так вот, URN идентифицирует человека как «Михаил Петров», а URL лишь сообщает, что кто-то живёт по адресу ул. Земляной вал, 14 (а может, там находится и организация… URL этого не сообщает).

Для нахождения ресурсов по URN-имени нужна «система разрешения URN-имён» (англ. URN resolution). Тогда человек (или программа), знающий точный URN ресурса, введёт его в систему разрешения и немедленно получит множество конкретных мест (серверов или, скажем, интернет-магазинов), где этот ресурс можно найти. В 2002 году была предложена система DDDS (англ. Dynamic Delegation Discovery System; система динамического обнаружения ресурсов), которая разрешает имена URN в URL-ссылки на конкретные местонахождения ресурсов. При этом и URN, и URL являются частью одной системы идентификации ресурсов URI.

В 1994 году вышел запрос RFC 1737, в котором описывались концептуальные и функциональные требования к разработке URN. Сама идея URN родилась несколько раньше, но до 1994 года не была никак сформулирована. После выхода RFC 1737 было потрачено очень много времени и усилий на разработку URN. Рабочая группа URN при IETF (англ. Internet Engineering Task Force) включает в себя очень много заинтересованных сторон (включая крупные конкурирующие компании), поэтому достижение всеобщего согласия представляется очень затруднительным. Тем не менее, уже в мае 1997 года вышла спецификация RFC 2141, описывающая первую версию синтаксиса URN. Хотя разработка URN ещё далеко не завершена, и достичь консенсуса по всем вопросам пока не удалось, но базовые черты URN вырисовываются уже довольно чётко.

В 1999 году был опубликован запрос комментариев RFC 2483, который в общих чертах обрисовывал систему разрешения URN-имён. В октябре 2002 года вышла целая серия документов: RFC 3401, RFC 3402, RFC 3403, RFC 3404, RFC 3405. В этих документах определялась система разрешения URN-имён DDDS (см. выше) — последнее необходимое звено для внедрения URN. Примерно в то же время вышла и спецификация RFC 3406, уточняющая спецификацию пространств имён URN.

В настоящее время применение URN приобрело уже значительные масштабы. Имена URN стали неотъемлемой частью расширяемого языка разметки XML. Всё чаще и чаще URN реализуются в популярном программном обеспечении.

Структура URN

[править | править код]

Единообразные имена ресурсов имеют следующую структуру:

<URN> ::= "urn:" <NID> ":" <NSS>

В этой записи:

<NID>
идентификатор пространства имён (англ. Namespace Identifier); представляет собой синтаксическую интерпретацию NSS, не чувствителен к регистру.
<NSS>
строка из определённого пространства имён (англ. Namespace Specific String); если в этой строке содержатся символы не из набора ASCII, то они должны быть закодированы в Юникоде (UTF-8) и предварены (каждый из них) знаком процента «%» (подробнее см. URL).

При этом начальная последовательность символов "urn: " не чувствительна к регистру. А идентификаторы пространства имён «urn» и «URN» запрещены вообще, чтобы не возникло путаницы с этой начальной строкой "urn: ".

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

[править | править код]

Эти URN содержат в NID название хеша, используемого для их создания. NSS содержит значение этого хеша, вычисленного из данных идентифицируемого объекта (файла). Такие URN получают свойства хешей, то есть для данных может быть создано множество различных URN, но каждая URN может идентифицировать только один набор данных (файл).

Такие URN используются:

  • в составе magnet-ссылки;
  • в HTTP-заголовке X-Content-URN, предложенном в «HTTP Extensions for a Content-Addressable Web»[1] и нашедшем применение в p2p-сети Gnutella2;
  • согласно RFC 2169[2] в Gnutella2 используются URL-ссылки, которые также содержат такой URN.
NID Разрядность Кодировка Пример
tree:tiger 192 Base32 urn:tree:tiger:7N5OAMRNGMSSEUE3ORHOKWN4WWIQ5X4EBOOTLJY
sha1 160 Base32 urn:sha1:XRX2PEFXOOEJFRVUCX6HMZMKS5TWG4K5
btih 160 Base32 urn:btih:QHQXPYWMACKDWKP47RRVIV7VOURXFE5Q
ed2k 128 Hex urn:ed2k:354B15E68FB8F36D7CD88FF94116CDC1
md5 128 Hex urn:md5:834CEF60EF3FD47162420FA25ABF2DFF
md4 128 Hex urn:md4:bbd810ee7731921c4582daa00bbc531e
tiger 192 Hex urn:tiger:cf13102788e1e6ef6124cb9ca9ef879e4bb04c58fe297dd3
aich 160 Base32 urn:aich:wbtmcm2wrbndylixh3jmwsg4uowzjcqm
whirlpool 512 Hex urn:whirlpool:dc38ce741d9c8be87a0d715fad951460c5299da2447c3fa8f1057b560f9253c7a017882dcc2390ab602c3b0f5fcf066d6d35f32ffa9b8e5557e1d2f619506873
ripemd160 160 Hex urn:ripemd160:93f1cb4a43643136d730a3b94b0ebcec66928c02
gost 256 Hex urn:gost:906fd73511810bafdaa33c05b9957b07edd8dca9b6982c04a86f6c642eb6b062
has160 160 Hex urn:has160:85c292d359574b89985b2667c9725edb1c7d12fc
snefru128 128 Hex urn:snefru128:646b932fee2529db11d05425cff21978
snefru256 256 Hex urn:snefru256:35879fc03ca60db551fa26ce8be6a6a04d542cf5a635ab203f95c6f1affb59a6
  • URN книги, идентифицируемой номером ISBN
urn:isbn:5170224575
  • URN технической спецификации RFC 3406 (англ. Request For Comments — запрос комментариев, см. RFC) организации «IETF»
urn:ietf:rfc:3406
urn:oid:2.16.643
  • URN конкретного файла MP3, идентифицируемого хеш-кодом по алгоритму SHA1
urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C
  • URN, идентифицирующий ресурс через идентификатор UUID (версии 1)
urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66
  • URN конкретного файла AVI, идентифицируемого хеш-кодом по алгоритму TTH
urn:tree:tiger:SLW7H5LWXRCK3WFX5USVWIUYCOLSBTZRYGCAOJY

В показанных примерах «isbn», «ietf», «oid», «sha1», «uuid» и «tree» — это пространства имён, т. н. <NID> (см. выше), а строки за вторым двоеточием — это <NSS>.

Примечания

[править | править код]
  1. HTTP Extensions for a Content-Addressable Web. Дата обращения: 16 октября 2009. Архивировано 28 июля 2011 года.
  2. RFC2169 — A Trivial Convention for using HTTP in URN Resolution. Дата обращения: 16 октября 2009. Архивировано 21 апреля 2015 года.
  3. OID Repository. Дата обращения: 10 июня 2009. Архивировано 24 апреля 2014 года.