Provided by: manpages-fr_3.32d0.2p4-1_all bug

NOM

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

SYNOPSIS

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

       URI_absolu = mecanisme ":" ( partie_hierarchique | partie_opaque )

       URI_relatif = ( chemin_reseau | chemin_absolu | chemin_relatif ) [ "?" requete

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

       partie_hierarchique = ( chemin_reseau | chemin_absolu ) [ "?" requete ]

       chemin_reseau = "//" autorite [ chemin_absolu ]

       chemin_absolu = "/"  segments_chemin

       chemin_relatif = segment_relatif [ chemin_relatif ]

DESCRIPTION

       Un Identificateur de Ressource Uniforme (URI) est une courte chaine  de
       caracteres identifiant une ressource physique ou abstraite (par exemple
       une page web). Une Localisation de Ressource Uniforme (URL) est un  URI
       qui   identifie   une   ressource  a  travers  son  moyen  d'acces  (sa
       << position >> reseau par exemple), plutot 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 meme si  la  ressource
       cesse d'exister ou devient indisponible.

       Les  URI constituent le mecanisme standard pour nommer les destinations
       des liens hypertextes pour les outils comme  les  navigateurs  web.  La
       chaine  << 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  etre  absolus  ou relatifs. Un identificateur absolu
       reference  une  ressource  independamment  du  contexte,  alors   qu'un
       identificateur   relatif   reference  une  ressource  en  decrivant  la
       difference par rapport au contexte  courant.  Dans  les  references  de
       chemins  relatifs,  les  segments  complets << . >> et << .. >> ont des
       significations   particulieres :   << le   niveau   actuel   dans    la
       hierarchie >>   et   << le  niveau  au-dessus  dans  la  hierarchie >>,
       respectivement, tout comme dans les systemes type UNIX. Un  segment  de
       chemin  qui  contient un caractere deux-points ne peut pas etre utilise
       comme premier segment du chemin d'un URI (par exemple << ceci:cela >>),
       car  on  le confondrait avec le mecanisme. Precedez 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 peripherique par
       une barre verticale dans les URI, ainsi << C: >> devient << C| >>.

       Un identificateur de fragment, s'il est present, reference une  portion
       particuliere  de  la ressource ; le texte apres le << # >> identifie le
       fragment. Un URI commencant par << # >> reference le fragment  dans  la
       ressource courante.

   Utilisation
       Il  y  a plusieurs schemas d'URI differents, chacun ajoutant des regles
       et des significations specifiques, mais ils sont volontairement  rendus
       le  plus  ressemblants  possible.  Par exemple, plusieurs schemas d'URL
       permettent le  format  suivant  pour  decrire  l'autorite  d'un  chemin
       reseau,  que  l'on  appellera  serveur_ip  (les  crochets encadrent les
       parties optionnelles) :

       serveur_ip = [user [ : password ] @ ] h^ote [ : port]

       Ce format permet d'inserer eventuellement un nom  d'utilisateur,  suivi
       eventuellement  d'un  mot  de passe, et/ou un numero de port. La partie
       h^ote est le nom de l'ordinateur, soit son nom  determine  par  le  DNS,
       soit  son  adresse  IP  (numeros  separes  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'identite fred (et le mot de passe
       fredpassword) en utilisant le port 8080. Evitez d'utiliser les mots  de
       passe  dans  les  URI  a cause des risques lies a la securite sitot que
       l'on ecrit un mot de passe. Si l'URL indique un  nom  d'utilisateur  et
       pas  de mot de passe, et si le serveur distant reclame un mot de passe,
       alors  le  programme  interpretant  l'URL  peut  en   demander   un   a
       l'utilisateur.

       Voici  les  mecanismes les plus courants utilises sur les systemes type
       UNIX, compris par de  nombreux  outils.  Notez  que  beaucoup  d'outils
       gerant  les  URI  ont  aussi  des  mecanismes internes ou specialises ;
       consultez la documentation de ces outils pour plus de details.

       http - Serveur Web (HTTP)

       http://serveur_ip/chemin
       http://serveur_ip/chemin?requ^ete

       Il s'agit d'une URL accedant a un  serveur  web  (HTTP).  Le  port  par
       defaut  est  80.  Si  le  chemin  reference  un  repertoire, le serveur
       choisira  ce  qu'il  renverra.  Habituellement,  si  un  fichier  nomme
       << index.html >>  ou  << index.htm >>  est  present,  son  contenu  est
       renvoye. Sinon, il cree et renvoie  une  liste  des  fichiers  dans  le
       repertoire   en   cours   avec   les  liens  appropries.  Un  exemple :
       <http://lwn.net>.

       Une requete peut etre formulee dans le format archaique  << isindex >>,
       consistant  en  mot ou phrase sans signe egal << = >>. Une requete peut
       aussi etre dans le format << GET >> plus long, qui a une  ou  plusieurs
       entrees  de  requetes  de la forme cl'e=valeur separees par un caractere
       << et commercial >>  << & >>.  Notez  que  la  cl'e  peut  etre  repetee
       plusieurs  fois,  et c'est au serveur web et ses programmes applicatifs
       de determiner s'il y  a  une  signification  pour  cela.  Il  y  a  une
       interaction malheureuse avec HTML/XML/SGML et le format de requete GET.
       Quand une telle  requete  avec  plusieurs  cles  est  incluse  dans  un
       document SGML/XML (y compris HTML), le << et commercial >> << & >> doit
       etre reecrit sous forme << &amp; >>.  Notez  que  toutes  les  requetes
       n'utilisent  pas  ce format ; elles peuvent etre trop longues pour etre
       stockee en  URL  et  utilisent  un  mecanisme  d'interaction  different
       (appele  POST)  sans  inclure  les  donnees  dans  l'URI.  Consultez la
       specification   Common   Gateway   Interface    (CGI)    a    l'adresse
       <http://www.w3.org/CGI> pour plus de details.

       ftp - File Transfer Protocol (FTP)

       ftp://serveur_ip/chemin

       Cette  URL  accede a un fichier a travers le protocole FTP. Le port par
       defaut (pour les commandes) est 21. Si aucun  nom  d'utilisateur  n'est
       inclus,  l'utilisateur  << anonymous >>  est employe, et dans ce cas de
       nombreux clients fournissent l'adresse courriel du requerant  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'electeur
       gopher://serveur_ip/type_gopher s'electeur%09recherche
       gopher://serveur_ip/type_gopher s'electeur%09recherche%09chaine_gopher+

       Le  port  gopher par defaut est 70. Le type_gopher est un champ compose
       d'un unique caractere indiquant le type de ressource Gopher a  laquelle
       l'URL fait reference. Le chemin entier paut aussi etre vide, auquel cas
       le delimiteur << / >> est aussi optionnel et le  type_gopher  prend  la
       valeur par defaut << 1 >>.

       selecteur est une chaine de selecteur Gopher. Dans le protocole Gopher,
       la chaine de selecteur est une sequence d'octets pouvant contenir  tous
       les octets sauf 09 hexadecimal (HT ACSII ou Tabulation), 0A hexadecimal
       (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^ote.
       Consultez  mailaddr(7)  pour  plus d'informations sur le format correct
       d'une adresse  courriel.  Notez  que  les  caracteres  %  doivent  etre
       transformes 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 hierarchique delimite par des points,
       comme << comp.infosystems.www.misc >>. Si nom-groupe-news  est  << * >>
       (comme   dans   <news:*>),   l'URL  reference  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  etre distingue d'un nom de groupe de
       news par la presence du caractere << @ >>.

       telnet - Connexion telnet

       telnet://serveur_ip/

       Le  mecanisme  d'URL  Telnet  est  utilise  pour  afficher  un  service
       interactif  accessible  par  le  protocole Telnet. Le caractere << / >>
       final peut  etre  omis.  Le  port  par  defaut  est  23.  Un  exemple :
       <telnet://melvyl.ucop.edu/>.

       file - Fichier normal

       file://serveur_ip/segments_chemins
       file:segments_chemins

       Ceci  represente  un fichier ou un repertoire accessible localement. En
       particulier, h^ote peut etre la chaine  << localhost >>  ou  une  chaine
       vide ;  elle est interpretee comme << la machine sur laquelle l'URL est
       en cours d'interpretation >>. Si le chemin conduit a un repertoire,  le
       navigateur  devrait  afficher  le  contenu du repertoire avec des liens
       pour chaque element. Tous les navigateurs ne le font  pas  encore.  KDE
       prend  en  charge les fichiers generes par l'URL <file:/cgi-bin>. Si le
       fichier n'est pas trouve, l'analyseur du  navigateur  peut  essayer  de
       developper le nom du fichier (consultez glob(7) et glob(3)).

       Le  second  format  (par  ex. <file:/etc/passwd>) est le format correct
       pour referencer 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 chaine vide en  guise
       de nom de serveur <file:///etc/passwd> ; cette forme a le meme effet et
       est reconnue facilement comme un URI par  les  analyseurs  des  anciens
       programmes.  Notez  que  si  vous desirez vraiment ecrire << debuter de
       l'emplacement actuel >>, n'indiquez pas  de  mecanisme ;  utilisez  une
       adresse   relative   comme   <../test.txt>,  qui  est  independante  du
       mecanisme. Un exemple de ce mecanisme est <file:///etc/passwd>.

       man - Pages de manuel

       man:nom-commande
       man:nom-commande(section)

       Ceci reference les pages de documentation en ligne  (man)  locales.  Le
       nom  de  la  commande  peut etre suivi eventuellement de parentheses et
       d'un numero de section. Consultez man(7) pour  plus  de  renseignements
       sur  la  signification  du  numero  de  section. Ce mecanisme d'URI est
       unique aux systemes UNIX (comme Linux) et n'est pas  encore  enregistre
       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 mecanisme reference les pages de documentation en-ligne info (creees
       par les fichiers texinfo), un format utilise par  les  outils  GNU.  Ce
       mecanisme  est  specifique aux systemes UNIX (comme Linux) et n'est pas
       encore enregistre 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  remplaces  par  des soulignes. Les deux formats suivants
       sont ceux de Kde ; les espaces doivent rester tels quels, meme si c'est
       interdit dans les standards d'URI. On peut esperer que dans l'avenir la
       plupart des outils comprendront les deux  formats  et  accepteront  des
       soulignes  en  remplacement  des  espaces. Dans tous les cas, le format
       sans nom de noeud est suppose 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:cha^ine

       Ce mecanisme parcourt une  base  de  donnees  de  courtes  (une  ligne)
       descriptions  des  commandes  et  renvoie  une  liste  des descriptions
       contenant la chaine. Seules les correspondances de mots  complets  sont
       renvoyees.  Consultez  whatis(1).  Ce mecanisme est unique aux systemes
       UNIX (comme Linux) et n'est pas encore enregistre par l'IETF.

       ghelp - Documentation d'aide Gnome

       ghelp:nom-application

       Ceci charge la documentation d'aide Gnome pour l'application  indiquee.
       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'ee
       ldap://hostport/dn?attributs?port'ee?filtre
       ldap://hostport/dn?attributs?port'ee?filtre?extensions

       Ce  mecanisme  prend  en  charge  les  requetes  utilisant le protocole
       Lightweight  Directory  Access  Protocol  (LDAP),  pour  interroger  un
       ensemble    de    serveurs    a    propos   d'informations   organisees
       hierarchiquement (comme des gens ou  des  ressources  de  calcul).  Des
       informations   supplementaires  sur  les  mecanismes  d'URL  LDAP  sont
       disponibles dans  la  RFC 2255 :  <http://www.ietf.org/rfc/rfc2255.txt>
       Les composants de l'URL sont :

       hostport    le  serveur  LDAP  a  interroger, ecrit comme un nom d'hote
                   suivi eventuellement par un deux-points  et  un  numero  de
                   port. Le port TCP pour le LDAP est 389. Si le nom est vide,
                   le client determine le serveur LDAP a 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 a renvoyer separes par des virgules ;
                   voir   la  RFC 2251  section 4.1.5.  Par  defaut  tous  les
                   attributs sont renvoyes..

       portee      indique la portee de la recherche qui peut etre  << base >>
                   (recherche  d'objet  de  base), << one >> (recherche sur un
                   niveau), ou << sub >> (recherche dans un  sous-arbre).  Par
                   defaut, on considere << base >>.

       filtre      indique le filtre de recherche (sous-ensemble des entrees a
                   renvoyer). Par defaut, toutes les entrees  sont  renvoyees.
                   Consultez   RFC 2254  <http://www.ietf.org/rfc/rfc2254.txt>
                   section 4.

       extensions  une liste de paires type=valeur separees par des  virgules,
                   ou  la  portion =valeur peut etre omise pour les options ne
                   la necessitant pas. Une extension prefixee par  un  << ! >>
                   est  critique  (doit etre pris en charge pour etre valide),
                   sinon elle est non-critique (facultative).

       Les requetes LDAP sont plus faciles a comprendre par  l'exemple.  Voici
       une requete demandant a ldap.itd.umich.edu des informations a propos de
       l'Universite 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 a host.com, sur le port  6666  des  informations  sur  la
       personne  de  nom  courant  (cn)  << Babs  Jensen >>  a 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 mecanisme designe une base de donnees  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'hote,  suivi
       eventuellement  d'un  deux-points  et  d'un  numero de port (par defaut
       210).

       La premiere forme designe une base de donnees WAIS pour les recherches.
       La  seconde  designe  une  recherche  particuliere  dans  la  base WAIS
       indiquee.  La  troisieme  forme  designe  un  document  particulier   a
       retrouver  dans  la base de donnees WAIS. wtype est la designation WAIS
       du type d'objet et wpath est l'identificateur WAIS du document.

       Autres m'ecanismes

       Il existe d'autres mecanismes URI. La plupart des outils  traitant  les
       URI  acceptent  un  jeu  d'URI  internes  (par  exemple,  Mozilla  a un
       mecanisme about: pour  les  informations  internes,  et  le  navigateur
       d'aide  Gnome  a un mecanisme toc: pour diverses operations). Il y a de
       nombreux mecanismes qui ont ete definis mais  pas  tres  utilises  pour
       l'instant  (par  exemple, prospero). Le mecanisme nntp: est deconseille
       en faveur de celui news:. Les  URN  seront  prises  en  charge  par  le
       mecanisme   urn:   avec  des  espaces  de  noms  hierarchique  (p.ex. :
       urn:ietf:... pour les documents IETF). Pour le moment, les URN ne  sont
       pas  tres largement implementes. Tous les outils ne gerent pas tous les
       mecanismes.

   Codage des caract`eres
       Les URI utilisent un nombre limite de caracteres afin d'etre saisis  et
       utilises dans de nombreuses situations.

       Les  caracteres suivants sont reserves ; ils peuvent apparaitre dans un
       URI, mais leurs usages est limites aux fonctionnalites  reservees  (les
       donnees conflictuelles doivent etre protegees avant de former l'URI) :

                 ; / ? : @ & = + $ ,

       Les  caracteres  non-reserves  peuvent  etre  inclus  dans  un URI. Les
       caracteres  non-reserves  incluent   les   majuscules   et   minuscules
       anglaises,  les  chiffres  decimaux, et l'ensemble suivant de signes de
       ponctuation et de symboles :

               - _ . ! ~ * ' ( )

       Tous les autres caracteres doivent etre proteges. Un octet protege  est
       encode  sous  forme  d'un triplet de caracteres, consistant en un signe
       pourcent << % >> suivi de deux chiffres  hexadecimaux  representant  le
       code  de  l'octet (les lettres hexadecimales peuvent etre en majuscules
       ou en minuscules). Par exemple un espace blanc doit etre  protege  sous
       forme  << %20 >>,  une tabulation << %09 >> et le << & >> en << %26 >>.
       Comme le caractere "% >>" a toujours un role reserve pour proteger  les
       autres  caracteres,  il  faut  le proteger sous forme << %25 >>. Il est
       courant de proteger le caractere espace en symbole  plus  << + >>  dans
       les requetes. Cette pratique n'est pas defini uniformement dans les RFC
       correspondantes (qui recommandent %20  plutot)  mais  tous  les  outils
       acceptant  les  URI  avec  des  requetes  preparees  ainsi. Une URI est
       toujours montree dans sa forme protegee.

       Les caracteres non-reserves peuvent  etre  proteges  sans  modifier  la
       semantique  de  l'URI,  mais il faut l'eviter sauf si l'URI est utilise
       dans un contexte qui ne  permet  pas  l'utilisation  du  caractere  non
       protege.  Par  exemple  << %7E >>  est  parfois  utilise  a la place de
       << ~ >> dans les URL HTTP mais les deux  sont  en  realite  equivalents
       dans ce contexte.

       Pour les URI qui doivent manipuler des caracteres hors du jeu ASCII, la
       specification HTML 4.01 (section B.2) et  la  RFC 2718  (section 2.2.5)
       preconisent l'approche suivante :

       1.  traduire  le  caractere  en  sequence UTF-8 (RFC 2279) -- consultez
           utf-8(7) -- puis

       2.  utiliser le mecanisme d'echappement d'URI,  c'est-a-dire,  utiliser
           les %HH pour coder les octets non-surs.

   'Ecrire un URI
       Lorsqu'il   est   ecrit,  un  URI  doit  etre  place  entre  guillemets
       ("http://www.kernelnotes.org"),    encadre     par     des     chevrons
       (<http://lwn.net>),   ou   place   sur   une   ligne  independante.  Un
       avertissement a  propos  des  guillemets :  Ne  jamais  introduire  une
       ponctuation  supplementaire  (comme  le  point final d'une phrase ou la
       virgule separant les elements d'une liste) a l'interieur de l'URI,  car
       cela  modifierait  sa  valeur  (N.d.T. : cet avertissement vaut surtout
       pour les anglo-saxons ; en francais l'usage veut que  les  elements  de
       ponctuations  restent  a  l'exterieur des guillemets). On peut utiliser
       les chevrons a la place, ou basculer sur un  systeme  de  notation  qui
       n'incopore  aucun caractere supplementaire a l'interieur des marques de
       citation. Ce systeme (N.d.T. : le  notre !),  appele  << nouveau >>  ou
       << logique >>  par  les  << Hart's Rules >> et le << Oxford Dictionnary
       for Writes and Editors >>, est la pratique preferee des hackers dans le
       monde  entier.  Consultez  la  section  sur le style d'ecriture dans le
       Jargon                                                             File
       (http://www.fwi.uva.nl/~mes/jargon/h/HackerWritingStyle.html  pour plus
       de details. Les documentations anciennes suggerent d'inserer le prefixe
       << URL: >> juste avant un URI, mais cette forme n'a jamais ete utilisee
       reellement.

       La syntaxe des URI a ete concue pour eviter les ambiguites.  Toutefois,
       comme  les  URI  sont  devenus  de  plus  en  plus repandus, les medias
       traditionnels television, radio, journaux et magazines...) ont  utilise
       de  maniere  croissante  des abreviations d'URI, consistant en la seule
       partie autorite et segments de chemin  de  la  ressource  (par  exemple
       <www.w3.org/Addressing>).  De tels references sont surtout prevues pour
       une interpretation humaine, avec la supposition que la comprehension du
       contexte  permet  de  completer  l'URI  (par  exemple  les noms d'hotes
       commencant par << www >> se prefixent avec << http:// >>  et  les  noms
       commencant  par  << ftp >>  doivent  se prefixer avec << ftp:// >>). De
       nombreux clients resolvent ces references avec de telles  heuristiques.
       Elle  peuvent  toutefois  evoluer,  particulierement  quand de nouveaux
       mecanismes sont introduits. Comme les URI abreges ont la  meme  syntaxe
       qu'un  chemin  d'URL  relative,  les  references  abregees  ne sont pas
       utilisables lorsque des URI relatifs  sont  autorises.  N'utilisez  pas
       d'URI  abreges  comme  liens  hypertexte dans un document ; utilisez le
       format standard decrit ici.

CONFORMIT'E

       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
       systeme  Linux  devrait  etre  capable  de  traiter   (directement   ou
       indirectement)  tous  les  mecanismes  decrits  ici,  y compris man: et
       info:. Sous-traiter ces elements a un autre programme est tout  a  fait
       acceptable, et meme encourage.

       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 donnees, 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 recemment  ajoutee,  ou
       incluent  juste  l'URI dans le texte (les visualiseurs doivent detecter
       le :// comme portion d'URI).

       Les environnements Gnome et Kde  divergent  actuellement  sur  les  URI
       qu'ils  acceptent,  en  particulier  dans  leurs  systemes 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   prefere
       l'approche   Kde,   bien  qu'un  format  plus  regulier  serait  encore
       meilleur). En general, Kde utilise <file:/cgi-bin/> comme prefixe  pour
       les  fichiers generes. Kde prefere la documentation en Html, accessible
       avec <file:/cgi-bin/helpindex>. Gnome prefere le mecanisme  ghelp  pour
       stocker  et  retrouver  la  documentation. Aucun navigateur ne gere les
       references file: vers un repertoire a l'heure ou j'ecris ces lignes, ce
       qui rend difficile de se referer a un repertoire avec un URI navigable.
       Comme indique plus haut, ces environnements different sur la gestion du
       mecanisme  info:,  probablement  leur  plus  importante  divergence. On
       espere que Gnome et Kde vont converger vers des formats d'URI  communs,
       et  la  future  version  de  cette  page  decrira  le resultat de cette
       convergence.

   S'ecurit'e
       Un URI ne pose pas de probleme de  securite  par  lui-meme.  Il  n'y  a
       aucune  garantie  qu'une  URL,  qui  localise une ressource a un moment
       donne continuera de le faire. Pas plus qu'il n'y a de  garantie  qu'une
       URL  ne  localisera pas une ressource differente a un autre moment. Les
       seules garanties peuvent etre fournies par  les  personnes  qui  gerent
       l'espace de noms de la ressource en question.

       Il  est  parfois  possible  de  construire  une  URL  de maniere qu'une
       tentative de realiser une operation apparemment benigne, comme  acceder
       a   la   ressource   associee,   va  en  realite  produire  une  action
       eventuellement dommageable pour le correspondant.  Les  URL  non  sures
       sont  typiquement construites en indiquant un numero de port differents
       de ceux reserves pour les protocoles en question.  Le  client,  croyant
       contacter un site, va en realite engager un autre protocole. Le contenu
       de l'URL  contient  des  instructions,  qui  interpretees  par  l'autre
       protocole,  produisent  des  resultats  inattendus.  Un  exemple  a ete
       l'emploi d'une URL Gopher pour envoyer un message falsifie et  indesire
       sur un serveur SMTP.

       Il faut etre prudent en utilisant une URL qui indique un numero de port
       different de celui du protocole, particulierement si ce numero est dans
       l'espace reserve.

       Il  faut  s'assurer que lorsque l'URI contient des delimiteurs proteges
       pour un protocole donne (par exemple CR et LF pour le protocole telnet)
       qu'ils  ne soient pas << deproteges >> avant la transmission. Ceci peut
       violer le protocole, mais evite le risque que ces caracteres servent  a
       simuler  une  operation  dans  ce protocole, ce qui peut conduire a des
       actions distantes eventuellement nocives.

       Il est clairement deraisonnable d'utiliser un URI qui contient  un  mot
       de  passe  cense  etre  secret. En particulier, l'utilisation du mot de
       passe dans la partie << info  utilisateur >>  de  l'URI  est  fortement
       deconseille,  sauf s'il s'agit d'un de ces cas rares ou 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  mecanisme d'URI pour la documentation
       generale en-ligne, dans des formats arbitraires. Les  reference  de  la
       forme   <file:///usr/doc/ZZZ>  ne  fonctionnent  pas,  car  differentes
       distributions et installations locales peuvent placer les fichiers dans
       divers  repertoires  (cela  peut  etre  /usr/doc, ou /usr/local/doc, ou
       /usr/share, ou autre part).  De  meme,  le  repertoire  ZZZ  change  en
       principe  avec le numero de version (bien que le developpement des noms
       de fichiers puisse  partiellement  couvrir  ce  probleme).  Finalement,
       l'utilisation  du  mecanisme  file: n'est pas recommandee pour les gens
       qui consultent la documentation dynamiquement  depuis  Internet  plutot
       que  de la telecharger sur leur systeme de fichiers local. Un mecanisme
       d'URI sera peut etre ajoute dans l'avenir (p.ex. : << userdoc: >>) pour
       permettre   aux   programme   d'inclure   des  references  vers  de  la
       documentation plus detaillees  sans  avoir  a  connaitre  l'emplacement
       exact  de celle-ci. Autrement, une version future des specifications du
       systeme  de  fichiers  peut  decrire  les   emplacements   de   maniere
       suffisamment precise pour que le mecanisme file: soit capable de situer
       la documentation.

       De nombreux programmes et formats de fichiers n'incluent aucune maniere
       d'incorporer ou l'implementer des liens utilisant les URI.

       Beaucoup   de   programmes   ne  traitent  pas  tous  les  formats  URI
       differents ; il devrait y avoir un mecanisme standard pour  charger  un
       URI  quelconque qui detecte automatiquement l'environnement utilisateur
       (p.ex. : texte ou graphique, environnement de  bureau,  preferences  de
       l'utilisateur,  outils  en  cours  d'execution) 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.32 du projet man-pages
       Linux. Une description du projet et des instructions pour signaler  des
       anomalies       peuvent       etre       trouvees      a      l'adresse
       <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

       Depuis 2010, cette traduction est maintenue a l'aide  de  l'outil  po4a
       <URL:http://po4a.alioth.debian.org/>   par   l'equipe   de   traduction
       francophone       au       sein        du        projet        perkamon
       <URL:http://perkamon.alioth.debian.org/>.

       Christophe  Blaess  <URL:http://www.blaess.fr/christophe/> (1996-2003),
       Alain  Portal  <URL:http://manpagesfr.free.fr/>  (2003-2006).    Julien
       Cristau et l'equipe francophone de traduction de Debian (2006-2009).

       Veuillez   signaler   toute   erreur   de   traduction  en  ecrivant  a
       <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
       paquet manpages-fr.

       Vous  pouvez  toujours avoir acces a la version anglaise de ce document
       en utilisant la commande << man -L C <section> <page_de_man> >>.