man 7 uri - 18 Ноября 2017 - Мануалы linux на русском

Главная » 2017 » Ноябрь » 18 » man 7 uri

21:47

man 7 uri

ИМЯ

uri, url, urn - единый идентификатор ресурса (URI), содержащий URL или URN

ОБЗОР

ОПИСАНИЕ

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

URI являются стандартным способом создания конечных адресов гипертекстовых ссылок
для таких инструментов как веб-браузеры. Строка «http://www.kernel.org» является
URL (а значит и URI). Многие используют термин URL неправильно, как синоним URI
(технически, URL являются частью URI).

URI могут быть абсолютными или относительными. Абсолютный идентификатор ссылается
на ресурс независимо от контекста, в то время как относительный идентификатор
ссылается на ресурс, описывая его относительно текущего контекста. В относительном
идентификаторе части пути «.» и «..» имеют специальные значения: «текущий
иерархический уровень» и «уровень выше текущего иерархического уровня»,
соответственно —аналогично UNIX-подобным системам. Часть пути, содержащая
двоеточие, не может быть использована как первая часть пути относительного URI
(например, «это:то»), потому что это приведёт к ошибке; перед такими частями надо
ставить ./ (например, «./это:то»). Заметим, что в производных MS-DOS (например,
Microsoft Windows) в URI в именах устройств двоеточие заменено на вертикальную
черту («|»), то есть «C:» заменяется на «C|».

Если используется идентификатор фрагмента, то он ссылается на часть ресурса с
конкретным названием; фрагментом называют текст после символа «#». URI,
начинающийся с «#», ссылается на такой фрагмент в текущем ресурсе.

Использование
Существует множество различных схем URI, в каждой могут быть свои дополнительные
правила и смыслы, но все они создаются максимально похожими друг на друга.
Например, многие схемы URL позволяют задавать полномочия в следующем формате,
обозначаемом здесь как ip_server (квадратные скобки указывают на
fredpassword). Желательно в целях безопасности не указывать пароль в URI. Если в
URL указано имя пользователя, но нет пароля, а серверу этот пароль требуется, то
программа, обрабатывающая URL, должна запросить его у пользователя.

Далее приводятся наиболее распространённые схемы, используемые в UNIX-подобных
системах. Заметьте, что многие программы, использующие URI, имеют внутренние или
специализированные схемы, поэтому советуем прочитать на них документацию.

http — веб-сервер (HTTP)

http://ip_server/путь
http://ip_server/путь?запрос

Это URL для доступа к веб-серверу (HTTP). По умолчанию используется порт 80. Если
путь указывает на каталог, то веб-сервер сам выберет, что необходимо вернуть;
обычно, если есть файл «index.html» или «index.htm», то возвращается его
содержимое, в ином случае возвращается список файлов в каталоге. Пример:
<http://lwn.net>.

Запрос может быть задан в устаревшем формате «isindex», состоящим из слова или
фразы, и не содержащим знака равенства (=). Запрос может быть также в удлинённом
формате «GET», в котором может быть несколько запрашиваемых элементов в виде
ключ=значение и разделяемых амперсандом (&). Заметим, что ключ может повторяться,
но как это обрабатывать будет решать сам веб-сервер и его прикладная программа.
Есть проблемы при работе с HTML/XML/SGML с помощью формата запроса GET: когда в
такие URI добавляются несколько ключей, используемый в документах SGML/XML
(включая HTML) амперсанд (&) перезаписывается в виде &. Заметим, что не все
запросы используют этот формат; огромные формы могут быть слишком большими для
записи в виде URI, поэтому они используют другой механизм взаимодействия
(называемый POST), в котором данные в URI не включаются. Подробности смотрите в
спецификации на Common Gateway Interface ⟨http://www.w3.org/CGI⟩.

ftp — протокол передачи файлов (FTP)

ftp://ip_server/путь

Это URL для получения доступа к файлу с помощью протокола передачи файлов FTP.
Номер порта (управляющего) по умолчанию равен 21. Если не указано имя
пользователя, то пишется слово «anonymous», и в этом случае многие клиентские
программы в качестве пароля отправляют адрес электронной почты пользователя.
Пример: <ftp://ftp.is.co.za/rfc/rfc1808.txt>.

gopher — сервер Gopher

gopher://ip_server/тип_gopher селектор
gopher://ip_server/тип_gopher селектор%09поиск
gopher://ip_server/тип_gopher селектор%09поиск%09gopher+_строка

По умолчанию служба gopher использует порт 70. тип_gopher — односимвольное поле
для указания типа ресурса Gopher, на который ссылается URL. Полный путь может быть
пустым; в этом случае знак «/» тоже является необязательным, а значение тип_gopher
по умолчанию равно «1».

