Scroll to navigation

uri(7) Miscellaneous Information Manual uri(7)

NOM

uri, url, urn - Identificateur de ressource uniforme (URI), comprenant URL ou URN

SYNOPSIS

URI = URI_absolu | URI_relatif ] [ "#fragment ]
absoluteURI = mécanisme .RB " : "partie_hiérarchique | partie_opaque )
relativeURI = chemin_réseau | chemin_absolu | chemin_relatif ) [ "?requête ]
scheme = "http" | "ftp" | "gopher" | "mailto" | "news" | "telnet" | "file" | "ftp" | "man" | "info" | "whatis" | "ldap" | "wais" | ...
hierarchical_part = chemin_réseau | chemin_absolu ) [ "?requête ]
net_path = "//autoritéchemin_absolu ]
absolute_path = "/segments_chemins
relative_path = segment_relatifchemin_absolu ]

DESCRIPTION

Un Identificateur de Ressource Uniforme (URI) est une courte chaîne de caractères identifiant une ressource physique ou abstraite (par exemple une page web). Une Localisation de Ressource Uniforme (URL) est un URI qui identifie une ressource à travers son moyen d'accès (sa « position » réseau par exemple), plutôt que par son nom ou un autre attribut de la ressource. Un Nom de Ressource Uniforme (URN) est un URI qui doit rester globalement unique, et persister même si la ressource cesse d'exister ou devient indisponible.

Les URI constituent le mécanisme standard pour nommer les destinations des liens hypertextes pour les outils comme les navigateurs web. La chaîne « http://www.kernel.org » est une URL (et donc aussi un URI). Beaucoup de gens utilisent le terme URL comme vague synonyme de URI (bien que techniquement les URL soient un sous-ensemble des URI).

Les URI peuvent être absolus ou relatifs. Un identificateur absolu référence une ressource indépendamment du contexte, alors qu'un identificateur relatif référence une ressource en décrivant la différence par rapport au contexte courant. Dans les références de chemins relatifs, les segments complets « . » et « .. » ont des significations particulières : « le niveau actuel dans la hiérarchie » et « le niveau au-dessus dans la hiérarchie », respectivement, tout comme dans les systèmes type UNIX. Un segment de chemin qui contient un caractère deux-points ne peut pas être utilisé comme premier segment du chemin d'un URI (par exemple « ceci:cela »), car on le confondrait avec le mécanisme. Précédez un tel segment avec ./ (par exemple « ./ceci:cela »). Notez que les descendants de MS-DOS (par ex. Windows) remplacent le deux-points du nom de périphérique par une barre verticale dans les URI, ainsi « C: » devient « C| ».

Un identificateur de fragment, s'il est présent, référence une portion particulière de la ressource ; le texte après le « # » identifie le fragment. Un URI commençant par « # » référence le fragment dans la ressource courante.

Utilisation

Il y a plusieurs schémas d'URI différents, chacun ajoutant des règles et des significations spécifiques, mais ils sont volontairement rendus le plus ressemblants possible. Par exemple, plusieurs schémas d'URL permettent le format suivant pour décrire l'autorité d'un chemin réseau, que l'on appellera serveur_ip (les crochets encadrent les parties optionnelles) :

serveur_ip = [user [ : password ] @ ] hôte [ : port]

Ce format permet d'insérer éventuellement un nom d'utilisateur, suivi éventuellement d'un mot de passe, et/ou un numéro de port. La partie hôte est le nom de l'ordinateur, soit son nom déterminé par le DNS, soit son adresse IP (numéros séparés par des points). Ainsi l'URI <http://fred:fredpassword@example.com:8080/> se connecte dans le serveur web sur l'ordinateur example.com avec l'identité fred (et le mot de passe fredpassword) en utilisant le port 8080. Évitez d'utiliser les mots de passe dans les URI à cause des risques liés à la sécurité sitôt que l'on écrit un mot de passe. Si l'URL indique un nom d'utilisateur et pas de mot de passe, et si le serveur distant réclame un mot de passe, alors le programme interprétant l'URL peut en demander un à l'utilisateur.

Voici les mécanismes les plus courants utilisés sur les systèmes type UNIX, compris par de nombreux outils. Notez que beaucoup d'outils gérant les URI ont aussi des mécanismes internes ou spécialisés ; consultez la documentation de ces outils pour plus de détails.

http - Serveur Web (HTTP)

http://serveur_ip/chemin
http://serveur_ip/chemin?requête

This is a URL accessing a web (HTTP) server. The default port is 80. If the path refers to a directory, the web server will choose what to return; usually if there is a file named "index.html" or "index.htm", its content is returned; otherwise, a list of the files in the current directory (with appropriate links) is generated and returned. An example is <http://lwn.net>.

