Отсутствует в строке uri ubuntu

Обновлено: 06.07.2024

Из того, что я могу собрать, .desktop файлы являются ярлыками, которые позволяют настраивать параметры приложения. Например, у меня их много в моей /usr/share/applications/ папке.

Если я открою эту папку в nautilus , я могу запустить эти приложения, просто дважды щелкнув соответствующий файл, например, дважды щелкнув, firefox.desktop запустит Firefox. Тем не менее, я не могу найти способ сделать то же самое через терминал.

Это мой вопрос, как мне запустить foo.desktop файл из терминала?

NB. Причина, по которой вы exec потерпели неудачу, заключается в том, что exec заменяет ваш текущий запущенный процесс указанным вами процессом, поэтому вы попытались заменить вашу оболочку запуском рабочего стола в виде скомпилированного двоичного файла. Причина, по которой вы не смогли этого сделать, sudo exec заключается в том, что это встроенная оболочка, а не двоичная команда. Интересно, мне было интересно, почему это привело к закрытию вкладки. Я вижу, они заканчивают анализом файла .desktop. В любом случае спасибо за ссылку. модераторы: ой, думаю, что я мог отметить это случайно, извините, если это так

Команда, которая выполняется, содержится в файле рабочего стола, перед которым стоит, Exec= чтобы вы могли извлечь и запустить ее:

Чтобы сломать это

Вы можете поместить это в файл, скажем,

/bin/deskopen с содержанием

Затем сделайте его исполняемым

И тогда вы могли бы сделать, например,

На данный момент я добавил секунду, sed чтобы удалить любые аргументы. Но я думаю, что может быть более «естественный» способ запустить его. Я обновил свой ответ дополнительным sed - я забыл, что файлы рабочего стола могут иметь аргументы. Вы должны добавить «tail -1» в канал после «grep», поскольку «Exec =» может появляться несколько раз, и после этого должно выполняться только последнее появление. -1: Это может работать для простых .desktop файлов, но он игнорирует записи , как Path= и TryExec= которые могут повлиять на исполнение. Он также выполняется неправильно, Exec= если файл содержит Действия на рабочем столе («

Ответ должен быть

Но из- за ошибки это больше не работает.

WoW это все еще ошибка, много прогресса в xdg. exo-open указан как обходной путь, и он также открывает Gedit. :( @RichardHolloway: gnome-open никак не назвать xdg-open , это наоборот! Таким образом, проблема заключается в gvfs-open (преемник или gnome-open ) "больше не работает"? Такого никогда не было! xdg-open работы ассоциации mimetype, а .desktop файлы связаны с текстовыми редакторами, поскольку они являются подклассом текста это настолько глупо (что нет разумного способа запустить файл рабочего стола из терминала) У меня работает на Arch Linux, но, возможно, это ошибка, специфичная для Ubuntu.

С любой недавней Ubuntu, которая поддерживает gtk-launch просто перейти

gtk-launch <file> где имя файла .desktop с или без .desktop детали

Так gtk-launch foo открывается foo.desktop

.Desktop должен находиться в / usr / share / Applications, / usr / local / share / application или

/ .local / share / Applications

Используется из терминала или alt + F2 (команда alt + F2 хранит историю, поэтому легко доступна)

/ .local / share / Applications / запускает Firefox, просматривая каталог

/ .local / share / Applications / для меня. Кажется, если вы были правы, Firefox не должен был передаваться каталог файла .desktop в качестве аргумента. Фактически, каталог, переданный в gtk-launch, не должен использоваться для поиска каталога, содержащего файл .desktop (и на самом деле это не так)

Никакая версия этого не работает для меня в Ubuntu 18.10. Каждый раз, когда он жалуется, приложение не существует, нахожусь ли я в папке с файлом рабочего стола или нет, включаю ли я расширение .desktop или нет, и я отдельно называю каталог или нет.

На сегодняшний день (12.10) ошибка все еще присутствует. На самом деле это зависит от того, как gvfs-open ( вызывается xdg-open ) работает.

Тем не менее, мне удалось быстро обойти (украсть вдохновение из исходного кода nautilus). Это немного запутанно, но работает безупречно на Ubuntu 12.10, добавляя значащий значок (не более ? ) на панели запуска Unity.

Во-первых, я написал скрипт на Python с использованием Gio и поместил его в файл

Сценарий должен иметь разрешение на выполнение, поэтому я запустил его в терминале:

Затем я создал относительную .desktop запись на

Наконец -то я связывал запись в качестве обработчика по умолчанию в

/.local/share/applications/mimeapps.list соответствии с [Default Applications] сечением в виде:

В настоящее время:

Это будет бесполезная работа, когда gvfs-open решит ошибку, а пока .

Это работает лучше, чем ответ Хэмиша Даунера, поскольку он будет правильно обрабатывать несколько Exec= строк и % параметров в команде. Спасибо за код - я на Lucid, и я просто сохранил это как /usr/bin/xdg-openpy , и дал его chmod +x - и использовал launcher.launch([],context) вместо . None,context) (из-за " TypeError: аргумент 1: Должен быть последовательность, а не NoneType "). Теперь xdg-openpy app.desktop работает из командной строки (и все как обычно при двойном щелчке app.desktop ), и это может напомнить мне, если я попытаюсь позвонить в терминал xdg-open и нажать Tab. Ура! +1. Это единственный ответ, который не требует ручного анализа .desktop файла, поэтому это наиболее разумный (и безопасный) подход. Также использует современные gi.repository вместо устаревших pygtk , так здорово! :) На самом деле, это вопрос, касающийся ответа Карло Пеллегрини. Я новичок, пожалуйста, поправьте меня, если есть лучший способ разместить его. Сценарий работает очень хорошо, но значок, который я получаю на панели запуска Unity, - это не значок, определенный в файле .desktop, а значок по умолчанию для команды «Exec». Есть идеи по этому поводу? @Noitidart написать последний ответ привел Мо сделать Google, и я нашел это . Не проверил это, но, возможно, это поможет

