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 ]
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 ] @ ] hte [ : 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
hte 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 ; voyez
la documentation de ces outils pour plus de détails.
http - Serveur Web (HTTP)
http://serveur_ip/chemin
http://serveur_ip/chemin?requte
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. Voir 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 slecteur
gopher://serveur_ip/type_gopher slecteur%09recherche
gopher://serveur_ip/type_gopher slecteur%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 Ascii ou Tabulation), 0A hexadécimal
(LF Ascii), et 0D (CR Ascii).
mailto - Adresse courriel
mailto:adresse-courriel
Il s’agit d’une adresse courriel, en principe de la forme nom@nom_hte.
Voir 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, hte 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 (voir 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. Voir 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-noeud
info:(nom-de-fichier-virtuel)
info:(nom-de-fichier-virtuel)nom-de-noeud
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 rejete la syntaxe de l’autre. Les deux
premiers formats sont ceux de Gnome ; dans le nom de noeud, 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 noeud est supposé viser le noeud « 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:chane
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. Voir 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?porte
ldap://hostport/dn?attributs?porte?filtre
ldap://hostport/dn?attributs?porte?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). Des
informations supplémentaires sur les mécanismes d’URL LDAP sont
disponibles dans la RFC 2255 : Les composants de l’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 section
3).
attributs une liste d’attributs à renvoyer séparés par des virgules ;
voir la RFC2251 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.
Voir RFC 2254 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 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) — voir 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. [Ndt : 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 [Ndt : 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. Voir 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É
http://www.ietf.org/rfc/rfc2396.txt (IETF RFC 2396),
http://www.w3.org/TR/REC-html40 (HTML 4.0).
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
COLOPHON
Cette page fait partie de la publication 3.23 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
Cette page de manuel a été traduite et mise à jour par Christophe
Blaess <http://www.blaess.fr/christophe/> entre 1996 et 2003, puis par
Alain Portal <aportal AT univ-montp2 DOT fr> jusqu’en 2006, et mise à
disposition sur http://manpagesfr.free.fr/.
Les mises à jour et corrections de la version présente dans Debian sont
directement gérées par Julien Cristau <jcristau@debian.org> et l’équipe
francophone de traduction de Debian.
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> ».