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%09
recherche
gopher:// serveur_ip/
type_gopher
sélecteur%09
recherche%09
chaine_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, 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
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
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
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)
— 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.
(IETF
RFC 2396)
(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.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> ».