URL

Apprendre encore plus Il a été suggéré que Clean URL soit fusionné dans cet article. ( Discuter ) Proposé depuis février 2022.

Un localisateur de ressources uniforme ( URL ), familièrement appelé adresse Web , ^[1] est une référence à une ressource Web qui spécifie son emplacement sur un réseau informatique et un mécanisme pour la récupérer. Une URL est un type spécifique d’ Uniform Resource Identifier (URI), ^{[2] [3]} bien que de nombreuses personnes utilisent les deux termes de manière interchangeable. ^{[4] [a]} Les URL se produisent le plus souvent pour référencer des pages Web ( HTTP ), mais sont également utilisées pour le transfert de fichiers ( ftp ), le courrier électronique ( mailto ), l’accès à la base de données ( JDBC), et de nombreuses autres applications.

URL

Localisateur de ressources uniformes
Abréviation	URL
Statut	Publié
Première publication	1994 ; il y a 28 ans ( 1994 )
Dernière version	Niveau de vie 2022
Organisme	Groupe de travail sur l’ingénierie Internet (IETF)
Comité	Groupe de travail sur la technologie des applications hypertextes Web (WHATWG)
Séries	Demande de commentaires (RFC)
Éditeurs	Anne van Kesteren
Auteurs	Tim Berners-Lee
Normes de base	RFC 3986 . – Identifiant de ressource uniforme (URI) : syntaxe générique. RFC 4248 . – Le schéma d’URI telnet. RFC 4266 . – Le schéma d’URI Gopher. RFC 6068 . – Le schéma d’URI ‘mailto’. RFC 6196 . – Déplacement du serveur de messagerie : Schéma d’URI vers Historique. RFC 6270 . – Le schéma d’URI ‘tn3270’.
Normes associées	URI , URN
Domaine	Internet
Licence	CC PAR 4.0
Site Internet	URL .spec .whatwg .org

La plupart des navigateurs Web affichent l’URL d’une page Web au-dessus de la page dans une barre d’adresse . Une URL typique peut avoir la forme HTTP://www.example.com/index.html, qui indique un protocole ( HTTP), un nom d’ hôte ( www.example.com) et un nom de fichier ( index.html).

Histoire

Les localisateurs de ressources uniformes ont été définis dans la RFC 1738 en 1994 par Tim Berners-Lee , l’inventeur du World Wide Web , et le groupe de travail URI de l’ Internet Engineering Task Force (IETF), ^[7] comme résultat d’une collaboration commencée au IETF Living Documents oiseaux d’une plume session en 1992. ^{[7] [8]}

