Les crochets sont-ils autorisés dans les URL ?

Question

Les crochets dans les URL sont-ils autorisés ?

J'ai remarqué ça Apache commonsHttpClient (3.0.1) lève une IOException, wget et Firefox acceptent cependant les crochets.

Exemple d'URL :

http://example.com/path/to/file[3].html

Mon client HTTP rencontre de telles URL, mais je ne sais pas s'il faut corriger le code ou lever une exception (comme cela devrait être le cas).

Answer 1

RFC3986 États

Un hôte identifié par une adresse littérale du protocole Internet, la version 6 [RFC3513] ou ultérieure, se distingue par la clôture du littéral IP entre crochets ([" et "]).C'est le seul endroit où les caractères du support carré sont autorisés dans la syntaxe URI.

En théorie, vous ne devriez donc pas voir de tels URI dans la nature, car ils devraient arriver codés.

Answer 2

Je sais que cette question est un peu ancienne, mais je voulais juste noter que PHP utilise des crochets pour transmettre des tableaux dans une URL.

http://www.example.com/foo.php?bar[]=1&bar[]=2&bar[]=3

Dans ce cas $_GET['bar'] contiendra array(1, 2, 3).

Answer 3

Tout navigateur ou logiciel Web qui accepte les URL et ne lève pas d'exception lorsque des caractères spéciaux sont introduits est presque assuré d'encoder les caractères spéciaux en coulisses.Les accolades, les crochets, les espaces, etc. ont tous des manières codées spéciales de les représenter afin de ne pas produire de conflits.Conformément aux réponses précédentes, le moyen le plus sûr de résoudre ces problèmes est de les encoder en URL avant de les transmettre à quelque chose qui tentera de résoudre l'URL.

Answer 4

Les seuls caractères non autorisés dans les noms de chemin sont # et ?car ils signifient la fin du chemin.

L'uri RFC aura la réponse définitive :

http://www.ietf.org/rfc/rfc1738.txt

Peu sûr:

Les personnages peuvent être dangereux pour plusieurs raisons.Le caractère de l'espace est dangereux car des espaces importants peuvent disparaître et des espaces insignifiants peuvent être introduits lorsque les URL sont transcrites ou composées ou soumises au traitement des programmes de traitement des mots.Les personnages "<" et ">" sont dangereux car ils sont utilisés comme délimiteurs autour d'URL dans le texte libre;La marque de devis ("" ") est utilisée pour délimiter les URL dans certains systèmes.Le personnage "#" est dangereux et doit toujours être codé car il est utilisé dans le World Wide Web et dans d'autres systèmes pour délimiter une URL d'un identifiant de fragment / ancre qui pourrait le suivre.Le caractère "%" est dangereux car il est utilisé pour les encodages d'autres caractères.D'autres caractères sont dangereux car les passerelles et autres agents de transport sont connus pour modifier parfois ces caractères.Ces caractères sont "{", "}", "|", "", "^", "~", [", "], et "` ".

Tous les caractères dangereux doivent toujours être codés dans une URL.Par exemple, le personnage "#" doit être codé dans les URL même dans des systèmes qui ne traitent normalement pas des identificateurs de fragment ou d'ancrage, de sorte que si l'URL est copiée dans un autre système qui les utilise, il ne sera pas nécessaire de modifier le Encodage d'URL.

La réponse est qu'ils devrait être codés en hexadécimal, mais connaissant la loi de Postel, la plupart des choses les accepteront textuellement.

Answer 5

Pour utiliser la classe commune HttpClient, vous souhaitez examiner la classe org.apache.commons.httpclient.util.URIUtil, en particulier la méthode encode().Utilisez-le pour encoder l'URL par URI avant d'essayer de la récupérer.

Answer 6

StackOverflow ne semble pas les coder :

https://stackoverflow.com/search?q=square+brackets+[url]

Answer 7

Il est préférable de les coder en URL, car ils ne sont clairement pas pris en charge par tous les serveurs Web.Parfois, même lorsqu’il existe une norme, tout le monde ne la respecte pas.

Answer 8

Selon le Spécification de l'URL, les crochets ne sont pas des caractères d'URL valides.

Voici les extraits pertinents :

Les personnages "nationaux" et "ponctuation" n'apparaissent dans aucune production et peuvent donc n'apparaître dans les URL.
National {| } | Vline | [| | ] | | ^ | ~
ponctuation <| >

Answer 9

Crochets [ et ] dans les URL ne sont pas souvent pris en charge.

Remplacez-les par %5B et %5D:

• En utilisant une ligne de commande, l'exemple suivant est basé sur bash et sed:

  url='http://example.com?day=[0-3][0-9]'
  encoded_url="$( sed 's/\[/%5B/g;s/]/%5D/g' <<< "$url")"
  

• Utiliser Java URLEncoder.encode(String s, String enc)

• Utiliser PHP rawurlencode() ou urlencode()

  <?php
  echo '<a href="http://example.com/day/',
      rawurlencode('[0-3][0-9]'), '">';
  ?>
  

  sortir:

  <a href="http://example.com/day/%5B0-3%5D%5B0-9%5D">
  

  ou:

  <?php
  $query_string = 'day=' . urlencode('[0-3][0-9]') .
                  '&month=' . urlencode('[0-1][0-9]');
  echo '<a href="http://example.com?',
        htmlentities($query_string), '">';
  ?>
  

• Utiliser votre langage de programmation préféré...Veuillez étendre cette réponse en publiant un commentaire ou en modifiant directement cette réponse pour ajouter la fonction que vous utilisez depuis votre langage de programmation ;-)

Pour plus de détails, consultez le RFC3986 spécifiant la syntaxe de l'URL.Le Annexe A est à propos %-encoding dans la chaîne de requête (les crochets appartiennent à "gen-delims" être %-encoded).

Answer 10

Les crochets sont considérés comme dangereux, mais la majorité des navigateurs les analyseront correctement.Cela dit, il est préférable de remplacer les crochets par d'autres caractères.