uri(7) Miscellaneous Information Manual uri(7)
NOM
uri, url, urn - Identificateur de ressource uniforme (URI), comprenant
URL ou URN
SYNOPSIS
URI = [ URI_absolu | URI_relatif ] [ "#" fragment ]
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 « posi-
tion » 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 syno-
nym 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 identifi-
cateur 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 particu-
lières : « le niveau actuel dans la hiérarchie » et « le niveau au-des-
sus 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| ».
A fragment identifier, if included, refers to a particular named por-
tion (fragment) of a resource; text after a '#' identifies the frag-
ment. A URI beginning with '#' refers to that fragment in the current
resource.
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 compu-
ter, either its name as determined by DNS or an IP address (numbers se-
parated by periods). Thus the URI <http://fred:fredpass-
word@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 ; consul-
tez 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 en-
tré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 malheu-
reuse 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 nom-
breux 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 va-
leur 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 trans-
formé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 dispo-
nibles. 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 identifica-
teur 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 interac-
tif accessible par le protocole Telnet. Le caractère « / » final peut
être omis. Le port par défaut est 23. Un exemple : <telnet://mel-
vyl.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)).
The second format (e.g., <file:/etc/passwd>) is a correct format for
referring to a local file. However, older standards did not permit this
format, and some programs don't recognize this as a URI. A more por-
table syntax is to use an empty string as the server name, for example,
<file:///etc/passwd>; this form does the same thing and is easily reco-
gnized by pattern matchers and older programs as a URI. Note that if
you really mean to say "start from the current location", don't specify
the scheme at all; use a relative address like <../test.txt>, which has
the side-effect of being scheme-independent. An example of this scheme
is <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 en-
core enregistré par l'IETF. Actuellement, Gnome et Kde divergent dans
la syntaxe d'URI et chacun rejette la syntaxe de l'autre. Les deux pre-
miers formats sont ceux de Gnome ; dans le nom de nœud, tous les es-
paces 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 in-
terdit 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) des-
criptions 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 Light-
weight 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éter-
mine 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 » (re-
cherche 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 à ren-
voyer). Par défaut, toutes les entrées sont renvoyées. Consultez
RFC 2254 ⟨http://www.ietf.org/rfc/rfc2254.txt⟩ section 4.
extensions
a comma-separated list of type=value pairs, where the =value
portion may be omitted for options not requiring it. An exten-
sion prefixed with a '!' is critical (must be supported to be
valid), otherwise it is noncritical (optional).
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 per-
sonne 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 do-
cument (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 indi-
qué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éca-
nisme 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 im-
plé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) :
; / ? : @ & = + $ ,
Unreserved characters may be included in a URI. Unreserved characters
include uppercase and lowercase Latin letters, decimal digits, and the
following limited set of punctuation marks and symbols:
- _ . ! ~ * ' ( )
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 carac-
tère "% »" a toujours un rôle réservé pour protéger les autres carac-
tè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.
For URIs which must handle characters outside the US ASCII character
set, the HTML 4.01 specification (section B.2) and IETF RFC 3986 (last
paragraph of section 2.5) recommend the following approach:
(1) translate the character sequences into UTF-8 (IETF RFC 3629)—see
utf-8(7)—and then
(2) utiliser le mécanisme d'échappement d'URI, c'est-à-dire, utiliser
les %HH pour coder les octets non-sûrs.
Écrire un URI
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 bra-
ckets instead, or switch to a quoting system that never includes extra-
neous 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 in various European languages. Older documents suggested
inserting the prefix "URL:" just before the URI, but this form has ne-
ver 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 tradi-
tionnels télévision, radio, journaux et magazines...) ont utilisé de
manière croissante des abréviations d'URI, consistant en la seule par-
tie 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 com-
menç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éca-
nismes 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.
STANDARDS
(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 sys-
tème Linux devrait être capable de traiter (directement ou indirecte-
ment) tous les mécanismes décrits ici, y compris man: et info:.
Sous-traiter ces éléments à un autre programme est tout à fait accep-
table, 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 for-
mat de données, voir la documentation sur ce format. HTML utilise le
format <A HREF="uri"> text </A>. Les fichiers texinfo utilisent le for-
mat @uref{uri}. Man et mdoc ont une macro UR récemment ajoutée, ou in-
cluent 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 lis-
ter 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/hel-
pindex>. 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:, proba-
blement 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 au-
cune 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 tenta-
tive 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 ac-
tions 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écon-
seillé, 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 distribu-
tions 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échar-
ger 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. Autre-
ment, 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⟩
TRADUCTION
La traduction française de cette page de manuel a été créée par Chris-
tophe Blaess <https://www.blaess.fr/christophe/>, Stéphan Rafin <ste-
phan.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.cou-
lon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux
<thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centra-
liens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard <si-
mon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@de-
bian.org>, David Prévot <david@tilapin.org>, Cédric Boutillier <ce-
dric.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⟩.
Pages du manuel de Linux 6.03 5 février 2023 uri(7)
Generated by dwww version 1.15 on Sat Jun 29 00:26:48 CEST 2024.