Quels caractères rendent une URL invalide?

en URI général tel que défini par RFC 3986 (voir Section 2: caractères ) peut contenir l'un des caractères suivants:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]@!$&'()*+,;=

notez que cette liste n'indique pas où ces caractères peuvent apparaître dans L'URI.

tout autre caractère doit être encodé avec le pourcentage d'encodage ( % hh ). Chaque partie de L'URI a d'autres restrictions sur les caractères qui doivent être représentés par un mot encodé en pourcentage.

pour apporter quelques précisions et répondre directement à la question ci-dessus, il existe plusieurs classes de caractères qui causent des problèmes pour les URLs et URIs.

il y a des caractères qui sont rejetés et qui ne doivent jamais apparaître dans une URL/URI, des caractères réservés (décrits ci-dessous), et d'autres caractères qui peuvent causer des problèmes dans certains cas, mais qui sont marqués comme" imprudent "ou"dangereux". Les raisons pour lesquelles les caractères sont restreints sont clairement énoncées dans RFC-1738 (URLs) et RFC-2396 (URIs). Remarque le plus récent la RFC 3986 (mise à jour de la RFC 1738) définit la construction de ce que les caractères sont autorisés dans un contexte donné, mais les aînés spec offre un moyen plus simple et plus description générale dont les caractères ne sont pas autorisés avec les règles suivantes.

Exclus US-ASCII des Caractères interdits dans la syntaxe d'URI:

   control     = <US-ASCII coded characters 00-1F and 7F hexadecimal>
   space       = <US-ASCII coded character 20 hexadecimal>
   delims      = "<" | ">" | "#" | "%" | <">

Liste des imprudent caractères sont autorisés, mais peut causer des problèmes:

   unwise      = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"

caractères réservés dans un composant de requête et / ou ayant une signification particulière dans un URI / URL:

  reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","

la classe de syntaxe "réservée" ci-dessus fait référence aux caractères qui sont autorisés dans une URI, mais qui ne peuvent pas l'être dans un composant particulier de la syntaxe URI Générique. les caractères de l'ensemble" réservé " ne sont pas Tous réservés. contextes de . Le nom d'hôte, par exemple, peut contenir un nom d'utilisateur optionnel de sorte qu'il pourrait être quelque chose comme ftp://user@hostname/ où le caractère " @ " a une signification particulière.

voici un exemple d'URL qui a des caractères invalides et imprécis (par ex. '$', '[', ']') et doit être correctement codé:

http://mw1.google.com/mw-earth-vectordb/kml-samples/gp/seattle/gigapxl/$[level]/r$[y]_c$[x].jpg

certaines des restrictions de caractères pour URIs/URLs dépendent du langage de programmation. Par exemple, le caractère ' | ' (0x7C) bien que seulement marqué comme "unwise" dans L'URI spec lancera un URISyntaxException dans le Java java.net.URI constructeur donc une URL comme http://api.google.com/q?exp=a|b n'est pas autorisée et doit être encodée à la place de http://api.google.com/q?exp=a%7Cb si vous utilisez Java avec une instance D'objet URI.

la plupart des réponses existantes ici sont impraticables parce qu'ils ignorent totalement l'usage réel des adresses comme:

• https://en.wikipedia.org/wiki/Möbius_strip ou
• https://zh.wikipedia.org/wiki/Wikipedia:关于中文维基百科/en .

Ok, donc selon RFC 3986 , ces adresses ne sont pas URIs (et par conséquent pas D'URLs, puisque les URLs sont un type D'URIs ). Si nous nous considérons redevables à la terminologie des normes existantes de L'IETF, alors nous devrions les appeler correctement IRIs (identificateurs de ressources internationalisés), tel que défini dans RFC 3987 , qui ne sont pas techniquement URIs mais peuvent être convertis en URIs simplement par le pourcentage-encodant tous les caractères non-ASCII dans L'IRI. Les gens normaux, cependant, n'ont jamais entendu parler D'IRIs et appellent simplement ces URIs ou URLs (et en effet il y a un WHATWG effort en cours pour créer une nouvelle, plus large spécification D'URL qui classe simplement tous les "URIs" et "IRIs" comme "URLs" pour aligner avec l'usage moderne de ces termes dans le monde réel).

supposons que nous voulons adopter immédiatement cette signification D'URL (ce qui met en contradiction avec les spécifications IETF, mais nous aligne avec l'usage quotidien). Dans ce cas, quels caractères sont valides dans une URL?

tout d'Abord, nous avons deux types de RFC 3986 caractères réservés :

• :/?#[]@ , 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 pour une utilisation comme composants syntaxiques de schémas URI particuliers. Par exemple, les points-virgules et les virgules sont utilisées dans le cadre de la syntaxe de URIs de données , et & et = sont utilisées dans le cadre du format ubiquitaire ?foo=bar&qux=baz dans les chaînes de requête (qui n'est pas spécifié par RFC 3986).

N'importe lequel des caractères réservés ci-dessus peut être utilisé légalement dans un URI sans encodage, soit pour servir leur but syntaxique ou tout simplement comme des caractères littéraux dans les données dans certains endroits où une telle utilisation ne pourrait pas être mal interprété comme le personnage servant son but syntaxique. (Par exemple, bien que / ait une signification syntaxique dans une URL, vous pouvez l'utiliser dans une chaîne de requête, parce que n'a pas de signification dans une chaîne de requête.)

  %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