селектор — это строка селектора в Gopher. В протоколе Gopher строки селектора
могут содержать любые байты, кроме шестнадцатеричных 09 (US-ASCII HT или tab), 0A
(US-ASCII-символ LF) и 0D (US-ASCII-символ CR).

news — сообщение или группа новостей

news:newsgroup-name
news:message-id

В newsgroup-name задаётся иерархическое имя, разделённое точками, например,
«comp.infosystems.www.misc». Если значение <newsgroup-name> равно «*»
(записывается как <news:*>), то такая запись используется для указания «всех
доступных групп новостей». Пример: <news:comp.lang.ada>.

Значение message-id соответствует Message-ID из IETF RFC 1036,
⟨http://www.ietf.org/rfc/rfc1036.txt⟩ без крайних «<» и «>»; оно имеет вид
уникальная_часть@полное_доменное_имя. Идентификатор сообщения можно отличить от
названия группы новостей по находящемуся в названии символу «@».

telnet — удалённый вход

telnet://ip_server/

Схема URL для Telnet используется для определения интерактивных текстовых служб,
которые доступны по протоколу Telnet. Последний символ «/» может быть опущен. По
умолчанию используется порт 23. Пример: <telnet://melvyl.ucop.edu/>.

file — обычный файл

file://ip_server/сегменты_пути
file:сегменты_пути

Представляет файл или каталог, доступный локально. Исключение: значение ip_server
может быть пустым или равно строке «localhost»; это означает: «машина, с которой
обращаются по URL». Если путь указывает на каталог, то программа просмотра
представит содержимое каталога с ссылками на каждый элемент, что выполняется не
всеми просмотрщиками. KDE поддерживает генерируемые файлы с помощью URL
<file:/cgi-bin>. Если указанный файл не найден, то обозреватель может попробовать
расширить имя файла при помощи функций охвата (смотрите glob(7) и glob(3)).

Второй формат (например, <file:/etc/passwd>) существует для ссылки на локальные
файлы. Однако, в старых стандартах этот формат не допускался и некоторые программы
не воспринимают его как URI. Более переносим следующий синтаксис: пустая строка
вместо имени сервера, например, <file:///etc/passwd>; эта форма имеет тот же
смысл, легко распознаётся определителями по шаблону и старыми программами как URI.
Заметим, что если вы на самом деле хотите «начать с текущего места», то не
используйте такую схему вообще; рекомендуется использовать относительный адрес,
такой как, <../test.txt>, который имеет побочный эффект: он не зависит от схемы.
Пример такой схемы: <file:///etc/passwd>.

man — справочная страница man

man:имя_команды
man:имя_команды(раздел)

Это ссылка на локальные справочные страницы (man). За именем команды может
следовать номер раздела в круглых скобках; для получения более подробной
информации о разделах прочтите man(7). Схемы URI в UNIX-подобных системах
(например, Linux) различаются и до сих пор не зарегистрированы в IETF. Пример:
<man:ls(1)>.

UNIX-подобных системах (например, Linux) различаются и до сих пор не
зарегистрированы в IETF. На момент написания синтаксисы URI у GNOME и KDE
различались, поэтому они не понимают синтаксис друг друга. Первые два формата —
GNOME: в именах узлов все пробелы заменены подчеркиванием. Следующие два формата —
KDE: пробелы в названиях узлов остаются пробелами, даже если это запрещено
стандартами URI. Это делалось в надежде на то, что в будущем все программы будут
принимать все эти форматы и будут считать подчеркивания как пробелы. В GNOME и
KDE, если используется форма без названия узла, то названием по умолчанию
считается «Top». Пример формата GNOME: <info:gcc> и <info:gcc#G++_and_GCC>.
Пример формата КDE: <info:(gcc)> и <info:(gcc)G++ and GCC>.

whatis — поиск документации

whatis:строка

Эта схема применяет для поиска в базе однострочных описаний команд и возвращает
список описаний, содержащих искомую строку. Возвращаются только полные совпадения.
За более полной информацией обращайтесь к whatis(1). Данная схема URI в
UNIX-подобных системах (например, Linux) различается и до сих пор не
зарегистрирована IETF.

ghelp — справочная документация GNOME

ghelp:название_приложения

Схема загружает справку GNOME для заданного приложения. Замечание: пока в
документации описаны не все приложения в этом формате.

ldap — простой протокол доступа к каталогам (Lightweight Directory Access
Protocol)

ldap://узел_порт
ldap://узел_порт/
ldap://узел_порт/dn
ldap://узел_порт/dn?атрибуты
ldap://узел_порт/dn?атрибуты?область
ldap://узел_порт/dn?атрибуты?область?фильтр
ldap://узел_порт/dn?атрибуты?область?фильтр?расширения