A query can be given in the archaic "isindex" format, consisting of a word or phrase and not including an equal sign (=). A query can also be in the longer "GET" format, which has one or more query entries of the form key=value separated by the ampersand character (&). Note that key can be repeated more than once, though it's up to the web server and its application programs to determine if there's any meaning to that. There is an unfortunate interaction with HTML/XML/SGML and the GET query format; when such URIs with more than one key are embedded in SGML/XML documents (including HTML), the ampersand (&) has to be rewritten as &amp;. Note that not all queries use this format; larger forms may be too long to store as a URI, so they use a different interaction mechanism (called POST) which does not include the data in the URI. See the Common Gateway Interface specification at http://www.w3.org/CGI for more information.

ftp - File Transfer Protocol (FTP)

ftp://serveur_ip/chemin

Cette URL accède à un fichier à travers le protocole FTP. Le port par défaut (pour les commandes) est 21. Si aucun nom d'utilisateur n'est inclus, l'utilisateur « anonymous » est employé, et dans ce cas de nombreux clients fournissent l'adresse courriel du requérant en guise de mot de passe. Un exemple est <ftp://ftp.is.co.za/rfc/rfc1808.txt>.

gopher - Serveur Gopher

gopher://serveur_ip/type_gopher sélecteur
gopher://serveur_ip/type_gopher sélecteur%09recherche
gopher://serveur_ip/type_gopher sélecteur%09recherche%09chaine_gopher+

The default gopher port is 70. gophertype is a single-character field to denote the Gopher type of the resource to which the URL refers. The entire path may also be empty, in which case the delimiting "/" is also optional, and the gophertype defaults to "1".

selecteur est une chaîne de sélecteur Gopher. Dans le protocole Gopher, la chaîne de sélecteur est une séquence d'octets pouvant contenir tous les octets sauf 09 hexadécimal (HT ACSII ou Tabulation), 0A hexadécimal (LF ACSII), et 0D (CR ACSII).

mailto - Adresse courriel

mailto:adresse-courriel

Il s'agit d'une adresse courriel, en principe de la forme nom@nom_hôte. Consultez mailaddr(7) pour plus d'informations sur le format correct d'une adresse courriel. Notez que les caractères % doivent être transformés en %25. Un exemple : <mailto:dwheeler@dwheeler.com>.

news - Groupe ou message des news

news:nom-groupe-news
news:id-message

Un nom-groupe-news est un nom hiérarchique délimité par des points, comme « comp.infosystems.www.misc ». Si nom-groupe-news est « * » (comme dans <news:*>), l'URL référence tous les groupes news disponibles. Un exemple : <news:comp.lang.ada>.

Un id-message correspond au champ identificant Message-ID de IETF RFC 1036, sans les chevrons « < » et « > » ; il prend la forme unique@nom-domaine-complet. Un identificateur de message peut être distingué d'un nom de groupe de news par la présence du caractère « @ ».

telnet - Connexion telnet

telnet://serveur_ip/

Le mécanisme d'URL Telnet est utilisé pour afficher un service interactif accessible par le protocole Telnet. Le caractère « / » final peut être omis. Le port par défaut est 23. Un exemple : <telnet://melvyl.ucop.edu/>.

file - Fichier normal

file://serveur_ip/segments_chemins
file:segments_chemins

Ceci représente un fichier ou un répertoire accessible localement. En particulier, ip_server peut être la chaîne « localhost » ou une chaîne vide ; elle est interprétée comme « la machine sur laquelle l'URL est en cours d'interprétation ». Si le chemin conduit à un répertoire, le navigateur devrait afficher le contenu du répertoire avec des liens pour chaque élément. Tous les navigateurs ne le font pas encore. KDE prend en charge les fichiers générés par l'URL <file:/cgi-bin>. Si le fichier n'est pas trouvé, l'analyseur du navigateur peut essayer de développer le nom du fichier (consultez glob(7) et glob(3)).

Le second format (par ex. <file:/etc/passwd>) est le format correct pour référencer un fichier local. Toutefois les anciens standards ne le permettaient pas, et certains programmes ne le reconnaissent pas comme URI. Une syntaxe plus portable est d'utiliser une chaîne vide en guise de nom de serveur <file:///etc/passwd> ; cette forme a le même effet et est reconnue facilement comme un URI par les analyseurs des anciens programmes. Notez que si vous désirez vraiment écrire « débuter de l'emplacement actuel », n'indiquez pas de mécanisme ; utilisez une adresse relative comme <../test.txt>, qui est indépendante du mécanisme. Un exemple de ce mécanisme est <file:///etc/passwd>.

