унифицированный идентификатор ресурса (URI), включая URL или URN (uniform resource identifier (URI), including a URL or URN)
Примечание (Note)
Any tool accepting URIs (e.g., a web browser) on a Linux system
should be able to handle (directly or indirectly) all of the
schemes described here, including the man: and info: schemes.
Handling them by invoking some other program is fine and in fact
encouraged.
Technically the fragment isn't part of the URI.
For information on how to embed URIs (including URLs) in a data
format, see documentation on that format. HTML uses the format
<A HREF="uri"> text </A>. Texinfo files use the format
@uref{uri}. Man and mdoc have the recently added UR macro, or
just include the URI in the text (viewers should be able to
detect :// as part of a URI).
The GNOME and KDE desktop environments currently vary in the URIs
they accept, in particular in their respective help browsers. To
list man pages, GNOME uses <toc:man> while KDE uses
<man:(index)>, and to list info pages, GNOME uses <toc:info>
while KDE uses <info:(dir)> (the author of this man page prefers
the KDE approach here, though a more regular format would be even
better). In general, KDE uses <file:/cgi-bin/> as a prefix to a
set of generated files. KDE prefers documentation in HTML,
accessed via the <file:/cgi-bin/helpindex>. GNOME prefers the
ghelp scheme to store and find documentation. Neither browser
handles file: references to directories at the time of this
writing, making it difficult to refer to an entire directory with
a browsable URI. As noted above, these environments differ in
how they handle the info: scheme, probably the most important
variation. It is expected that GNOME and KDE will converge to
common URI formats, and a future version of this man page will
describe the converged result. Efforts to aid this convergence
are encouraged.
Security
A URI does not in itself pose a security threat. There is no
general guarantee that a URL, which at one time located a given
resource, will continue to do so. Nor is there any guarantee
that a URL will not locate a different resource at some later
point in time; such a guarantee can be obtained only from the
person(s) controlling that namespace and the resource in
question.
It is sometimes possible to construct a URL such that an attempt
to perform a seemingly harmless operation, such as the retrieval
of an entity associated with the resource, will in fact cause a
possibly damaging remote operation to occur. The unsafe URL is
typically constructed by specifying a port number other than that
reserved for the network protocol in question. The client
unwittingly contacts a site that is in fact running a different
protocol. The content of the URL contains instructions that,
when interpreted according to this other protocol, cause an
unexpected operation. An example has been the use of a gopher
URL to cause an unintended or impersonating message to be sent
via a SMTP server.
Caution should be used when using any URL that specifies a port
number other than the default for the protocol, especially when
it is a number within the reserved space.
Care should be taken when a URI contains escaped delimiters for a
given protocol (for example, CR and LF characters for telnet
protocols) that these are not unescaped before transmission.
This might violate the protocol, but avoids the potential for
such characters to be used to simulate an extra operation or
parameter in that protocol, which might lead to an unexpected and
possibly harmful remote operation to be performed.
It is clearly unwise to use a URI that contains a password which
is intended to be secret. In particular, the use of a password
within the "userinfo" component of a URI is strongly recommended
against except in those rare cases where the "password" parameter
is intended to be public.
