Décoder une URL

L'ambiguïté que rien ne peut lever à votre place

Le décodage est mécaniquement simple — repérer chaque % suivi de deux chiffres hexadécimaux, le retransformer en octet, puis lire les octets en UTF-8 — et il ne comporte qu'une seule véritable ambiguïté. Un signe plus peut signifier une espace, ou bien un plus. Dans un formulaire envoyé, il signifie une espace, selon une convention plus ancienne que la spécification des URL elle-même. Dans un segment de chemin, c'est un caractère littéral. Rien dans le texte n'indique quel cas s'applique : la page vous montre donc les deux lectures plutôt que d'en choisir une et de se tromper sans rien dire — ce qui compte surtout là où l'erreur fait le plus mal, une adresse e-mail ou une valeur base64 où le plus fait réellement partie des données.

Le texte non ASCII arrive sous forme de plusieurs séquences pourcent par caractère, car l'encodage porte sur les octets UTF-8 et non sur les caractères : une lettre accentuée en donne deux, la plupart des symboles trois, un emoji quatre. Décodez une séquence qui n'est pas de l'UTF-8 valide et vous obtenez des caractères de remplacement — signe, en général, que le texte a été encodé depuis un autre jeu de caractères, ou qu'il a été coupé au milieu d'un caractère.

Décoder deux fois est une faille de sécurité, pas une simple erreur. Si une valeur est décodée, contrôlée, puis décodée à nouveau, un attaquant peut cacher des caractères au contrôle : %252e%252e%252f passe un filtre qui cherche « ../ », car après un premier passage il reste %2e%2e%2f, et après le second il devient justement la remontée de répertoire que le filtre devait bloquer. Décodez exactement une fois, puis validez, et jamais dans l'autre ordre.

Un texte qui n'a jamais été encodé revient tel quel, sans être abîmé — le comportement utile quand vous ne savez pas si une chaîne a besoin d'être décodée. Un signe pourcent qui n'est pas suivi de deux chiffres hexadécimaux est laissé en place au lieu d'être traité comme une erreur : c'est un pourcent littéral, fréquent dans un texte collé plutôt qu'encodé.

Si vous cherchez autre chose

Dans le code, le décodeur doit correspondre à l'encodeur. JavaScript propose decodeURIComponent ; Python sépare unquote et unquote_plus précisément à cause de la question du signe plus ; PHP a rawurldecode et urldecode pour la même raison. Mieux encore, laissez un type URL ou un analyseur de chaîne de requête s'en charger — la plupart des frameworks décodent les paramètres pour vous, et décoder à nouveau ensuite, c'est exactement ainsi que s'écrit le bug du double décodage décrit plus haut.

Pour examiner une longue URL plutôt que décoder une valeur, un analyseur vaut mieux qu'un décodeur : python -c "import urllib.parse,sys; print(urllib.parse.urlparse(sys.argv[1]))" découpe une adresse en ses différentes parties pour que vous voyiez quel morceau est lequel avant de décoder quoi que ce soit — c'est généralement la vraie question quand un lien se comporte mal.