man - Pages de manuel

man:nom-commande
man:nom-commande(section)

Ceci référence les pages de documentation en ligne (man) locales. Le nom de la commande peut être suivi éventuellement de parenthèses et d'un numéro de section. Consultez man(7) pour plus de renseignements sur la signification du numéro de section. Ce mécanisme d'URI est unique aux systèmes UNIX (comme Linux) et n'est pas encore enregistré par l'IETF. Un exemple : <man:ls(1)>.

info - Page de documentation Info

info:nom-de-fichier-virtuel
info:nom-de-fichier-virtuel#nom-de-nœud
info:(nom-de-fichier-virtuel)
info:(nom-de-fichier-virtuel)nom-de-nœud

This scheme refers to online info reference pages (generated from texinfo files), a documentation format used by programs such as the GNU tools. This URI scheme is unique to UNIX-like systems (such as Linux) and is not currently registered by the IETF. As of this writing, GNOME and KDE differ in their URI syntax and do not accept the other's syntax. The first two formats are the GNOME format; in nodenames, all spaces are written as underscores. The second two formats are the KDE format; spaces in nodenames must be written as spaces, even though this is forbidden by the URI standards. It's hoped that in the future most tools will understand all of these formats and will always accept underscores for spaces in nodenames. In both GNOME and KDE, if the form without the nodename is used, the nodename is assumed to be "Top". Examples of the GNOME format are <info:gcc> and <info:gcc#G++_and_GCC>. Examples of the KDE format are <info:(gcc)> and <info:(gcc)G++ and GCC>.

whatis - Recherche de documentation

whatis:chaîne

Ce mécanisme parcourt une base de données de courtes (une ligne) descriptions des commandes et renvoie une liste des descriptions contenant la chaîne. Seules les correspondances de mots complets sont renvoyées. Consultez whatis(1). Ce mécanisme est unique aux systèmes UNIX (comme Linux) et n'est pas encore enregistré par l'IETF.

ghelp - Documentation d'aide Gnome

ghelp:nom-application

Ceci charge la documentation d'aide Gnome pour l'application indiquée. Notez qu'il n'y a pas encore beaucoup de documentation dans ce format.

ldap - Lightweight Directory Access Protocol

ldap://hostport
ldap://hostport/
ldap://hostport/dn
ldap://hostport/dn?attributs
ldap://hostport/dn?attributs?portée
ldap://hostport/dn?attributs?portée?filtre
ldap://hostport/dn?attributs?portée?filtre?extensions

Ce mécanisme prend en charge les requêtes utilisant le protocole Lightweight Directory Access Protocol (LDAP), pour interroger un ensemble de serveurs à propos d'informations organisées hiérarchiquement (comme des gens ou des ressources de calcul). Consultez RFC 2255 pour plus d'informations sur la forme des URL LDAP. Les composantes de cette URL sont :