Le format combine le système préexistant de noms de domaine (créé en 1985) avec une syntaxe de chemin de fichier , où des barres obliques sont utilisées pour séparer les noms de répertoire et de fichier . Il existait déjà des conventions où les noms de serveur pouvaient être préfixés pour compléter les chemins de fichiers, précédés d’une double barre oblique ( //). ^[9]

Berners-Lee a par la suite regretté l’utilisation de points pour séparer les parties du nom de domaine dans les URI , souhaitant avoir utilisé des barres obliques partout, ^[9] et a également déclaré que, étant donné les deux-points suivant le premier composant d’un URI, les deux les barres obliques avant le nom de domaine étaient inutiles. ^[dix]

Une première ébauche (1993) de la spécification HTML ^[11] faisait référence à des localisateurs de ressources “universels”. Cela a été abandonné entre juin 1994 ( RFC 1630 ) et octobre 1994 (draft-ietf-URI-url-08.txt). ^[12]

Syntaxe

Chaque URL HTTP est conforme à la syntaxe d’un URI générique. La syntaxe générique URI consiste en une séquence hiérarchique de cinq composants : ^[13]

URI = schéma “:” [“//” autorité] chemin [“?” requête] [fragment “#”]

où la composante autorité se divise en trois sous- composantes :

autorité = [info utilisateur “@”] hôte [“:” port]

Ceci est représenté dans un diagramme de syntaxe comme suit :

URI syntax diagram” height=”100″ src=”” data-src=”//upload.wikimedia.org/wikipedia/commons/thumb/d/d6/URI_syntax_diagram.svg/1068px-URI_syntax_diagram.svg.png” width=”1068″>

L’URI comprend :

• Un non-videcomposant de schéma suivi de deux-points (:), composé d’une séquence de caractères commençant par une lettre et suivi de n’importe quelle combinaison de lettres, chiffres, plus (+), point (.) ou trait d’union (-). Bien que les schémas ne soient pas sensibles à la casse, la forme canonique est en minuscules et les documents qui spécifient des schémas doivent le faire avec des lettres minuscules. Desexemples de schémas populaires incluenthttp,https,ftp,mailto,fileetdata. ircLes schémas d’URI doivent être enregistrés auprès de l’IANA (Internet Assigned Numbers Authority), bien que des schémas non enregistrés soient utilisés dans la pratique. ^[c]
• Un facultatif élément d’ autorité précédé de deux barres obliques (//), comprenant :
  • Un facultatif sous-composant userinfo qui peut être composé d’unnom d’utilisateurpassefacultatifprécédés de deux-points (:), suivis d’un arobase (@). L’utilisation du formatusername:passworddans le sous-composant userinfo est obsolète pour des raisons de sécurité. Les applications ne doivent pas restituer en texte clair les données après le premier deux-points (:) trouvées dans un sous-composant userinfo à moins que les données après les deux-points ne soient la chaîne vide (n’indiquant aucun mot de passe).
  • UN sous-composant hôte , composé soit d’un nom enregistré (y compris, mais sans s’y limiter, unhôte) soit d’uneadresse IP. Les adresses IPv4doivent être ennotation décimale pointetIPv6doivent être entre crochets ([]). ^{[15] [e]}
  • Un facultatif sous-composant port: précédé de deux-points ( ).
• UN composant de chemin , composé d’une séquence de segments de chemin séparés par une barre oblique (/). Un chemin est toujours défini pour un URI, bien que le chemin défini puisse être vide (de longueur nulle). Un segment peut également être vide, ce qui entraîne deux barres obliques consécutives (//) dans le composant de chemin. Un composant de chemin peut ressembler ou correspondre exactement à unchemin de système de fichiers,mais n’implique pas toujours une relation avec celui-ci. Si un composant d’autorité est présent, le composant de chemin doit être vide ou commencer par une barre oblique (/). Si un composant d’autorité est absent, le chemin ne peut pas commencer par un segment vide – c’est-à-dire par deux barres obliques (//) – car les caractères suivants seraient interprétés comme un composant d’autorité. ^[17]

Par convention, dans les URI HTTP et https , la dernière partie d’un chemin est nommée pathinfo et il est facultatif. Il est composé de zéro ou plusieurs segments de chemin qui ne font pas référence à un nom de ressource physique existant (par exemple, un fichier, un programme de module interne ou un programme exécutable) mais à une partie logique (par exemple, une commande ou une partie qualificative) qui doit être passé séparément à la première partie du chemin qui identifie un module exécutable ou un programme géré par un serveur web; ceci est souvent utilisé pour sélectionner un contenu dynamique (un document, etc.) ou pour l’adapter à la demande (voir aussi : CGIet PATH_INFO, etc.). Exemple: URI : “HTTP://www.example.com/questions/3456/my-document” où : “/questions”est la première partie du chemin (un module ou un programme exécutable) et “/3456/my-document”est la deuxième partie du chemin nommé pathinfo , qui est passé au module exécutable ou au programme nommé “/questions”pour sélectionner le document demandé. Un URI HTTP ou https contenant une partie pathinfo sans partie requête peut également être appelé une « URL propre » dont la dernière partie peut être un « slug ».

Délimiteur de requête	Exemple
Esperluette ( &)	key1=value1&key2=value2
Point-virgule ( 😉 [d]	key1=value1;key2=value2

• Un facultatif composant de requête précédé d’un point d’interrogation (?), contenant unechaînede requête de données non hiérarchiques. Sa syntaxe n’est pas bien définie, mais par convention est le plus souvent une séquence depaires attribut-valeurséparées par undélimiteur.
• Un facultatif composant de fragment précédé d’undièse(#). Le fragment contient unidentifiant de fragmentfournissant une direction à une ressource secondaire, telle qu’un titre de section dans un article identifié par le reste de l’URI. Lorsque la ressource principale est unHTML, le fragment est souvent unidattributd’un élément spécifique, et les navigateurs Web font défiler cet élément dans la vue.

Un navigateur Web déréférencera généralement une URL en effectuant une requête HTTP vers l’hôte spécifié, par défaut sur le numéro de port 80. Les URL utilisant le httpsschéma nécessitent que les requêtes et les réponses soient effectuées via une connexion sécurisée au site Web .

URL internationalisée

Les internautes sont répartis dans le monde entier en utilisant une grande variété de langues et d’alphabets et s’attendent à pouvoir créer des URL dans leurs propres alphabets locaux. Un IRI (Internationalized Resource Identifier) ​​est une forme d’URL qui inclut des caractères Unicode. Tous les navigateurs modernes prennent en charge les IRI. Les parties de l’URL nécessitant un traitement spécial pour les différents alphabets sont le nom de domaine et le chemin. ^{[19] [20]}

Le nom de domaine dans l’IRI est connu sous le nom de Nom de domaine internationalisé (IDN). Les logiciels Web et Internet convertissent automatiquement le nom de domaine en punycode utilisable par le Domain Name System ; par exemple, l’URL chinoise HTTP://例子.卷筒纸devient HTTP://xn--fsqu00a.xn--3lr804guic/. Le xn--indique que le caractère n’était pas ASCII à l’origine. ^[21]

Le nom du chemin de l’URL peut également être spécifié par l’utilisateur dans le système d’écriture local. S’il n’est pas déjà encodé, il est converti en UTF-8 et tous les caractères ne faisant pas partie du jeu de caractères de base de l’URL sont échappés au format hexadécimal à l’aide du codage en pourcentage ; par exemple, l’URL japonaise HTTP://example.com/引き割り.htmldevient HTTP://example.com/%E5%BC%95%E3%81%8D%E5%89%B2%E3%82%8A.html. L’ordinateur cible décode l’adresse et affiche la page. ^[19]

URL relatives au protocole

Les liens relatifs au protocole (PRL), également appelés URL relatives au protocole (PRURL), sont des URL pour lesquelles aucun protocole n’est spécifié. Par exemple, //example.comutilisera le protocole de la page en cours, généralement HTTP ou HTTPS. ^{[22] [23]}

Voir également

• Lien hypertexte
• PURL – URL persistante
• CURIE (URI compact)
• Identifiant de fragment
• Localisateur de ressources Internet (IRL)
• Identifiant de ressource internationalisé (IRI)
• URL sémantique
• Typosquattage
• Identificateur de ressource uniforme
• Normalisation des URL
• Utilisation des barres obliques dans le réseautage

Remarques

1. ^ Une URL implique les moyens d’accéder à une ressource indiquée et est désignée par un protocole ou un mécanisme d’accès, ce qui n’est pas vrai pour chaque URI. ^{[5] [4]} Ainsihttp://www.example.comest une URL, alors qu’ellewww.example.comne l’est pas. ^[6]
2. ^ Les procédures d’enregistrement de nouveaux schémas d’URI ont été définies à l’origine en 1999 par la RFC 2717 , et sont maintenant définies par RFC 7595 , publiée en juin 2015. ^[14]
3. ^ Pour les URI relatives aux ressources sur le World Wide Web, certains navigateurs Web permettent.0de supprimer des parties de notation décimale à points ou d’utiliser des adresses IP entières brutes. ^[16]
4. ^ RFC 1866 historique (obsolète par RFC 2854 ) encourage les auteurs CGI à prendre en charge ‘;’ en plus de ‘&’. ^[18]

Citations

1. ^ W3C (2009) .
2. ^ “Avant et barres obliques inverses dans les URL” . zzz.buzz . Récupéré le 19/09/2018 .
3. ^ RFC 3986 (2005) .
4. ^ ^{un b} Groupe d’Intérêt de Planification d’URI W3C/IETF Conjoint (2002) .
5. ^ RFC 2396 (1998) .
6. ^ Miessler, Daniel. “La différence entre les URL et les URI” .
7. ^ ^{un b} W3C (1994) .
8. ^ IETF (1992) .
9. ^ ^{un b} Berners-Lee (2015) .
10. ^ Nouvelles de la BBC (2009) .
11. ^ Berners-Lee, Tim ; Connolly, Daniel “Dan” (mars 1993). Langage de balisage hypertexte (projet de RFCxxx) (rapport technique). p. 28.
12. ^ Berners-Lee, Tim ; Masinter, Larry ; McCahill, Mark Perry (octobre 1994). Localisateurs de ressources uniformes (URL) (rapport technique). (Ce projet Internet a été publié en tant que RFC standard proposé, RFC 1738 (1994) ) Cité dans Ang, CS; Martin, DC (janvier 1995). Constituent Component Interface++ (rapport technique). Bibliothèque et centre de gestion des connaissances de l’UCSF.
13. ^ RFC 3986, section 3 (2005) .
14. ^ IETF (2015) .
15. ^ RFC 3986 (2005) , §3.2.2.
16. ^ Laurent (2014) .
17. ^ RFC 2396 (1998) , §3.3.
18. ^ RFC 1866 (1995) , §8.2.1.
19. ^ ^{un b} W3C (2008) .
20. ^ W3C (2014) .
21. ^ IANA (2003) .
22. ^ Glaser, JD (2013). Développement sécurisé pour les applications mobiles : comment concevoir et coder des applications mobiles sécurisées avec PHP et JavaScript . CRC Appuyez sur . p. 193. ISBN 978-1-48220903-7. Récupéré le 12/10/2015 .
23. ^ Schäfer, Steven M. (2011). Bible HTML, XHTML et CSS . John Wiley et fils . p. 124. ISBN 978-1-11808130-3. Récupéré le 12/10/2015 .

Références

• “Berners-Lee “désolé” pour les barres obliques” . Nouvelles de la BBC . 2009-10-14 . Récupéré le 14/02/2010 .
• “Documents vivants BoF Minutes” . Consortium World Wide Web . 1992-03-18 . Récupéré le 26/12/2011 .
• Berners-Lee, Tim (1994-03-21). “Uniform Resource Locators (URL): Une syntaxe pour l’expression des informations d’accès des objets sur le réseau” . Consortium World Wide Web . Récupéré le 13/09/2015 .
• Berners-Lee, Tim ; Masinter, Larry ; McCahill, Mark Perry (décembre 1994). Localisateurs de ressources uniformes (URL) . doi : 10.17487/RFC1738 . RFC 1738 . Récupéré le 31/08/2015 .
• Berners-Lee, Tim (2015) [2000]. “Pourquoi le //, #, etc?” . Foire aux questions . Consortium World Wide Web . Récupéré le 03/02/2010 .
• Connolly, Daniel “Dan” ; Sperberg-McQueen, C. Michael , éds. (2009-05-21). “Adresses Web en HTML 5” . Consortium World Wide Web . Récupéré le 13/09/2015 .
• IANA (2003-02-14). “Achèvement de la sélection IANA du préfixe IDNA” . Liste de diffusion IETF-Announce . Archivé de l’original le 2004-12-08 . Récupéré le 03/09/2015 .
• Berners-Lee, Tim ; Connolly, Daniel “Dan” (novembre 1995). “Langage de balisage hypertexte – 2.0” . Groupe de travail sur l’ingénierie Internet . Récupéré le 13/09/2015 .
• Berners-Lee, Tim ; Fielding, Roy T. ; Masinter, Larry (août 1998). Identifiants de ressources uniformes (URI) : syntaxe générique . doi : 10.17487/RFC2396 . RFC 2396 . Récupéré le 31/08/2015 .
• Hansen, Tony; Hardie, Ted (juin 2015). Thaler, Dave (éd.). Lignes directrices et procédures d’enregistrement pour les schémas d’URI . doi : 10.17487/RFC7595 . RFC 7595 .
• Mealling, Michael ; Denenberg, Ray, éd. (Août 2002). Rapport du groupe d’intérêt conjoint W3C/IETF sur la planification des URI : identificateurs de ressources uniformes (URI), URL et noms de ressources uniformes (URN) : clarifications et recommandations . doi : 10.17487/RFC3305 . RFC 3305 . Récupéré le 13/09/2015 .
• Berners-Lee, Tim ; Fielding, Roy T. ; Masinter, Larry (janvier 2005). Identifiants de ressources uniformes (URI) : syntaxe générique . doi : 10.17487/RFC3986 . RFC 3986 . Récupéré le 31/08/2015 .
• Berners-Lee, Tim ; Fielding, Roy T. ; Masinter, Larry (janvier 2005). Uniform Resource Identifiers (URI): Generic Syntax, section 3, Composants de la syntaxe . doi : 10.17487/RFC3986 . RFC 3986 . Récupéré le 31/08/2015 .
• “Une introduction aux adresses Web multilingues” . 2008-05-09 . Récupéré le 11/01/2015 .
• Philip, A. (2014). “Que se passe-t-il avec les “URL internationales” ?” . World Wide Web Consortium . Récupéré le 11/01/2015 .
• Laurent, Éric (2014-03-06). “Browser Arcana: IP Literals in URLs” . docs.microsoft.com . Archivé de l’original le 2020-06-22 . Récupéré le 22/06/2020 .

Liens externes

• Spécification d’URL au WHATWG