Encodage en pourcentage

L’encodage en pourcentage (aussi appelé encodage URL) est le mécanisme utilisé par les URL pour représenter les caractères qui ne sont pas légaux dans la grammaire URL, ou qui ont des significations réservées. Défini dans RFC 3986 §2.

Le schéma : chaque octet à échapper est écrit comme % suivi de deux chiffres hexadécimaux représentant la valeur de l’octet. L’espace devient %20. Le point d’interrogation devient %3F. La barre oblique avant devient %2F. Le signe dièse devient %23.

Pour les caractères non-ASCII (trémas, accents, CJK, emoji), le caractère est d’abord encodé en UTF-8 en une séquence d’octets, puis chaque octet est encodé en pourcentage. Le caractère unique « é » (U+00E9) devient les octets 0xC3 0xA9 en UTF-8, encodé en pourcentage comme %C3%A9.

Trois classes de caractères à connaître :

• Non réservés — A-Z, a-z, 0-9, et -_.~. Jamais échappés.
• Réservés — caractères avec une signification syntaxique (:/?#[]@!$'()*+,;=). Échappés quand ils apparaissent dans des données qui ne devraient pas être analysées comme syntaxe URL.
• Autres — tout le reste (espaces, non-ASCII, caractères de contrôle). Toujours échappés.

Encodez ou décodez n’importe quelle chaîne dans notre encodeur URL, qui gère correctement UTF-8.

La note sur l’espace comme plus : dans le chemin et le fragment d’une URL, un espace s’encode comme %20. Mais dans la chaîne de requête d’un corps application/x-www-form-urlencoded, les espaces s’encodent comme + — une convention spécifique aux formulaires antérieure à la spécification URL moderne. La fonction JavaScript encodeURIComponent() émet toujours %20. Le conseil moderne : utilisez les API URL standard (WHATWG URLSearchParams dans les navigateurs, url.URL dans Node) et laissez l’implémentation choisir le bon encodage pour le contexte.

Le double encodage — le bug de production le plus courant : si une valeur passe par deux encodeurs sans décodeur intermédiaire, le % d’origine du premier passage devient %25, et l’utilisateur voit des charabia comme %2520 au lieu de %20. La cause profonde est presque toujours qu’une couche du système suppose que son entrée est du texte brut alors qu’elle est déjà encodée en URL. Voir aussi : UTF-8, ASCII. Référence : RFC 3986 §2.1 — Encodage en pourcentage.

Exemple concret

Encodez la requête de recherche café & thé dans une chaîne de requête URL. Étape un — UTF-8 chaque caractère : c a f é <espace> & <espace> t h é devient les octets 63 61 66 C3 A9 20 26 20 74 68 C3 A9. Étape deux — appliquer les règles d’encodage en pourcentage : les caractères non réservés (c a f t h) restent ; les séquences UTF-8 multi-octets et les caractères réservés (&) sont échappés. Résultat : caf%C3%A9%20%26%20th%C3%A9. URL complète : https://example.com/search?q=caf%C3%A9%20%26%20th%C3%A9. Du côté récepteur, le serveur décode en inversant les deux étapes.

Pourquoi et quand cela importe

Chaque URL construite par concaténation de chaînes est un bug potentiel d’injection ou de routage. Un nom de fichier fourni par l’utilisateur comme ../../../etc/passwd intégré brut dans une URL devient une tentative de traversée de chemin. Les frameworks HTTP modernes (Express, FastAPI, ASP.NET) gèrent cela automatiquement via leurs constructeurs de paramètres de requête ; les bugs se concentrent dans les URL de redirection construites manuellement. Référence : WHATWG URL Standard — Octets encodés en pourcentage.