le serveur LDAP à interroger, écrit comme un nom d'hôte suivi éventuellement par un deux-points et un numéro de port. Le port TCP pour le LDAP est 389. Si le nom est vide, le client détermine le serveur LDAP à utiliser.
Le nom complet (Distinguished Name) LDAP, qui identifie l'objet de base de la recherche LDAP (voir RFC 2253 section 3).
une liste d'attributs à renvoyer séparés par des virgules ; voir la RFC 2251 section 4.1.5. Par défaut tous les attributs sont renvoyés..
indique la portée de la recherche qui peut être « base » (recherche d'objet de base), « one » (recherche sur un niveau), ou « sub » (recherche dans un sous-arbre). Par défaut, on considère « base ».
indique le filtre de recherche (sous-ensemble des entrées à renvoyer). Par défaut, toutes les entrées sont renvoyées. Consultez RFC 2254 section 4.
une liste de paires type=valeur séparées par des virgules, où la portion =valeur peut être omise pour les options ne la nécessitant pas. Une extension préfixée par un « ! » est critique (doit être pris en charge pour être valide), sinon elle est non-critique (facultative).

Les requêtes LDAP sont plus faciles à comprendre par l'exemple. Voici une requête demandant à ldap.itd.umich.edu des informations à propos de l'Université du Michigan aux U.S. :

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

Pour n'obtenir que l'attribut Adresse Postale, on demanderait :

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

Pour demander à host.com, sur le port 6666 des informations sur la personne de nom courant (cn) « Babs Jensen » à l'University du Michigan, demandez :

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

wais - Wide Area Information Servers

wais://hostport/base
wais://hostport/base?recherche
wais://hostport/base/wtype/wpath

Ce mécanisme désigne une base de données WAIS, une recherche ou un document (voir IETF RFC 1625 pour plus de renseignements sur WAIS). Hostport est le nom d'hôte, suivi éventuellement d'un deux-points et d'un numéro de port (par défaut 210).

The first form designates a WAIS database for searching. The second form designates a particular search of the WAIS database database. The third form designates a particular document within a WAIS database to be retrieved. wtype is the WAIS designation of the type of the object, and wpath is the WAIS document-id.

Autres mécanismes

There are many other URI schemes. Most tools that accept URIs support a set of internal URIs (e.g., Mozilla has the about: scheme for internal information, and the GNOME help browser has the toc: scheme for various starting locations). There are many schemes that have been defined but are not as widely used at the current time (e.g., prospero). The nntp: scheme is deprecated in favor of the news: scheme. URNs are to be supported by the urn: scheme, with a hierarchical name space (e.g., urn:ietf:... would identify IETF documents); at this time, URNs are not widely implemented. Not all tools support all schemes.

Codage des caractères

Les URI utilisent un nombre limité de caractères afin d'être saisis et utilisés dans de nombreuses situations.

Les caractères suivants sont réservés ; ils peuvent apparaître dans un URI, mais leurs usages est limités aux fonctionnalités réservées (les données conflictuelles doivent être protégées avant de former l'URI) :


; / ? : @ & = + $ ,
    

Les caractères non-réservés peuvent être inclus dans un URI. Les caractères non-réservés incluent les majuscules et minuscules latines, les chiffres décimaux, et l'ensemble suivant de signes de ponctuation et de symboles :


- _ . ! ~ * ' ( )
    

All other characters must be escaped. An escaped octet is encoded as a character triplet, consisting of the percent character "%" followed by the two hexadecimal digits representing the octet code (you can use uppercase or lowercase letters for the hexadecimal digits). For example, a blank space must be escaped as "%20", a tab character as "%09", and the "&" as "%26". Because the percent "%" character always has the reserved purpose of being the escape indicator, it must be escaped as "%25". It is common practice to escape space characters as the plus symbol (+) in query text; this practice isn't uniformly defined in the relevant RFCs (which recommend %20 instead) but any tool accepting URIs with query text should be prepared for them. A URI is always shown in its "escaped" form.

Les caractères non réservés peuvent être protégés sans modifier la sémantique de l'URI, mais il faut l'éviter sauf si l'URI est utilisé dans un contexte qui ne permet pas l'utilisation du caractère non protégé. Par exemple « %7E » est parfois utilisé à la place de « ~ » dans les URL HTTP mais les deux sont en réalité équivalents dans ce contexte.

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)
utiliser le mécanisme d'échappement d'URI, c'est-à-dire, utiliser les %HH pour coder les octets non-sûrs.

Écrire un URI

Lorsqu'il est écrit, un URI doit être placé entre guillemets (« http://www.kernel.org »), encadré par des chevrons (<http://lwn.net>), ou placé sur une ligne indépendante. Un avertissement à propos des guillemets : ne jamais introduire une ponctuation supplémentaire (comme le point final d'une phrase ou la virgule séparant les éléments d'une liste) à l'intérieur de l'URI, car cela modifierait sa valeur (N.d.T. : cet avertissement vaut surtout pour les anglo-saxons ; en français l'usage veut que les éléments de ponctuations restent à l'extérieur des guillemets). On peut utiliser les chevrons à la place, ou basculer sur un système de notation qui n'incopore aucun caractère supplémentaire à l'intérieur des marques de citation. Ce système (N.d.T. : le nôtre !), appelé « nouveau » ou « logique » par les « Hart's Rules » et le « Oxford Dictionnary for Writes and Editors », est la pratique préférée des hackers en Grande-Bretagne et dans plusieurs langues européennes. Les documentations anciennes suggèrent d'insérer le préfixe « URL: » juste avant un URI, mais cette forme n'a jamais été utilisée réellement.

The URI syntax was designed to be unambiguous. However, as URIs have become commonplace, traditional media (television, radio, newspapers, billboards, etc.) have increasingly used abbreviated URI references consisting of only the authority and path portions of the identified resource (e.g., <www.w3.org/Addressing>). Such references are primarily intended for human interpretation rather than machine, with the assumption that context-based heuristics are sufficient to complete the URI (e.g., hostnames beginning with "www" are likely to have a URI prefix of "http://" and hostnames beginning with "ftp" likely to have a prefix of "ftp://"). Many client implementations heuristically resolve these references. Such heuristics may change over time, particularly when new schemes are introduced. Since an abbreviated URI has the same syntax as a relative URL path, abbreviated URI references cannot be used where relative URIs are permitted, and can be used only when there is no defined base (such as in dialog boxes). Don't use abbreviated URIs as hypertext links inside a document; use the standard format as described here.

STANDARDS

(IETF RFC 2396), (HTML 4.0).

NOTES

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

Les environnements Gnome et Kde divergent actuellement sur les URI qu'ils acceptent, en particulier dans leurs systèmes d'aide. Pour lister les pages de manuel, Gnome utilise <toc:man> alors que Kde utilise <man:(index)>. Pour lister les pages info, Gnome emploie <toc:info> et Kde <info:(dir)> (l'auteur de cette page préfère l'approche Kde, bien qu'un format plus régulier serait encore meilleur). En général, Kde utilise <file:/cgi-bin/> comme préfixe pour les fichiers générés. Kde préfère la documentation en Html, accessible avec <file:/cgi-bin/helpindex>. Gnome préfère le mécanisme ghelp pour stocker et retrouver la documentation. Aucun navigateur ne gère les références file: vers un répertoire à l'heure où j'écris ces lignes, ce qui rend difficile de se référer à un répertoire avec un URI navigable. Comme indiqué plus haut, ces environnements diffèrent sur la gestion du mécanisme info:, probablement leur plus importante divergence. On espère que Gnome et Kde vont converger vers des formats d'URI communs, et la future version de cette page décrira le résultat de cette convergence.

Sécurité

Un URI ne pose pas de problème de sécurité par lui-même. Il n'y a aucune garantie qu'une URL, qui localise une ressource à un moment donné continuera de le faire. Pas plus qu'il n'y a de garantie qu'une URL ne localisera pas une ressource différente à un autre moment. Les seules garanties peuvent être fournies par les personnes qui gèrent l'espace de noms de la ressource en question.

Il est parfois possible de construire une URL de manière qu'une tentative de réaliser une opération apparemment bénigne, comme accéder à la ressource associée, va en réalité produire une action éventuellement dommageable pour le correspondant. Les URL non sûres sont typiquement construites en indiquant un numéro de port différents de ceux réservés pour les protocoles en question. Le client, croyant contacter un site, va en réalité engager un autre protocole. Le contenu de l'URL contient des instructions, qui interprétées par l'autre protocole, produisent des résultats inattendus. Un exemple a été l'emploi d'une URL Gopher pour envoyer un message falsifié et indésiré sur un serveur SMTP.

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.

Il est clairement déraisonnable d'utiliser un URI qui contient un mot de passe censé être secret. En particulier, l'utilisation du mot de passe dans la partie « info utilisateur » de l'URI est fortement déconseillé, sauf s'il s'agit d'un de ces cas rares où le mot de passe est vraiment public.

BOGUES

Documentation may be placed in a variety of locations, so there currently isn't a good URI scheme for general online documentation in arbitrary formats. References of the form <file:///usr/doc/ZZZ> don't work, because different distributions and local installation requirements may place the files in different directories (it may be in /usr/doc, or /usr/local/doc, or /usr/share, or somewhere else). Also, the directory ZZZ usually changes when a version changes (though filename globbing could partially overcome this). Finally, using the file: scheme doesn't easily support people who dynamically load documentation from the Internet (instead of loading the files onto a local filesystem). A future URI scheme may be added (e.g., "userdoc:") to permit programs to include cross-references to more detailed documentation without having to know the exact location of that documentation. Alternatively, a future version of the filesystem specification may specify file locations sufficiently so that the file: scheme will be able to locate documentation.

De nombreux programmes et formats de fichiers n'incluent aucune manière d'incorporer ou l'implémenter des liens utilisant les URI.

Many programs can't handle all of these different URI formats; there should be a standard mechanism to load an arbitrary URI that automatically detects the users' environment (e.g., text or graphics, desktop environment, local user preferences, and currently executing tools) and invokes the right tool for any URI.

VOIR AUSSI

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

IETF RFC 2255

TRADUCTION

La traduction française de cette page de manuel a été créée par Christophe Blaess <https://www.blaess.fr/christophe/>, Stéphan Rafin <stephan.rafin@laposte.net>, Thierry Vignaud <tvignaud@mandriva.com>, François Micaux, Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe Guérard <fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-luc.coulon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux <thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@debian.org>, David Prévot <david@tilapin.org>, Cédric Boutillier <cedric.boutillier@gmail.com>, Frédéric Hantrais <fhantrais@gmail.com> et Jean-Pierre Giraud <jean-pierregiraud@neuf.fr>

Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à debian-l10n-french@lists.debian.org.

21 septembre 2025 Pages du manuel de Linux 6.16