uri

URI(7)                     Manuel du programmeur Linux                    URI(7)



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

SYNOPSIS
       URI = [ URI_absolu | URI_relatif ] [ "#" fragment ]

       URI_absolu = mécanisme ":" ( partie_hiérarchique | partie_opaque )

       URI_relatif = ( chemin_réseau | chemin_absolu | chemin_relatif ) [ "?" requête

       mécanisme = "http" | "ftp" | "gopher" | "mailto" | "news" | "telnet" |
                     "file" | "man" | "info" | "whatis" | "ldap" | "wais" | ...

       partie_hierarchique = ( chemin_réseau | chemin_absolu ) [ "?" requête ]

       chemin_réseau = "//" autorité [ chemin_absolu ]

       chemin_absolu = "/"  segments_chemin

       chemin_relatif = segment_relatif [ chemin_relatif ]

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.

       URIs are the standard way to name hypertext link destinations for tools
       such as web browsers.  The string "http://www.kernel.org" is a URL (and
       thus it is also a URI).  Many people use the term URL loosely as a
       synonym for URI (though technically URLs are a subset of URIs).

       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]

       This format allows you to optionally insert a username, a user plus
       password, and/or a port number.  The host is the name of the host
       computer, either its name as determined by DNS or an IP address (numbers
       separated by periods).  Thus the URI
       <http://fred:fredpassword@example.com:8080/> logs into a web server on
       host example.com as fred (using fredpassword) using port 8080.  Avoid
       including a password in a URI if possible because of the many security
       risks of having a password written down.  If the URL supplies a username
       but no password, and the remote server requests a password, the program
       interpreting the URL should request one from the user.

       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

       Il s'agit d'une URL accédant à un serveur web (HTTP). Le port par défaut
       est 80. Si le chemin référence un répertoire, le serveur choisira ce
       qu'il renverra. Habituellement, si un fichier nommé « index.html » ou
       « index.htm » est présent, son contenu est renvoyé. Sinon, il crée et
       renvoie une liste des fichiers dans le répertoire en cours avec les liens
       appropriés. Un exemple : <http://lwn.net>.

       Une requête peut être formulée dans le format archaïque « isindex »,
       consistant en mot ou phrase sans signe égal « = ». Une requête peut aussi
       être dans le format « GET » plus long, qui a une ou plusieurs entrées de
       requêtes de la forme clé=valeur séparées par un caractère « et
       commercial » « & ». Notez que la clé peut être répétée plusieurs fois, et
       c'est au serveur web et ses programmes applicatifs de déterminer s'il y a
       une signification pour cela. Il y a une interaction malheureuse avec
       HTML/XML/SGML et le format de requête GET. Quand une telle requête avec
       plusieurs clés est incluse dans un document SGML/XML (y compris HTML), le
       « et commercial » « & » doit être réécrit sous forme « &amp; ». Notez que
       toutes les requêtes n'utilisent pas ce format ; elles peuvent être trop
       longues pour être stockée en URL et utilisent un mécanisme d'interaction
       différent (appelé POST) sans inclure les données dans l'URI. Consultez la
       spécification Common Gateway Interface (CGI) à l'adresse
       ⟨http://www.w3.org/CGI⟩ pour plus de détails.

       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+

       Le port gopher par défaut est 70. Le type_gopher est un champ composé
       d'un unique caractère indiquant le type de ressource Gopher à laquelle
       l'URL fait référence. Le chemin entier paut aussi être vide, auquel cas
       le délimiteur « / » est aussi optionnel et le type_gopher prend la valeur
       par défaut « 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, ⟨http://www.ietf.org/rfc/rfc1036.txt⟩ 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

       Ce mécanisme référence les pages de documentation en ligne info (créées
       par les fichiers texinfo), un format utilisé par les outils GNU. Ce
       mécanisme est spécifique aux systèmes UNIX (comme Linux) et n'est pas
       encore enregistré par l'IETF. Actuellement, Gnome et Kde divergent dans
       la syntaxe d'URI et chacun rejette la syntaxe de l'autre. Les deux
       premiers formats sont ceux de Gnome ; dans le nom de nœud, tous les
       espaces sont remplacés par des soulignés. Les deux formats suivants sont
       ceux de Kde ; les espaces doivent rester tels quels, même si c'est
       interdit dans les standards d'URI. On peut espérer que dans l'avenir la
       plupart des outils comprendront les deux formats et accepteront des
       soulignés en remplacement des espaces. Dans tous les cas, le format sans
       nom de nœud est supposé viser le nœud « Top »". Exemples de format
       Gnome : <info:gcc> et <info:gcc#G++_and_GCC>. Exemples de format Kde :
       <info:(gcc)> et <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
       ⟨http://www.ietf.org/rfc/rfc2255.txt⟩ pour plus d'informations sur la
       forme des URL LDAP. Les composantes de cette URL sont :

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

       dn          Le nom complet (Distinguished Name) LDAP, qui identifie
                   l'objet de base de la recherche LDAP (voir RFC 2253
                   ⟨http://www.ietf.org/rfc/rfc2253.txt⟩ section 3).

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

       portée      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 ».

       filtre      indique le filtre de recherche (sous-ensemble des entrées à
                   renvoyer). Par défaut, toutes les entrées sont renvoyées.
                   Consultez RFC 2254 ⟨http://www.ietf.org/rfc/rfc2254.txt⟩
                   section 4.

       extensions  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 ⟨http://www.ietf.org/rfc/rfc1625.txt⟩ 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).

       La première forme désigne une base de données WAIS pour les recherches.
       La seconde désigne une recherche particulière dans la base WAIS indiquée.
       La troisième forme désigne un document particulier à retrouver dans la
       base de données WAIS. wtype est la désignation WAIS du type d'objet et
       wpath est l'identificateur WAIS du document.

       Autres mécanismes

       Il existe d'autres mécanismes URI. La plupart des outils traitant les URI
       acceptent un jeu d'URI internes (par exemple, Mozilla a un mécanisme
       about: pour les informations internes, et le navigateur d'aide Gnome a un
       mécanisme toc: pour diverses opérations). Il y a de nombreux mécanismes
       qui ont été définis mais pas très utilisés pour l'instant (par exemple,
       prospero). Le mécanisme nntp: est déconseillé en faveur de celui news:.
       Les URN seront prises en charge par le mécanisme urn: avec des espaces de
       noms hiérarchique (p.ex. : urn:ietf:... pour les documents IETF). Pour le
       moment, les URN ne sont pas très largement implémentés. Tous les outils
       ne gèrent pas tous les mécanismes.

   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 anglaises,
       les chiffres décimaux, et l'ensemble suivant de signes de ponctuation et
       de symboles :

               - _ . ! ~ * ' ( )

       Tous les autres caractères doivent être protégés. Un octet protégé est
       encodé sous forme d'un triplet de caractères, consistant en un signe
       pourcent « % » suivi de deux chiffres hexadécimaux représentant le code
       de l'octet (les lettres hexadécimales peuvent être en majuscules ou en
       minuscules). Par exemple un espace blanc doit être protégé sous forme
       « %20 », une tabulation « %09 » et le « & » en « %26 ». Comme le
       caractère "% »" a toujours un rôle réservé pour protéger les autres
       caractères, il faut le protéger sous forme « %25 ». Il est courant de
       protéger le caractère espace en symbole plus « + » dans les requêtes.
       Cette pratique n'est pas défini uniformément dans les RFC correspondantes
       (qui recommandent %20 plutôt) mais tous les outils acceptant les URI avec
       des requêtes préparées ainsi. Une URI est toujours montrée dans sa forme
       protégée.

       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.

       Pour les URI qui doivent manipuler des caractères hors du jeu ASCII, la
       spécification HTML 4.01 (section B.2) et la RFC 2718 (section 2.2.5)
       préconisent l'approche suivante :

       1.  traduire le caractère en séquence UTF-8 (RFC 2279) — consultez
           utf-8(7) — puis

       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
       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
       hackers worldwide (see the Jargon File's section on Hacker Writing Style,
       ⟨http://www.fwi.uva.nl/~mes/jargon/h/HackerWritingStyle.html⟩, for more
       information).  Older documents suggested inserting the prefix "URL:" just
       before the URI, but this form has never caught on.

       La syntaxe des URI a été conçue pour éviter les ambiguïtés. Toutefois,
       comme les URI sont devenus de plus en plus répandus, les médias
       traditionnels télévision, radio, journaux et magazines...) ont utilisé de
       manière croissante des abréviations d'URI, consistant en la seule partie
       autorité et segments de chemin de la ressource (par exemple
       <www.w3.org/Addressing>). De tels références sont surtout prévues pour
       une interprétation humaine, avec la supposition que la compréhension du
       contexte permet de compléter l'URI (par exemple les noms d'hôtes
       commençant par « www » se préfixent avec « http:// » et les noms
       commençant par « ftp » doivent se préfixer avec « ftp:// »). De nombreux
       clients résolvent ces références avec de telles heuristiques. Elle
       peuvent toutefois évoluer, particulièrement quand de nouveaux mécanismes
       sont introduits. Comme les URI abrégés ont la même syntaxe qu'un chemin
       d'URL relative, les références abrégées ne sont pas utilisables lorsque
       des URI relatifs sont autorisés. N'utilisez pas d'URI abrégés comme liens
       hypertexte dans un document ; utilisez le format standard décrit ici.

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