Эта схема поддерживает запросы, направляемые по протоколу LDAP одному или
нескольким серверам для получения иерархически упорядоченной информации (например,
о людях или ресурсах компьютеров). Подробности о схеме LDAP URL смотрите в
RFC 2255 ⟨http://www.ietf.org/rfc/rfc2255.txt⟩. Компоненты этого URL:

узел_порт запрашиваемый сервер LDAP, записывается как имя машины, двоеточие,
номер порта (необязательно). По умолчанию в LDAP используется TCP-порт
389. Если компонент не указан, то клиент сам определяет, какой из
LDAP-серверов запрашивать.

dn отличительное имя LDAP, которое определяет базовый объект поиска LDAP
(смотрите RFC 2253 ⟨http://www.ietf.org/rfc/rfc2253.txt⟩ раздел 3).

атрибуты возвращаемый список атрибутов, разделённых запятой; смотрите RFC 2251,
раздел 4.1.5. Если данный компонент не задан, то возвращаются все
атрибуты.

область область поиска, значениями могут быть: «base» (для поиска по базовому
случаях, когда это не требуется) может не употребляться. Расширение с
приставкой «!» обязательно; если этот значок отсутствует, то
необязательно.

Приведём примеры запросов LDAP. Запрос к ldap.itd.umich.edu информации о
Мичиганском университете США:

ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US

Для того, чтобы получить атрибут почтового адреса, введите запрос:

ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress

Для того, чтобы запросить у host.com (порт 6666) информацию о человеке по имени
(cn) «Babs Jensen» в Мичиганском университете, введите строку:

ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)

wais — глобальная сеть информационных серверов (Wide Area Information Servers)

wais://узел_порт/база_данных
wais://узел_порт/база_данных?поиск
wais://узел_порт/база_данных/wtype/wpath

Эта схема предназначена для базы данных WAIS, поиска или документа (более
подробную информацию о WAIS смотрите IETF RFC 1625 ⟨http://www.ietf.org/rfc
/rfc1625.txt⟩ ). Узел_порт — это название машины, в некоторых случаях
сопровождающееся номером порта (после двоеточия). Используемый порт по умолчанию —
210.

Первая форма определяет базу данных WAIS для поиска. Вторая форма — это
определённой поиск в базе данных WAIS. Третья форма предназначена для поиска
конкретного документа в базе данных WAIS. Значение wtype служит для обозначения
объекта в WAIS, а wpath — это document-id WAIS.

другие схемы

Существует множество других схем URI. Большинство программ, использующих URI,
поддерживают свои собственные схемы URI (например, Mozilla имеет схему about: для
работы с внутренней информацией; браузер справки GNOME имеет схему toc: для работы
с разными разделами). Есть схемы, которые в данный момент не распространены
(например, prospero). Схема news: предпочтительнее схемы nntp:. URN поддерживаются
схемой urn: (например, urn:ietf:… означает документы IETF); в настоящее время URN
широко не используются. Не все приложения поддерживают все схемы.

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

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

; / ? : @ & = + $ ,

Незарезервированные символы могут быть использованы в URI. Незарезервированные
символы — это английские буквы верхнего и нижнего регистров, цифры и следующий
зарезервирован, он всегда обозначаться только как «%25». Обычно в запросах
пробельные символы заменяют знаком плюс (+); этот способ не определён в RFC (где
рекомендуется использовать %20), но любое приложение, принимающее запросы URI,
должно его воспринимать. URI всегда показываются в своём «экранированном» виде.

Незарезервированные символы можно экранировать без изменения семантики URI, но это
нельзя делать в случаях, когда URI не используется в контексте, не допускающем
появления неэкранированных символов. Например, «%7e» иногда используется вместо
«~» в пути HTTP URL, но обе формы воспринимаются в HTTP URL одинаково.

Для URI, обрабатывающих символы, не входящих в набор US-ASCII, в главе В.2
документации по HTML 4.01 и в главе 2.2.5 IETF RFC 2718 приводится рекомендуемое
рациональное решение:

1. Переводить последовательность символов в кодировку UTF-8 (IETF RFC 2279) —
смотрите utf-8(7) — затем

2. использовать механизм экранирования URI, то есть, использовать конвертацию %HH
для небезопасных октетов.

