Skip to main content

Encodage URL

Français

Encodez ou décodez des chaînes d'URL.

→ Encodage d'entités HTML→ Base64
Tous les calculs sont effectués localement dans votre navigateur. Aucune donnée n'est envoyée au serveur.

Les résultats sont fournis à titre informatif. Vérifiez-les auprès d'autres sources.

Une phrase polonaise de 17 caractères en devient 66 dans une URL

L'encodage pour cent travaille sur des octets, pas sur des caractères, et l'UTF-8 dépense plus d'un octet pour tout ce qui sort de l'ASCII. Chaque octet devient trois caractères, si bien qu'un texte accentué gonfle violemment : zażółć gęślą jaźń fait 17 caractères, 26 octets et 66 caractères une fois encodé — un facteur de 3,88.

Comment ça marche

  • Encode le texte en pour cent pour un usage sûr dans les URL, et le décode.
  • Encode d'abord en UTF-8, d'où provient l'expansion de taille.
  • Distingue l'encodage d'une URL entière de celui d'un composant : deux tâches distinctes aux jeux de caractères sûrs différents.
chaque octet non sûr → % suivi de deux chiffres hexadécimaux

nombre d'octets en UTF-8 :
  ASCII        1 octet  → 1 caractère non encodé
  ł, ü         2 octets → 6 caractères   (%C5%82)
  €, 日        3 octets → 9 caractères   (%E2%82%AC)
  emoji        4 octets → 12 caractères  (%F0%9F%98%80)

71 des 95 caractères ASCII imprimables passent intacts

Exemple chiffré

Les mêmes caractères encodés, puis la panne classique du double encodage.

  1. a → a (1 caractère, inchangé)
  2. ł → %C5%82 (6 caractères)
  3. 😀 → %F0%9F%98%80 (12 caractères)
  4. "a b" → "a%20b"
  5. réencodé → "a%2520b"

Le second encodage transforme le % de %20 en %25 et produit %2520. Décoder une fois redonne a%20b et non a b : la chaîne a l'air décodée tout en restant fausse, ce qui explique la longévité des bugs de double encodage avant qu'on les remarque.

Lire le résultat

  • L'espace vaut %20 dans un chemin et + dans des données de requête encodées en formulaire, et les deux ne sont pas interchangeables. Décoder un + comme un plus littéral là où un espace était voulu, ou l'inverse, est le deuxième bug d'encodage le plus courant après le double encodage.
  • Encodez des composants, pas des URL entières. Passer une URL complète dans l'encodage de composant détruit le :// et les séparateurs ; passer un composant dans l'encodage d'URL complète laisse & et = intacts, ce qui permet à une saisie utilisateur d'injecter des paramètres supplémentaires.
  • L'expansion s'accompagne de limites pratiques. Serveurs et proxys plafonnent souvent les URL vers 2 000 caractères : une chaîne de requête portant du texte accentué atteint ce plafond bien plus tôt que le nombre de caractères ne le laisse croire.
  • L'encodage n'est pas l'échappement pour d'autres contextes. Une chaîne encodée pour cent est sûre dans une URL et ne dit rien de sa sûreté en HTML, en SQL ou dans un shell : chaque destination exige son propre encodage, appliqué au point d'usage.

Questions fréquentes

Pourquoi mon texte est-il devenu %2520 ?
Il a été encodé deux fois. Le premier passage a changé un espace en %20 ; le second a vu le % comme un caractère ordinaire et l'a encodé en %25, donnant %2520. Décodez deux fois pour retrouver l'original, puis corrigez la couche qui encode en double.
Un espace doit-il être %20 ou + ?
%20 partout sauf dans les chaînes de requête encodées en formulaire, où + est la convention historique et reste largement produite. Dans ce contexte les deux se décodent en espace, mais seul %20 est correct dans un segment de chemin.

Sources