NOTES
       Un outil acceptant les URI (par exemple un navigateur web) sur un système
       Linux devrait être capable de traiter (directement ou indirectement) tous
       les mécanismes décrits ici, y compris man: et info:. Sous-traiter ces
       éléments à un autre programme est tout à fait acceptable, et même
       encouragé.

       Techniquement, la notation d'un fragment ne fait pas partie de l'URI.

       Pour savoir comment incorporer des URI (y compris des URL) dans un format
       de données, voir la documentation sur ce format. HTML utilise le format
       <A HREF="uri"> text </A>. Les fichiers texinfo utilisent le format
       @uref{uri}. Man et mdoc ont une macro UR récemment ajoutée, ou incluent
       juste l'URI dans le texte (les visualiseurs doivent détecter le :// comme
       portion d'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.

       Il faut être prudent en utilisant une URL qui indique un numéro de port
       différent de celui du protocole, particulièrement si ce numéro est dans
       l'espace réservé.

       Il faut s'assurer que lorsque l'URI contient des délimiteurs protégés
       pour un protocole donné (par exemple CR et LF pour le protocole telnet)
       qu'ils ne soient pas « déprotégés » avant la transmission. Ceci peut
       violer le protocole, mais évite le risque que ces caractères servent à
       simuler une opération dans ce protocole, ce qui peut conduire à des
       actions distantes éventuellement nocives.

       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
       La documentation peut se trouver dans un grand nombre d'endroit, ainsi il
       n'y a pas encore de bon mécanisme d'URI pour la documentation générale en
       ligne, dans des formats arbitraires. Les référence de la forme
       <file:///usr/doc/ZZZ> ne fonctionnent pas, car différentes distributions
       et installations locales peuvent placer les fichiers dans divers
       répertoires (cela peut être /usr/doc, ou /usr/local/doc, ou /usr/share,
       ou autre part). De même, le répertoire ZZZ change en principe avec le
       numéro de version (bien que le développement des noms de fichiers puisse
       partiellement couvrir ce problème). Finalement, l'utilisation du
       mécanisme file: n'est pas recommandée pour les gens qui consultent la
       documentation dynamiquement depuis Internet plutôt que de la télécharger
       sur leur système de fichiers local. Un mécanisme d'URI sera peut être
       ajouté dans l'avenir (p.ex. : « userdoc: ») pour permettre aux programme
       d'inclure des références vers de la documentation plus détaillées sans
       avoir à connaître l'emplacement exact de celle-ci. Autrement, une version
       future des spécifications du système de fichiers peut décrire les
       emplacements de manière suffisamment précise pour que le mécanisme file:
       soit capable de situer la documentation.

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

       Beaucoup de programmes ne traitent pas tous les formats URI différents ;
       il devrait y avoir un mécanisme standard pour charger un URI quelconque
       qui détecte automatiquement l'environnement utilisateur (p.ex. : texte ou
       graphique, environnement de bureau, préférences de l'utilisateur, outils
       en cours d'exécution) et invoque le bon outil quelque soit l'URI.

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

       IETF RFC 2255 ⟨http://www.ietf.org/rfc/rfc2255.txtCOLOPHON
       Cette page fait partie de la publication 5.10 du projet man-pages Linux.
       Une description du projet et des instructions pour signaler des anomalies
       et la dernière version de cette page peuvent être trouvées à l'adresse
       https://www.kernel.org/doc/man-pages/.


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> et Frédéric Hantrais <fhantrais@gmail.com>

       Cette traduction est une documentation libre ; veuillez vous reporter à
       la GNU General Public License version 3
       ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 ⟨⟩.




Linux                             13 août 2020                            URI(7)