Запись URI
При записи URI должны помещаться в двойные кавычки (например,
"http://www.kernel.org"), закрываться в угловые скобки (например,
<http://lwn.net>) или помещаться на отдельной строке. Предупреждение для
использующих двойные кавычки: никогда не помещайте лишнюю пунктуацию (например,
точку в конце фразы или запятую в списке) внутрь URI, так как они изменят значение
URI. Вместо этого используйте угловые скобки, или перейдите к системе цитирования,
в которой никогда не встречаются дополнительные символы внутри цитат. В качестве
такой системы можно предложить «новую» или «логическую» систему цитирования от
«Hart's Rules» и «Oxford Dictionary for Writers and Editors», используемую в
Великобритании и хакерами по всему миру (смотрите раздел Jargon File в Hacker
Writing Style, ⟨http://www.fwi.uva.nl/~mes/jargon/h/HackerWritingStyle.html⟩ ).
Старые документы предполагают вставку префикса «URL:» сразу перед URI, но такая
форма никогда не была популярной.

Синтаксис URI разрабатывался как однозначный. Однако когда URI стали использовать
повсеместно, традиционные средства массовой информации (телевидение, радио, газеты
и т.д.) стали применять сокращённые ссылки URI, состоящие из названия домена и
пути к конкретному ресурсу (например, <www.w3.org/Addressing>). Такие ссылки
больше предназначены для человеческого восприятия, а не для считывания машиной в
предположении, что для полного понимания URI будет достаточно контекста применения
(например, имена узлов, начинающиеся с «www», скорее всего, имеют в URI префикс
«http://», а имена узлов, начинающиеся с «ftp», скорее всего, имеют префикс
«ftp://»). Много реализаций клиентов «додумывают» такие ссылки. Такие
предположения могут иногда меняться, в частности при появлении новых схем. Так как
сокращённые URI имеют тот же синтаксис, что и путь относительных URL, сокращённые
URI не могут быть использованы в тех случаях, где используются относительные URI;
они могут использоваться только когда нет определённой основы (например, в
диалоговых окнах). Не используйте сокращённые URI как гипертекстовые ссылки в
документах, используйте стандартный формат, как описано в данном документе.

СООТВЕТСТВИЕ СТАНДАРТАМ

(IETF RFC 2396) ⟨http://www.ietf.org/rfc/rfc2396.txt⟩, (HTML 4.0)
⟨http://www.w3.org/TR/REC-html40⟩.

ЗАМЕЧАНИЯ

Любое приложение, использующее URI (например, веб-браузер) в Linux, должно
распознавать, что :// это часть URI).

В настоящее время окружения рабочего стола GNOME и KDE используют различные URI, в
частности в своих справочных системах. Для справочных страниц в GNOME используется
<toc:man>, а в KDE — <man:(index)>; для страниц info в GNOME используется
<toc:info>, а в KDE — <info:(dir)> (автору данной справочной страницы нравится
выбор KDE, так как он больше похож на обычно используемый формат). В общем случае,
в KDE используется <file:/cgi-bin/> в качестве приставки к набору генерируемых
файлов. В KDE предпочитают использовать документацию в HTML, доступную как
<file:/cgi-bin/helpindex>. В GNOME для хранения и поиска документации предпочитают
использовать схему ghelp. Ни один обозреватель в момент написания этого документа
не поддерживал схему ссылок на каталоги file:, что затрудняет ссылку на весь
каталог с помощью просматриваемого URI. Как говорилось ранее, эти окружения
различаются по способу поддержки схемы info:. В перспективе GNOME и KDE должны
прийти к единому формату URI, и будущая версия системы войдёт в эту справочную
страницу. Помогите достичь этого единства.

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

Существует возможность составить URL таким образом, что попытка произвести
обыкновенную, «безобидную» операцию, такую, как получение информации с
определённого ресурса, возможно, вызовет сбой в её выполнении. Небезопасный URL,
обычно, создаётся следующим образом: в запросе указывается номер порта, не
совпадающий с номером зарезервированного порта сетевого протокола. Клиент
неосознанно заходит на сайт, но используя другой протокол. В URL содержатся
команды, которые при их считывании (в соответствии с другим протоколом) производят
непредвиденную операцию. Примером может послужить использование gopher URL для
создания ненужного и безадресного сообщения, которое отправится через сервер SMTP.

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

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

Также довольно не предусмотрительно использовать пароль в URI. В частности,
рекомендуется использовать пароль внутри URI-компонента «userinfo», за исключением
редких случаев, когда параметр «password» может быть показан всем.

ДЕФЕКТЫ

Документация может быть расположена в различных местах, поэтому не существует
схемы URI для просмотра документации в различных форматах. Ссылки типа
<file:///usr/doc/ZZZ> не работают по причине различных требований дистрибутивов и
установочных требований, согласно которым документация может быть размещена в
разных каталогах (она может быть в /usr/doc, /usr/local/doc, /usr/share или
где-нибудь ещё). К тому же, содержимое каталога ZZZ, обычно, изменяется с каждой
версией (хотя, частично это можно решить использованием шаблонов имён файлов). А
URI.

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

СМОТРИТЕ ТАКЖЕ

lynx(1), man2html(1), mailaddr(7), utf-8(7)

IETF RFC 2255 ⟨http://www.ietf.org/rfc/rfc2255.txt⟩

Категория: (7) Различные описания, соглашения и прочее | Просмотров: 499 | Добавил: Администратор | Рейтинг: 0.0/0

Всего комментариев: 0