Вы должны действительно использовать, gtk-launch если это доступно. Обычно это часть пакета libgtk-3-bin (это может отличаться в зависимости от дистрибутива).

gtk-launch используется следующим образом:

Обратите внимание, что для установки gtk-launch требуется файл .desktop (т. Е. Он находится в /usr/share/applications или

Таким образом, чтобы обойти это, мы можем использовать маленькую хакерскую функцию Bash, которая временно устанавливает нужный файл .desktop перед его запуском. «Правильный» способ установки файла .desktop - через, desktop-file-install но я собираюсь игнорировать это.

Вы можете использовать его следующим образом (а также передавать дополнительные аргументы или URI, если хотите):

Если вы хотите вручную проанализировать и выполнить файл .desktop , вы можете сделать это с помощью следующей awk команды:

Вышеупомянутые команды будут:

Найти строку, начинающуюся с Exec =
Удалить Exec =
Удалите все переменные Exec (например %f , %u , %U ). Их можно заменить позиционными аргументами, как это предусмотрено в спецификации, но это может значительно усложнить проблему. См. Последнюю спецификацию входа на рабочий стол .
Выполнить команду
Немедленно завершите работу с соответствующим кодом выхода (чтобы не выполнять несколько строк Exec )

Обратите внимание, что этот сценарий AWK обращается к нескольким крайним случаям, которые могут или не могут быть должным образом рассмотрены некоторыми другими ответами. В частности, эта команда удаляет несколько переменных Exec (стараясь не удалять символ% в противном случае), будет выполнять только одну строковую команду Exec и будет вести себя так, как ожидается, даже если строковая команда Exec содержит один или несколько знаков равенства (например, script.py --profile=name ).

Еще несколько предостережений . Согласно спецификации, TryExec это:

Путь к исполняемому файлу на диске, который используется для определения, установлена ли программа на самом деле. Если путь не является абсолютным, файл ищется в переменной среды $ PATH. Если файл отсутствует или не является исполняемым, запись можно игнорировать (например, не использовать в меню).

Имея это в виду, не имеет смысла выполнять его значение.

Некоторые другие проблемы - Путь и Терминал . Путь состоит из рабочего каталога, в котором запускается программа. Terminal - логическое значение, указывающее, выполняется ли программа в окне терминала. Все это может быть решено, но нет смысла изобретать велосипед, поскольку уже есть реализации спецификации. Если вы хотите реализовать Path , имейте в виду, что он system() порождает подпроцесс, поэтому вы не можете изменить рабочий каталог, выполнив что-то подобное system("cd \047" working_directory "\047"); system(command) . Однако вы могли бы предположительно сделать что-то вроде system("cd \047" working_directory "\047 && " command) . Примечание \ 047 - одинарные кавычки (поэтому команда не разбивается на пути с пробелами).

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

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

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

Я создал собственный обработчик схемы URI в RedHat Linux, и он работал как положено. Когда пользователь перенаправляется на пользовательский URI, например: myapp://abcd браузер открывает всплывающее окно запуска приложений, подобное mailto: handler.

Нелегко было сделать подобные шаги в Ubuntu, я попробовал все возможные решения, но ни одно из них не сработало.

Вот что я сделал для RedHat, который работал отлично:

Добавить запись в

Добавьте myprotocol-handler.desktop в

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

Я попробовал следующие места:

Ни один из подходов не работает, как ожидалось. Может кто-нибудь указать мне правильное направление, моя версия Ubuntu 16.04.4

Я пробовал вышеуказанные шаги на Ubuntu, и он не работает

Если бы мне пришлось угадывать, я бы сказал, что ваш рабочий стол не может быть исполняемым файлом.

Кроме того, я вижу сразу несколько других проблем:

Вы регистрируете myapp схема или myprotocol схема?

Вы упоминаете оба из них, и это несколько сбивает с толку, какие именно URL вы хотите открыть.

Я предполагаю, что вы хотите использовать myprotocol схема, например myprotocol://abcd ,

Запись "Exec" вашего рабочего стола.

$HOME/ не нужно, если .my-handler.sh в вашем $PATH ,

sh -c не нужен, если ваш скрипт исполняемый, так как в верхней части он содержит строку shebang. Это также добавляет еще один уровень сложности, поскольку все URL-адреса будут расширяться оболочкой до того, как они попадут в сценарий вашего обработчика URL-адресов.

Вам не нужно делать это скрытым файлом; имя файла как my-handler.sh будет хорошо. Поскольку я сомневаюсь, что ваш домашний каталог находится в $PATH нет никакого преимущества в том, чтобы поместить его в свой домашний каталог, кроме как сделать абсолютный путь немного короче. (Подробнее о $PATH ниже.)

Ваш шебанг будет работать на Ubuntu:

Вы используете неинициализированную переменную "$code" и добавляете ее в файл с именем file , Какова цель этого? поскольку file это относительный путь, это будет зависеть от рабочего каталога, что, вероятно, не то, что вы хотите. (Для URL-адресов, запущенных из Firefox, это будет зависеть от того, из какого каталога был запущен браузер, который может быть домашним каталогом, но также может быть где-то еще).

Но, возможно, это всего лишь сценарий-заполнитель, и это было сделано намеренно? Если это так, я бы предложил этот тестовый скрипт вместо:

так что вы можете увидеть переданный URL и каталог, из которого он запущен.

Обработчик схемы работает только для xdg-open команда не работает, если я пытаюсь использовать тот же URI в браузере.

Если xdg-open работает, тогда это просто вопрос настройки браузера. Исходя из ваших комментариев, похоже, что вы используете Firefox, который обрабатывает это в Предпочтения:

Приложения
Выберите, как Firefox обрабатывает файлы, которые вы загружаете из Интернета, или приложения, которые вы используете при просмотре.

Это хранится в handlers.json , как вы упоминаете.

Если xdg-open уже работает, это не должно быть проблемой, но одна хитрость в пользовательских обработчиках URL заключается в том, что существует как минимум четыре файла, в которых могут храниться ассоциации, в зависимости от приложения / библиотеки, которую использует приложение:

Мы рассмотрим этот вопрос ниже.

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

Протестируйте скрипт напрямую.

Вам может понадобиться сделать его исполняемым, например так:

Затем используйте пример URL:

Исправьте все проблемы здесь, прежде чем продолжить.

Добавьте скрипт в свой $PATH поэтому файл рабочего стола может найти его.

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

Я использую bin каталог, как это:

и добавить это к

и, наконец, либо скопируйте скрипт, либо

Если вы сделали это правильно, вы должны что-то похожее на это:

Установите файл рабочего стола.

Похоже, вы уже сделали это, но для дальнейшего использования вы можете использовать desktop-file-install команда от desktop-file-utils пакет:

Это самые важные строки в файле рабочего стола:

Убедитесь, что файл рабочего стола является исполняемым.

Сделайте это так:

Зарегистрируйте файл рабочего стола с помощью x-scheme-handler/myprotocol MimeType.

Все, что на самом деле делает, это меняет строки в

/.config/mimeapps.list под [Default Applications] группа так говорит это:

Некоторые старые приложения используют

/.local/share/application/mimeapps.list , но это официально не рекомендуется. Однако xdg-mime Команда все равно использует это местоположение:

Существует также еще более устаревший файл, который называется defaults.list это все еще используется некоторыми приложениями. Отредактируйте этот файл с помощью текстового редактора:

и вручную добавьте эти строки:

под [Default Applications] группа.

Проверьте xdg-mime также.

Проверьте некоторые URL-адреса из командной строки.

Теперь протестируйте тот же URL с xdg-open :

Обновите кеш mimeinfo.

Некоторые приложения читают

/.config/mimeapps.list , Итак, обновите кеш:

Протестируйте его в браузере с локальным HTML-файлом.

При первом открытии ссылки Firefox предложит вам найти файл рабочего стола.

/.local/share/applications/ и нажмите myprotocol-handler.desktop ,

Также установите флажок "Запомнить мой выбор для моих протокольных ссылок".

Это должно выглядеть так, когда вы закончите.

Протестируйте его в браузере с помощью удаленного HTML-файла.

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

Я сталкивался с несколькими инструкциями по установке, которые включают команду deb . Но похоже, что эта команда недоступна в моей установке.

Где я могу получить эту команду? Есть ли обходной путь?

Примите ответ на вопросы, на которые у вас есть хороший ответ, чтобы показать, что вам нравится ответ, и он вам больше всего помог. Вы можете сделать это с галочкой слева. Меня смущает, что я не осознавал, что инструкции, которые я читал, не показывал мне что-то, что нужно напечатать в командной строке, это показывало мне строку для вставки в файл. Я рад, что вы задали этот вопрос!

'deb' не является командой Он используется в /etc/apt/sources.list файле для обозначения репозитория программного обеспечения Debian.

Список источников предназначен для поддержки любого количества активных источников и различных источников мультимедиа. В файле указывается один источник в строке, причем наиболее предпочтительный источник указан первым. Формат каждой строки: введите uri args. Первый элемент type определяет формат для аргументов. uri - это универсальный идентификатор ресурса (URI), который представляет собой расширенный набор более конкретного и известного универсального указателя ресурса или URL-адреса.

Тип deb описывает типичный двухуровневый архив Debian, дистрибутив / компонент. Формат записи sources.list с использованием типов deb и deb-src:

URI для типа deb должен указывать базу дистрибутива Debian, из которой APT найдет нужную ему информацию. В распределении можно указать точный путь, в этом случае компоненты должны быть пропущены, а распространение должно заканчиваться косой чертой (/). Это полезно для случая, когда интерес представляет только конкретный подраздел архива, обозначенный URI. Если в распределении не указан точный путь, должен присутствовать хотя бы один компонент.

Может быть полезно, если вы говорите, что строки "deb" - это инструкции, добавленные в списки источников Aptitude. Это устранит всю путаницу, которую создает весь этот вопрос.

Например, ответ @Eric Carvalho deb - это не командная строка. Если у вас есть deb, тогда url выглядит так:

редактировать

Как и коммит @muru , вам нужно создать новый файл с расширением .list в /etc/apt/source.list.d/ папке:

Пример : я хочу скачать Oracle virtualbox, создать новый файл:

Затем скопируйте и вставьте строку deb в этот файл

1. Это apt , нет opt (хотя есть opt ) и 2. Никогда не редактируйте, /etc/apt/sources.list чтобы добавить строку, если это не зеркало / официальный репозиторий Ubuntu. Создайте новый файл /etc/apt/sources.list.d с расширением .list с этой строкой. @muru " Никогда не редактируйте /etc/apt/sources.list, чтобы добавить строку, если это не зеркало или официальный репозиторий Ubuntu. " Почему? Конечно, создание .list файлов /etc/apt/sources.list.d - это то, что я делаю в этих условиях, и это то, что я обычно рекомендую. Но я не вижу причин настаивать на добавлении сторонних программных источников /etc/apt/sources.list.d . Некоторые файлы по возможности лучше не редактировать пользователем (например, использовать /etc/profile.d более /etc/profile , возможно, использовать /etc/sudoers.d более /etc/sudoers ), но sources.list часто изменяются. (Даже настроенный Ubiquity для регионального зеркала.) @EliahKagan, когда вы когда-нибудь видели, чтобы Ubiquity добавил сторонний репозиторий (не зеркальный) в sources.list? Или в этом отношении, любой официальный инструмент? sources.list.d присутствует по причине. Я буду продолжать настаивать на том, чтобы он использовался для сторонних репозиториев. @muru Извините, мне было непонятно. Я упомянул поведение Ubiquity, чтобы указать, что /etc/apt/sources.list это не одна из конфессий, которую можно оставить в покое, чтобы облегчить более плавное обновление - поскольку это часто (возможно, обычно) мотивирует сильные предложения предпочесть создание файлов X.d редактированию X . Я не предполагаю, что Ubiquity позволяет сторонним репозиториям каким-либо образом. Вы еще не объяснили, что особенного в таких репозиториях, чтобы сделать их неправильными (т. Е. «Никогда не редактировать . »), чтобы вставить их sources.list . @EliahKagan В этом нет ничего «действительно неправильного», если это ваша проблема с утверждением. «Никогда [делай X]» не всегда означает, что делать X неправильно, это может означать, что делать X - плохая практика («Никогда не используйте GOTO»). Счастливы сейчас? Повторяю: я буду продолжать настаивать на том, чтобы sources.list.d использовался для сторонних репозиториев и sources.list только для зеркал и официальных репозиториев, если только вы не можете дать мне ясную, ясную причину, почему это хорошая идея, а не сделать это.

deb это не команда Unix. Если у вас есть строка, подобная следующей (источник для docker):

это строка, которая должна быть доступна в вашем Ubuntu, sources.list чтобы apt-get можно было найти будущие пакеты из этого нового источника.

Однако не рекомендуется редактировать /etc/apt/sources.list файл напрямую. Вместо этого добавьте deb строку в качестве записи в новый .list файл внутри /etc/apt/sources.list.d/ каталога. Мы создадим такой docker.list файл:

После этого не забудьте выполнить a, sudo apt-get update и теперь вы сможете легко найти новые пакеты из этого источника.

Появилось таки некоторое количество времени, и я решил написать сий пост, идея которого возникла уже давно.
Связан он будет будет с такой, казалось бы, простой вещью, как 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

Для данного случая, согласно ABNF :
ALPHA — любая буква верхнего и нижнего регистров кодировки ASCII (в regExp [A-Za-z])
DIGIT — любая цифра (в regExp 5)
HEXDIG — шестнадцатиричная цифра (в regExp [0-9A-F])

Процентное кодирование

В случае, если используются символы выходящие за пределы кодировки ASCII используется механизм т.н. "Процентного кодирования ". Так же он применяется для передачи зарезервированных символов в составе данных. Зарезервированные символы, по правилам, не участвуют в процентном кодировании.
Процентно-кодированный символ представляет из себя символьный триплет, состоящий из знака "%" и следующих за ним двух шестнадцатиричных чисел:

Т.о., %20, например, означает пробел.

1.2. Компоненты URI

Разрешенные символы для схемы:

2. URL

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

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

2.1. Структура

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

Ссылка сетевого пути

3. URN

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

Т. е., в отличие от URL, который ссылается на како-то место, где хранится документ, URN ссылается на сам документ, и при перемещении документа в другое место ссылка не изменится.
В силу того, что URN концептуально отличается от URL, то и система разрешения имен у него другая — DDDS , которая преобразует URN в URL, по которым можно найти ресурс/объект или что бы то ни было, на что ссылается URN.

3.1. Структура

«urn:» — обязательная, регистронезависимая часть URN
NID — Namespace Identifier, данная компонента определяет синтаксическую интерпретацию компоненты NSS.
Минимальная длина — 2 символа, максимальная — 32, разрешенные символы:

Запрещенные символы

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

Такие URN содержат в NID название хэш-функции, а в NSS значение хэша, вычисленного для идентифицируемого объекта. Такие ссылки используются в magnet-ссылках и заголовках p2p-сети Gnutela2.
Например, URN из magnet-ссылки с одного торрент-трекера:
magnet:?xt=urn:btih:c68abc1ba9b8c7c4bc373862cad1a8c01d69e53d.

С теорией все, во второй части рассмотрим, что можно и что нужно делать с URI, если мы их обрабатываем, а именно — нормализация, разбор и т.д.

Читайте также: