La plupart des réponses existantes ici ne sont pas pratiques car elles ignorent totalement l'utilisation dans le monde réel d'adresses comme:
Tout d'abord, une digression dans la terminologie. Quelles sont ces adresses? S'agit-il d'URL valides?
Historiquement, la réponse était "non". Selon la RFC 3986 , à partir de 2005, ces adresses ne sont pas des URI (et donc pas des URL, car les URL sont un type d'URI ). Selon la terminologie des normes IETF 2005, nous devrions les appeler correctement IRI (Internationalized Resource Identifiers), tels que définis dans la RFC 3987 , qui ne sont techniquement pas des URI mais qui peuvent être convertis en URI simplement en encodant en pourcentage tous les caractères non ASCII dans l'IRI .
Selon les spécifications modernes, la réponse est "oui". Le WHATWG Living Standard classe simplement tout ce qui serait auparavant appelé "URI" ou "IRI" comme "URL". Cela aligne la terminologie spécifiée sur la façon dont les personnes normales qui n'ont pas lu la spécification utilisent le mot "URL", qui était l'un des objectifs de la spécification .
Quels caractères sont autorisés en vertu du niveau de vie WHATWG?
Selon cette nouvelle signification de "URL", quels caractères sont autorisés? Dans de nombreuses parties de l'URL, telles que la chaîne de requête et le chemin, nous sommes autorisés à utiliser des "unités d'URL" arbitraires , qui sont
Points de code URL et octets codés en pourcentage .
Que sont les «points de code URL»?
Les points de code URL sont alphanumériques ASCII, U + 0021 (!), U + 0024 ($), U + 0026 (&), U + 0027 ('), U + 0028 PARENTHÈSE GAUCHE, U + 0029 PARENTHÈSE DROITE, U + 002A (*), U + 002B (+), U + 002C (,), U + 002D (-), U + 002E (.), U + 002F (/), U + 003A (:), U + 003B (;), U + 003D (=), U + 003F (?), U + 0040 (@), U + 005F (_), U + 007E (~) et points de code dans la plage U + 00A0 à U + 10FFFD, inclus, à l'exclusion des substituts et des non-caractères.
(Notez que la liste des "points de code URL" ne comprend pas %, mais que les %s sont autorisés dans les "unités de code URL" s'ils font partie d'une séquence de codage en pourcentage.)
Le seul endroit où je peux repérer où la spécification autorise l'utilisation de tout caractère qui n'est pas dans cet ensemble est dans l' hôte , où les adresses IPv6 sont incluses entre les caractères [et ]. Partout ailleurs dans l'URL, les unités d'URL sont autorisées ou un ensemble de caractères encore plus restrictif.
Quels caractères étaient autorisés dans les anciens RFC?
Par souci d'histoire, et comme cela n'est pas exploré complètement ailleurs dans les réponses ici, examinons ce qui était autorisé sous l'ancienne paire de spécifications.
Tout d'abord, nous avons deux types de caractères réservés RFC 3986 :
:/?#[]@, qui font partie de la syntaxe générique d'un URI défini dans la RFC 3986!$&'()*+,;=, qui ne font pas partie de la syntaxe générique de la RFC, mais sont réservés à une utilisation en tant que composants syntaxiques de schémas URI particuliers. Par exemple, des points - virgules et les virgules sont utilisés dans le cadre de la syntaxe des URIs de données , et &et =sont utilisés dans le cadre de l'omniprésent ?foo=bar&qux=bazformat dans les chaînes de requête (qui ne sont pas spécifié par la RFC 3986).
N'importe lequel des caractères réservés ci-dessus peut être légalement utilisé dans un URI sans codage, soit pour servir leur objectif syntaxique, soit comme caractères littéraux dans les données à certains endroits où une telle utilisation ne peut pas être mal interprétée comme le caractère servant son objectif syntaxique. (Par exemple, bien qu'il /ait une signification syntaxique dans une URL, vous pouvez l'utiliser non codé dans une chaîne de requête, car il n'a pas de signification dans une chaîne de requête.)
La RFC 3986 spécifie également certains caractères non réservés , qui peuvent toujours être utilisés simplement pour représenter des données sans aucun encodage:
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._~
Enfin, le %caractère lui-même est autorisé pour les encodages en pourcentage.
Cela ne laisse que les caractères ASCII suivants qui sont interdits d'apparaître dans une URL:
- Les caractères de contrôle (caractères 0-1F et 7F), y compris la nouvelle ligne, la tabulation et le retour chariot.
"<>\^`{|}
Tout autre caractère ASCII peut légalement figurer dans une URL.
La RFC 3987 étend ensuite cet ensemble de caractères non réservés avec les plages de caractères unicode suivantes:
%xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
/ %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
/ %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
/ %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
/ %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
/ %xD0000-DFFFD / %xE1000-EFFFD
Ces choix de bloc de l'ancienne spécification semblent bizarres et arbitraires étant donné les dernières définitions de bloc Unicode ; cela est probablement dû au fait que les blocs ont été ajoutés au cours de la décennie écoulée depuis la rédaction de la RFC 3987.
Enfin, il convient peut-être de noter que le simple fait de savoir quels caractères peuvent légalement apparaître dans une URL n'est pas suffisant pour reconnaître si une chaîne donnée est une URL légale ou non, car certains caractères ne sont légaux que dans des parties particulières de l'URL. Par exemple, les caractères réservés [et ]sont autorisés dans le cadre d'un hôte littéral IPv6 dans une URL telle que http: // [1080 :: 8: 800: 200C: 417A] / foo mais ne sont pas autorisés dans un autre contexte, de sorte que le L'exemple d'OP http://example.com/file[/].htmlest illégal.