Provided by: manpages-ru_4.18.1-1_all bug

ИМЯ

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

СИНТАКСИС

       URI = [ абсолютный_URI | относительный_URI ] [ "#" фрагмент ]

       абсолютныйURI = схема ":" ( иерархическая_часть | неясная_часть )

       относительныйURI = ( сетевой_путь | абсолютный_путь | относительный_путь ) [ "?" запрос ]

       схема = "http" | "ftp" | "gopher" | "mailto" | "news" | "telnet" |
                  "file" | "man" | "info" | "whatis" | "ldap" | "wais" | …

       иерархическая_часть = ( сетевой_путь | абсолютный_путь ) [ "?" запрос ]

       сетевой_путь = "//" полномочия [ абсолютный_путь ]

       абсолютный_путь = "/"  сегменты_пути

       относительный_путь = относительный_сегмент [ абсолютный_путь ]

ОПИСАНИЕ

       Единый  идентификатор  ресурса  (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|».

       A  fragment  identifier, if included, refers to a particular named portion (fragment) of a
       resource; text after a '#' identifies the fragment.  A URI beginning with  '#'  refers  to
       that fragment in the current resource.

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

       ip_server = [пользователь [ : пароль ] @ ] узел [ : порт]

       Этот формат позволяет указать имя пользователя, его пароль и/или номер порта. Узел  —  это
       имя  компьютера-узла;  он  может  быть  указан в виде имени DNS или IP-адреса (числа через
       точку).  Таким  образом,  URI  <http://fred:fredpassword@example.com:8080/>   определяется
       подключение  к  веб-серверу example.com по порту 8080 пользователем fred (с помощью пароля
       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) амперсанд (&) перезаписывается в виде &amp;. Заметим,
       что не все запросы используют этот формат; огромные формы могут быть слишком большими  для
       записи  в  виде  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).

       mailto  адрес электронной почты

       mailto:адрес_email

       Это адрес электронный почты, обычно имеющий форму имя_пользователя@имя_узла. Для получения
       более подробной информации о  формате  адресов  электронной  почты  смотрите  mailaddr(7).
       Заметим,    что    любой    символ    %    должен    записываться    как    %25.   Пример:
       <mailto:dwheeler@dwheeler.com>.

       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)).

       The second format (e.g., <file:/etc/passwd>)  is a correct format for referring to a local
       file.   However,  older  standards  did  not  permit  this format, and some programs don't
       recognize this as a URI.  A more portable syntax is to use an empty string as  the  server
       name,  for  example,  <file:///etc/passwd>;  this  form  does the same thing and is easily
       recognized by pattern matchers and older programs as a URI.  Note that if you really  mean
       to  say "start from the current location", don't specify the scheme at all; use a relative
       address like <../test.txt>, which has the side-effect  of  being  scheme-independent.   An
       example of this scheme is <file:///etc/passwd>.

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

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

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

       info  страница документации info

       info:виртуальное_имя_файла
       info:виртуальное_имя_файла#имя_узла
       info:(виртуальное_имя_файла)
       info:(виртуальное_имя_файла)имя_узла

       Эта схема ссылается на справочные страницы info  (созданные  из  файлов  texinfo);  данный
       формат  документации  используется  в инструментах GNU. Схемы URI в 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» (для поиска по базовому объекту),
              «one» (для поиска на одном уровне) или «sub» (для поиска по ветвям).  Если  область
              поиска не указывается, то по умолчанию используется «base».

       фильтр фильтр   поиска   (набор   возвращаемых  записей).  Если  компонент  не  задан,  то
              возвращаются все записи.  Смотрите  RFC 2254  ⟨http://www.ietf.org/rfc/rfc2254.txt⟩
              раздел 4.

       расширения
              a comma-separated list of type=value pairs, where the =value portion may be omitted
              for options not requiring it.  An extension prefixed with a '!' is  critical  (must
              be supported to be valid), otherwise it is noncritical (optional).

       Приведём  примеры  запросов  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):

                  ; / ? : @ & = + $ ,

       Unreserved characters may be included in a URI.  Unreserved characters  include  uppercase
       and  lowercase Latin letters, decimal digits, and the following limited set of punctuation
       marks and symbols:

                  - _ . ! ~ * ' ( )

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

       Unreserved characters can be escaped without changing the semantics of the URI,  but  this
       should  not  be  done  unless  the  URI is being used in a context that does not allow the
       unescaped character to appear.  For example, "%7e" is sometimes used instead of "~" in  an
       HTTP URL path, but the two are equivalent for an HTTP URL.

       For  URIs  which  must handle characters outside the US ASCII character set, the HTML 4.01
       specification (section B.2) and IETF RFC 3986 (last paragraph of section  2.5)   recommend
       the following approach:

       (1)  translate the character sequences into UTF-8 (IETF RFC 3629)—see utf-8(7)—and then

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

   Запись URI
       When written, URIs should be placed inside double quotes (e.g.,  "http://www.kernel.org"),
       enclosed in angle brackets (e.g., <http://lwn.net>), or placed on a line by themselves.  A
       warning for those who use double-quotes: never move extraneous punctuation  (such  as  the
       period ending a sentence or the comma in a list)  inside a URI, since this will change the
       value of the URI.  Instead, use angle brackets instead, or switch to a quoting system that
       never  includes  extraneous characters inside quotation marks.  This latter system, called
       the 'new' or 'logical' quoting system by "Hart's Rules" and  the  "Oxford  Dictionary  for
       Writers  and  Editors",  is  preferred  practice  in Great Britain and in various European
       languages.  Older documents suggested inserting the prefix "URL:" just before the URI, but
       this form has never caught on.

       Синтаксис  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, должно поддерживать
       (непосредственно или косвенно) все схемы, описанные здесь, включая схемы man: и info:. Для
       обработки предлагается вызывать стороннюю программу.

       Технически, фрагмент не является частью URI.

       Для  получения  информации о том, как включить URI (включая URL) в формат данных, прочтите
       соответствующую документацию. HTML использует  формат  <A  HREF="uri">  text  </A>.  Файлы
       texinfo  используют  формат @uref{uri}. Man и mdoc имеют недавно добавленный макрос UR или
       просто включают URI в текст (программы просмотра должны распознавать, что  ://  это  часть
       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,
       обычно,  изменяется  с  каждой  версией  (хотя,  частично  это можно решить использованием
       шаблонов имён файлов). А людям, которые получают документацию по  Интернет  (вместо  того,
       чтобы  хранить  её  в своей системе), схема file: вообще ничем не будет полезна. В будущем
       может быть добавлена новая схема URI (например, «userdoc:»), которая  позволит  программам
       включать  перекрёстные  ссылки  на  дополнительную  документацию и, при этом, не учитывать
       точное расположение такой документации. Или же в новой версии файловой системы можно будет
       указывать  расположения  файлов  так, что можно будет находить документацию прямо по схеме
       file:.

       Многие программы и форматы файлов не имеют возможности включать ссылки с помощью URI.

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

СМ. ТАКЖЕ

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

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

ПЕРЕВОД

       Русский   перевод   этой    страницы    руководства    был    сделан    Azamat    Hackimov
       <azamat.hackimov@gmail.com>,    Dmitriy    Ovchinnikov    <dmitriyxt5@gmail.com>,   Dmitry
       Bolkhovskikh <d20052005@yandex.ru>, Katrin Kutepova <blackkatelv@gmail.com>,  Yuri  Kozlov
       <yuray@komyakino.ru> и Иван Павлов <pavia00@gmail.com>

       Этот  перевод  является  бесплатной  документацией;  прочитайте  Стандартную  общественную
       лицензию GNU версии 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ или более позднюю, чтобы
       узнать об условиях авторского права. Мы не несем НИКАКОЙ ОТВЕТСТВЕННОСТИ.

       Если  вы  обнаружите  ошибки  в  переводе этой страницы руководства, пожалуйста, отправьте
       электронное письмо на ⟨man-pages-ru-talks@lists.sourceforge.net⟩.