Provided by: manpages-fr_3.65d1p1-1_all 
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.
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.kernelnotes.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@xyz.com:8080/> se connecte dans le serveur web sur
l'ordinateur xyz.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
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 « & ». 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.
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.
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
Lorsqu'il est écrit, un URI doit être placé entre guillemets
(« http://www.kernelnotes.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 dans le monde
entier. Consultez la section sur le style d'écriture dans le Jargon File
⟨http://www.fwi.uva.nl/~mes/jargon/h/HackerWritingStyle.html⟩ pour plus de détails. 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.
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.txt⟩
COLOPHON
Cette page fait partie de la publication 3.65 du projet man-pages Linux. Une description
du projet et des instructions pour signaler des anomalies peuvent être trouvées à
l'adresse http://www.kernel.org/doc/man-pages/.
TRADUCTION
Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a
<http://po4a.alioth.debian.org/> par l'équipe de traduction francophone au sein du projet
perkamon <http://perkamon.alioth.debian.org/>.
Christophe Blaess <http://www.blaess.fr/christophe/> (1996-2003), Alain Portal
<http://manpagesfr.free.fr/> (2003-2006). Julien Cristau et l'équipe francophone de
traduction de Debian (2006-2009).
Veuillez signaler toute erreur de traduction en écrivant à
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le paquet
manpages-fr.
Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la
commande « man -L C <section> <page_de_man> ».