Uri пространства имен 1с что это
Обновлено: 08.07.2024
Цель блога описать интересные и полезные примеры программирования в системе 1С:Предприятие 8.
понедельник, 12 ноября 2012 г.
1С:Предприятие 8. Веб-сервисы. XDTO
Программист 1С, разрабатывая свой веб-сервис в большинстве случаев работает не с простыми типами, а с типами свой конфигурации, либо с типами данных другой информационной системы. Потому программист сталкивается с проблемой перевода одного типа данных в другой. Для решения этой проблемы в 1С существует механизм XDTO.
- Результат - число - результат выполнения сложения. 0 если есть ошибка;
- Ошибка - строка - "Ok" или "Передано отрицательное значение".
Для этого нам надо:
- Создать модель XDTO для нашей структуры;
- В модуле веб-сервиса создать ОбъектXDTO для для того что бы возвратить как результат функции.
На этом завершено создание пакета XDTO. Теперь можно приступить к написанию кода обработки ошибки и возврата результата веб-операции.
У нашего веб-сервиса WebService в свойство "Пакет XDTO" укажем только что созданный пакет. Иначе не сможем указать у веб-операции Plus2 тип "РезультатОперации".
Откроем свойства веб-операции Plus2 в поле "Тип возвращаемого значения" выберем тип "РезультатОперации" из пакета с пространства имен "http://codenotes-1c.blogspot.com" как на рисунке.
Этой строкой мы с помощью Фабрики XDTO в конфигурации создали ТипОбъектаXDTO, указав пространство имен пакета и имя типа.
Эта строка создает уже сам ОбъектXDTO, с которым можно уже будет работать привычным способом (обращение к реквизитам через точку). Далее мы перепишем код, добавив проверку на отрицательные значения, и код веб-операции будет выглядеть так:
Функция Plus2(Параметр)
ТипXDTOРезультатОперации = ФабрикаXDTO.Тип("http://codenotes-1c.blogspot.com", "РезультатОперации");
РезультатОперации = ФабрикаXDTO.Создать(ТипXDTOРезультатОперации);
Если Параметр < 0 Тогда
РезультатОперации.Результат = 0;
РезультатОперации.Ошибка = "Передано отрицательное значение";
Иначе
РезультатОперации.Результат = Параметр+2;
РезультатОперации.Ошибка = "Ok";
КонецЕсли;
Возврат РезультатОперации;
КонецФункции
О том как вызвать операцию веб-сервиса и просмотреть результат вы можете прочитать в статье 1С:Предприятие 8. Веб-сервисы. Публикация и тестирование
то этот тип можно использовать как тип входного параметра:
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Header/>
<soap:Body>
<soap:Fault>
<soap:Code>
<soap:Value>soap:Sender</soap:Value>
</soap:Code>
<soap:Reason>
<soap:Text xml:lang="ru_RU">Неизвестная ошибка. Ошибка проверки данных XDTO:
Значение: '-2' не соответствует простому типу: ПоложительноеЧисло
Несоответствие фасету MinInclusive = '0'
по причине:
Ошибка проверки данных XDTO:
Значение: '-2' не соответствует простому типу: ПоложительноеЧисло
Несоответствие фасету MinInclusive = '0'</soap:Text>
</soap:Reason>
</soap:Fault>
</soap:Body>
</soap:Envelope>
Таким образом используя описание ЗначенияXDTO мы можем указать ограничения к типам и не задумываться о программной обработке значений. Вы можете использовать ЗначениеXDTO в полях ОбъектаXDTO, тем самым можете создавать очень сложные структуры типов данных.
upd 09.01.2012. Это первая статья про XDTO. Продолжение здесь и здесь.
Введение
С появлением платформы 8.1 фирма “1С” представила механизм, носящий интригующее название XML Data Transfer Objects или, если коротко - XDTO. По традиции, документирование механизма составлял тот, кто хорошо разбирался в вопросе, а стало быть опустил “и так понятные” с его точки зрения моменты.
В результате, не всегда можно разобраться - что за зверь такой - XDTO. Кроме того, даже разобравшись немного и осмелев, специалисты сталкиваются с проблемами, когда начинают использовать его более активно и в более сложных сценариях. За несколько лет плотной работы с XDTO я набил массу шишек и, как мне кажется, достаточно близко подошел к постижению дао :). С моей подачи в механизме XDTO даже было исправлено несколько серьезных ошибок, нарушавших стандарты XML.
Целью данной статьи (или цикла статей, как получится) стало желание поделиться накопленным опытом. Мне кажется, многие неочевидные вещи в механизме XDTO необходимо осветить получше, чем это делает стандартная документация.
Надеюсь, что данный материал поможет специалистам, начинающим знакомство с XDTO избежать моих ошибок, а значит более эффективно решить поставленные задачи.
Кроме того, я часто сталкиваюсь с тем, что уже достаточно опытные специалисты в сфере “1С” довольно слабо знают язык XML. Как правило, в повседневной деятельности им хватает базовых знаний синтаксиса, и погружение в более сложные моменты им не нужно. Поэтому, в данной статье будут затронуты темы не только напрямую касающиеся XDTO, но и обсуждаются некоторые синтаксические моменты XML-стандартов.
Что такое XDTO
Для начала, давайте определимся - что же это за зверь такой - XDTO?
Как я уже говорил, это сокращение от XML Data Transfer Objects, что по-русски означает “XML-объекты переноса данных”.
Оказывается, это не какой-то всемирно принятый стандарт, поддерживаемый платформой 1С. Наоборот, аббревиатура XDTO родилась в недрах фирмы 1С и представляет собой ее собственный креатив. Нигде, кроме как в сфере 1С, вы не встретите данного сочетания букв.
Зачем оно надо?
Мне не ведомы истинные мотивы создания целой подсистемы, но кажется, что основная цель - это создание простой объектной модели доступа к XML документам. Причем, под объектной моделью должно пониматься не абстрактное дерево узлов XML, а именно прикладные классы данных, полезные с точки зрения бизнес-логики..
И вот эти объекты должны участвовать в таких механизмах взаимодействия, где нужно передать с машины на машину удобный для использования объект. Как пример - объекты XDTO используются для обмена с веб-сервисами.
Что в итоге?
XDTO - это механизм, разработанный фирмой “1С” для обмена данными с другими программными системами посредством XML, позволяющий на уровне языка 1С оперировать не узлами XML, а прикладными понятиями “Сотрудник”, “Счет” и привычными встроенными типами (“ТаблицаЗначений”, “СправочникСсылка” и т.п.).
Начнем знакомство
Для начала, давайте обратимся к концепции XML документа, как такового. Как правило, документ содержит некоторую структурированную информацию, которую можно условно представить в виде набора объектов. Например, документ “СписокСотрудников.xml” содержит узел “Сотрудники”, внутри которого имеются элементы с типом “Сотрудник”.
Для того, чтобы корректно прочитать данный документ, мы должны знать структуру того, как в документе расположены данные. Для этого существует такая вещь, как Схема XML. Схема XML представляет собой документ, в котором описаны все типы, которые могут встретиться в документе. Строго говоря, это не совсем точное определение схемы, но для XDTO его вполне достаточно.
Схема однозначно указывает, какие узлы и в каком порядке должны располагаться в документе. Кроме того, она представляет наборы узлов в виде функциональных типов данных, таких, как “Сотрудник”. Что еще более приятно - типы могут наследоваться и составлять иерархии типов.
А теперь, вспомним, зачем нужен XDTO - представление XML в виде объектов бизнес-логики. Если у нас будет набор бизнес-объектов, которые нужно передать по сети в виде XML, то мы можем создать XML-документ с помощью стандартного средства записи - объекта ЗаписьXML и поэлементно создать структуру, постаравшись ничего не напутать в структуре документа. Либо, мы можем создать XML-документ c помощью XDTO, используя более простой код:
Сотрудник . ФИО = “Иванов Иван Иванович” ;
Сотрудники . Добавить ( Сотрудник );
Низкоуровневые вопросы формирования XML и размещения его в документе возьмет на себя платформа.
Здесь я заранее хочу попросить прощения за такое длинное вступление у тех, кто хорошо знаком с XML и с XDTO. Мне хочется, чтобы рассказ шел от самых начал, т.к. я не могу заранее предсказать квалификацию читателя. Если все вышесказанное вам и так известно, пролистайте ниже :).
Вернемся к приведенному примеру кода. Видно, что есть некий объект сотрудник со свойством “ФИО”, которому присваивается строка. Далее этот сотрудник помещается в коллекцию. После записи коллекции, мы получим готовый XML документ, что явно проще, чем ручное создание элементов и атрибутов с помощью ЗаписьXML.
Закономерный вопрос - как платформа узнает о том, какие свойства есть у сотрудника и как его записывать в XML-файл? Ответ только один - из схемы XML документа. Платформа знает какие свойства могут быть у объекта, потому, что этот объект описан в схеме будущего документа. Закономерный вывод - XDTO без схемы документа работать не может. Система типов обязательно должна быть известна, только тогда мы сможем создавать объекты этих типов, присваивать им свойства, записывать и читать их из XML потока.
Теперь все вместе: Платформа позволяет оперировать фрагментами XML-документов, как обыкновенными объектами, к которым можно, например, обращаться “через точку”. При этом, сами объекты описываются в XML-схеме, и именно из нее платформа узнает - как выглядит тот или иной объект. То, как выглядит объект, называется типом . То есть, чтобы получить объект мы должны знать его тип .
Типы, объекты и фабрики
Пространства имен
На свете существует огромное количество программистов, которые создают те или иные XML-документы. При этом, очень часто они оперируют одинаковыми понятиями, например “Дата”, “Цена” и “Сотрудник”. Если вдруг две системы имен (созданных разными программистами) встретятся в рамках одной информационной системы, то произойдет конфликт имен.
Например, Вася создал тип данных “Сотрудник” со свойством “ФИО” и Петя создал объект "Сотрудник" со свойствами “Фамилия”, “Имя”, “Отчество” и “ИНН”. Объекты разные, а имя типа одно, возникает путаница. Чтобы этого избежать, используются пространства имен. Все имена должны быть уникальны в рамках одного пространства имен. Имена в разных пространствах запросто могут повторять друг друга.
Теперь, все типы, которые изобретет Вася, он поместит в свое пространство имен и творчество Пети ему не страшно. Всегда можно отличить одного “Сотрудника” от другого.
Типы данных
Как уже было сказано выше, тип данных обязан принадлежать пространству имен. Пространство это задается в схеме XML и однозначно определяет все типы, которые в него входят. Отсюда же следует простой вывод - тип данных всегда дополняется пространством имен, в котором этот тип нужно искать.
Модель данных и Фабрика XDTO
При построении системы типов XDTO используется понятие Модели данных . Модель представляет собой совокупность всех типов, которые можно записать в один XML документ. С понятием модели неразрывно связано понятие Фабрики XDTO. Фабрика, это объект платформы 1С:Предприятие, который позволяет создавать те самые объекты “Сотрудник”, к которым можно обращаться “через точку”. Именно фабрика создает объект встроенного языка и наделяет его свойствами “ФИО” и “ИНН”, позволяя виртуальной машине обращаться к этим свойствам. Перечень возможных типов и их свойств фабрика берет из модели данных , которая в конечном итоге представляет собой просто набор схем XML.
Что в итоге?
Представьте, что у нас есть большая система взаимосвязанных типов. Каждый тип входит в определенный логический блок типов, а блоки для удобства разнесены по разным схемам XML. Например, у нас есть блок “Коллекции”, представляющий абстрактные списки объектов и есть блок “Сотрудники”, представляющий типы объектов, описывающие сотрудников, их зарплату, должности и т.п.
Нам нужно выгрузить и передать куда-то XML документ со списком сотрудников.
Для этого, нам удобно взять тип “Список” из схемы списков и наполнить его “Сотрудниками” из схемы “Сотрудники”. В результате, наша модель типов включает в себя 2 схемы (2 пакета) типов - “Списки” и “Сотрудники”. На основании данной модели типов мы можем создать Фабрику, которая будет “строить” объекты, к которым мы сможем обращаться из встроенного языка.
Меньше слов, ближе к делу
Для того, чтобы воспользоваться механизмом XDTO нам потребуется модель типов. Модель типов - это набор схем XML, а сами схемы можно сделать любым текстовым редактором, но лучше воспользоваться специализированным инструментом.
Для разработки схем я использую Liquid XML Studio. Отличный инструмент позволяющий построить схему посредством тыкания мышкой. Я пользуюсь версией 2008, она бесплатная, но слегка глючная. Более старшие версии мощны, но за деньги.
Liquid XML Studio позволяет строить схемы в виде вот-таких картинок:
Создаваемая схема описывает типы данных, которые мы можем использовать. Обязательно задается пространство имен, которому наши типы будут принадлежать. Сами типы подразделяются на простые и составные (simple и complex). Соответственно, простые типы, это те, которые можно представить одним значением - строка, дата, булево и т.п. Составные объекты - те, которые содержат несколько значений, а стало быть одной строчкой представлены быть не могут.
В конфигураторе, каждая схема XML может быть представлена в виде ПакетаXDTO , а вся совокупность типов, имеющихся в конфигурации составляет Модель данных конфигурации. Соответственно, все типы Модели (включая созданные нами Пакеты ) могут создаваться глобальным объектом ФабрикаXDTO .
Простые типы XML представляются в виде объектов языка 1С с типом “ЗначениеXDTO”. Составные типы XML представляются в виде объектов языка 1С с типом “ОбъектXDTO”.
Подобно тому, как в конфигурации есть метаданные, предоставляющие информацию о типах, в XDTO тоже есть подобные объекты - ТипЗначенияXDTO и ТипОбъектаXDTO. Эти объекты позволяют узнать информацию о типе данных - размер, число знаков после запятой, неотрицательность и т.п.
Что со всем этим делать?
Давайте еще раз подведем краткий итог и воспользуемся полученной информацией. Итак, у нас есть 2 пакета типов (2 схемы XML). Первая - разные коллекции, списки, соответствия и т.п. Вторая - сотрудники. Нам нужно сформировать список сотрудников.
2. В конфигураторе раскрываем ветку ПакетыXDTO и в контекстном меню выбираем “Импорт схемы XML”. Указываем файлы со схемами.
3. В ветке пакетов появятся наши пакеты. Зададим им осмысленные имена (любые)
4. Теперь конфигурация “знает” о наших типах данных и они включены в модель типов конфигурации
Применение в коде
Как уже говорилось, для создания объектов XDTO применяется ФабрикаXDTO. Чтобы создать объект, фабрика должна знать его тип. Делается это следующим образом:
// Создаем объект списка
ОбъектСписок = ФабрикаXDTO . Создать ( ТипОбъектаСписок );
// Свойство “ФИО” объявлено в схеме
Сотрудник . ФИО = Выборка . Наименование ;
// Добавление “Сотрудников” в “Список”
ОбъектСписок . Добавить ( Сотрудник );
// А теперь, запись в поток XML
Запись = Новый ЗаписьXML ;
Запись . УстановитьСтроку (); // запись в строку
ФабрикаXDTO . Записать ( Запись , ОбъектСписок );
ДанныеXML = Запись . Закрыть (); // документ готов!
Резюме
На этом хочется завершить первую вводную статью. И безо всяких тонкостей она получилось довольно большой. Мы рассмотрели самые основы-основ - создание модели типов и загрузка ее в конфигурацию, а также создание XML документа на основании модели типов.
Далее мы рассмотрим программное создание модели типов, собственных фабрик, а также нюансы работы с объектами XDTO.
Если данная тема вам интересна, отпишитесь в комментариях, продолжение обязательно последует.
Цель блога описать интересные и полезные примеры программирования в системе 1С:Предприятие 8.
воскресенье, 14 октября 2012 г.
1С:Предприятие 8. Веб-сервисы. Реализация веб-сервиса
После этих действий веб-сервисом можно будет пользоваться. Таким образом будет создан веб-сервис, который сможет оперировать только простыми типами данных.Откройте конфигурацию и в дереве метаданных найдите ветку "Общие - Web-сервисы". Нажмите правой кнопкой и добавьте новый элемент.
Имя веб-сервиса можно задать русское. И платформа его сохранит и опубликует, но рекомендую использовать латиницу в названиях веб-сервисов, ws-операций, параметров ws-операций. Например, chrome не смог отобразить wsdl файл веб-сервиса с русским именем.
Перейдите на вкладку "Прочее" и укажите параметр "URI пространство имен".
В документации об этом параметре написано чуть больше чем ничего, примерно то, что это поле служит для идентификации вашего веб-сервиса. Когда я делал свой первый веб-сервис, мне казалось что это ссылка на сайт, на котором я публикую свой веб-сервис и все наименования буду получаться через запрос к этому сайту. На самом деле "URI пространство имен" не что иное как строка определяющая название набора ваших имен (названий веб-сервиса, операций, параметров, типов данных и т.д.). То есть если вы объявите свой тип "integer" то xml-парсер не будет ругаться, так как этот тип принадлежит вашему пространству имен. Мало того если "URI пространство имен" будет содержать русские символы и не будет соответствовать стандарту как формат URI, платформа все равно опубликует такой веб-сервис, и он будет работать. Но по стандартам рекомендуется использовать URI ссылку. Я советую того же самого.
Простое и понятное объяснение пространства имен можно прочитать тут.
Поле "Пакеты XDTO" не обязательное. Оно определяет набор пакетов XDTO в которых вы можете оказать свои типы значений. Это не обязательное поле, по умолчанию вам всегда доступны типы пространства имен "http://www.w3.org/2001/XMLSchema". О пакетах XDTO я расскажу чуть позже.
"Имя файла публикации", это имя файла, в котором хранятся настройки веб-сервиса для Apache(путь к базе и другие) после публикации. Папка, в которой находится этот файл, определяется при публикации. О публикации на веб-сервере будет рассказано позже.
Веб-сервис создан, но еще нет ни одной функции которую он мог бы исполнить. Надо добавить операцию. Для этого добавьте в созданный веб-сервис операцию. Нажмите не веб-веб-сервис правой кнопкой и выберите "Добавить-Операция". Она будет к вашему операнду прибавлять 2 и возвращать значение. Давайте назовем ее "Plus2". Можно указать и русское название, многие клиенты его обработают, но все же могут возникнуть проблемы.
"Тип возвращаемого значения" это тип описанный в указанном вами пакете XDTO или же тип из пространства имен "http://www.w3.org/2001/XMLSchema". Именно в этом типе веб сервис будет возвращать значение.
"Возможно пустое значение" признак что ws-операция может не вернуть значение( nillable webkit-html-attribute-value" style="font-family: monospace; font-size: 13px;">true " ).
"В транзакции" указывает что код веб-сервиса будет выполняться в транзакции. А "Режим управления блокировкой данных" определяет тип блокировки данных при транзакции по умолчанию.
Установим тип возвращаемого значения в int. В поле "Имя метода" укажем имя "Plus2" для нового метода, который будет выполнять обработку. При нажатии на лупу метод будет автоматом создан в модуле веб-сервиса.
Напишем простой код.
Функция Plus2(Параметр)
Возврат Параметр+2;
КонецФункции
Вы заметили что на входе функции у нас есть параметр "Параметр". Для того что бы в метод этот параметр был передан надо добавить его в дереве метаданных. Для этого щелкните правой кнопкой по веб-операции Plus2 и выберите "Добавить-Параметр".
Давайте назовем его "Param". Названия параметров тоже можно указывать русскими, мало того класс SoapClient языка PHP работает с ними корректно, ведь параметры передаются через массив. Желательно использовать кодировку UTF-8.
Укажем "Тип значения" int из пространства имен "http://www.w3.org/2001/XMLSchema".
Появилось таки некоторое количество времени, и я решил написать сий пост, идея которого возникла уже давно.
Связан он будет будет с такой, казалось бы, простой вещью, как URI, детальному рассмотрению которой в рунете уделяется как-то мало внимания.
"Пфф, ссылки они и в Африке ссылки, чего тут разбираться?" — скажете вы, тогда я задам вопрос:
Перед тем как начать хотел бы обозначить, что есть пост на схожую тему, в котором все обозначено проще и немного понятнее. Целью же этого поста, я ставлю более глубокое изучение вопроса и сбор информации об URI в одном месте, дабы «не потерять». Ну, почти в одном месте, статья будет разделена на две части
А для удобства бахнем оглавление, которое работает не без особенностей URI, которую мы рассмотрим попозжа, в этой статье.
Ознакомление
1. URI
Унифицированный Идентификатор Ресурса, в простонародье — URI
Самое свежее описание того, чем же все-таки являются эти пресловутые URI датируется январем аж 2005-го, а именно RFC3986, написанный самим Тимом Бёнесом-Ли, родоначальника всеми нами любимого тырнета.
Резюмируя п.1.1 можно сформулировать определение:
Многие из вас замечали, что на разных ресурсах ссылки называют то URL, то URI и, вероятно, становилось интересно — какой же из вариантов правильный?
Дело в том, что URL увидел свет и был документирован в 1990 году, в то время как URI был документирован лишь в 1994 году. И вплоть до 2002 года, до выхода RFC3305, уместными были оба варианта именования, что, порой вносило путаницу.
В п.2 RFC3305 сообщается об устаревании такого термина как URL, применимо к ссылкам, и что отныне верным будет именование URI, с того момента, во всех документах W3C использует термин URI. Исходя из этого, применяя термин URL к соответствующим ссылкам, вы не делаете смысловой ошибки, но делаете ее с точки зрения правильного именования.
Так же примечателен тот момент, что вплоть до выхода RFC2396, в 1997 году, URI расшифровывался как Universal Resource Identifier, что можно увидеть в RFC1630
- либо scheme+authority+path ,
- либо sheme+path ,
- либо только path .
1.1. Синтаксис
URI составлен из ограниченного набора символов, состоящих из цифр, букв и нескольких графических символов, все эти символы вписываются в кодировку US-ASCII (ASCII). Зарезервированное подмножество символов может использоваться, чтобы разграничить компоненты синтаксиса в URI, в то время как остающиеся символы: не зарезервированный набор и включая те зарезервированные символы, которые не действуют как разделители в данной компоненте URI, определяют данные идентификации каждого компонента.
Зарезервированные символы
-
gen-delims, они же «главные разделители», т.е. символы, разделяющие URI на крупные компоненты.
Для данного случая, согласно ABNF :
ALPHA — любая буква верхнего и нижнего регистров кодировки ASCII (в regExp [A-Za-z])
DIGIT — любая цифра (в regExp 7)
HEXDIG — шестнадцатиричная цифра (в regExp [0-9A-F])
Процентное кодирование
В случае, если используются символы выходящие за пределы кодировки ASCII используется механизм т.н. "Процентного кодирования ". Так же он применяется для передачи зарезервированных символов в составе данных. Зарезервированные символы, по правилам, не участвуют в процентном кодировании.Процентно-кодированный символ представляет из себя символьный триплет, состоящий из знака "%" и следующих за ним двух шестнадцатиричных чисел:
Т.о., %20, например, означает пробел.
1.2. Компоненты URI
-
Scheme (схема)
Каждый URI начинается с имени схемы, которое относится к спецификации для присвоения идентификаторов в этой схеме. Также, синтаксис URI — объединенная и расширяемая система именования, причем, спецификация каждой схемы может далее ограничить синтаксис и семантику идентификаторов, использующих эту схему.
Название схемы обязательно начинается с буквы и далее может быть продолжено любым количеством разрешенных символов.
Разрешенные символы для схемы:
2. URL
URL используются, чтобы определить местоположение ресурсов, обеспечивая абстрактную идентификацию расположения ресурса. Определив местоположение ресурса, система может выполнить множество операций на ресурсе, которые могут быть характеризованы такими словами как 'доступ', 'обновление', 'замена', 'поиск атрибутов'. В целом только метод доступа должен быть определен для любой схемы URL.Т. о.: URL призван решить широкий ряд задач, начиная с получения и заканчивая изменением данных на ресурсе, а обязательным параметром для получения доступа — является метод, т. е. любой полноценный (абсолютный) URL можно свести к виду:
2.1. Структура
В целом, URL имеет схожую структуру, для всех схем, хотя для каждой отдельно взятой схемы, структура может отличаться от общего шаблона.
Графически ее можно выразить в следующем виде:
-
Относительная ссылка использует иерархический синтаксис, чтобы выразить ссылку URI относительно пространства имен другого иерархического URI.
- «urn:» — обязательная, регистронезависимая часть URN
- NID — Namespace Identifier, данная компонента определяет синтаксическую интерпретацию компоненты NSS.
Минимальная длина — 2 символа, максимальная — 32, разрешенные символы:
Относительные ссылки так же делятся на несколько подвидов:
-
Ссылка сетевого пути
Имеет вид:
3. URN
Унифицированные имена ресурсов (URN) предназначены, чтобы служить постоянными, независимыми от расположения, идентификаторами ресурсов и разработаны для упрощения отображения других пространств имен (которые совместно используют свойства URN) в URN-пространство. Таким образом, синтаксис URN обеспечивает средство закодировать символьные данные в форме, которая может быть отправлена посредством существующих протоколов, записана при помощи большинства клавиатур, и т.д.
Т. е., в отличие от URL, который ссылается на како-то место, где хранится документ, URN ссылается на сам документ, и при перемещении документа в другое место ссылка не изменится.
В силу того, что URN концептуально отличается от URL, то и система разрешения имен у него другая — DDDS , которая преобразует URN в URL, по которым можно найти ресурс/объект или что бы то ни было, на что ссылается URN.
3.1. Структура
Самоидентифицирующийся URN
Такие URN содержат в NID название хэш-функции, а в NSS значение хэша, вычисленного для идентифицируемого объекта. Такие ссылки используются в magnet-ссылках и заголовках p2p-сети Gnutela2.
Например, URN из magnet-ссылки с одного торрент-трекера:
magnet:?xt=urn:btih:c68abc1ba9b8c7c4bc373862cad1a8c01d69e53d.
С теорией все, во второй части рассмотрим, что можно и что нужно делать с URI, если мы их обрабатываем, а именно — нормализация, разбор и т.д.
Читайте также: