Encodeur / Décodeur d’URL & analyseur de chaîne de requête

encodeURIComponent() échappe presque tout : c’est donc ce que vous appliquez à un seul morceau d’URL — une valeur de requête, un segment de chemin. encodeURI() laisse tranquilles les caractères réservés : / ? # & = + et même #, c’est donc ce que vous appliquez à une URL déjà assemblée qu’il faut seulement débarrasser de ses espaces et de ses caractères non ASCII. Donnez une URL entière à encodeURIComponent et elle devient un bloc opaque (https%3A%2F%2F…) ; donnez une seule valeur à encodeURI et un & qu’elle contient devient silencieusement un séparateur de paramètres. Le mode Encode d’ici expose les deux : la règle de composant est celle par défaut, et la case « Whole URL » est encodeURI() octet pour octet.

Les deux sont corrects, à des endroits différents. RFC 3986 ne connaît que %20. La convention du + vient de la soumission des formulaires HTML (application/x-www-form-urlencoded) et s’applique aux corps de formulaire et, par vieille habitude, aux chaînes de requête — c’est pourquoi URLSearchParams décode + en espace mais le laisse intact dans un chemin. Autrement dit : %20 est toujours sûr, alors que + n’est une espace que si celui qui a produit la valeur l’a voulu ainsi. Le mode Decode vous montre quelle convention a été appliquée et vous laisse l’inverser, pour distinguer « Ada+Lovelace » le nom de « Ada Lovelace » les deux mots.

L’encodage pourcent remplace un octet par un % suivi de cet octet écrit en deux chiffres hexadécimaux. Une URL ne peut transporter qu’un petit ensemble de caractères ASCII : tout le reste — une espace, un accent, un emoji, ou un caractère réservé utilisé comme donnée — est d’abord converti en octets UTF-8, puis chaque octet est écrit %XX. é fait deux octets, il devient donc %C3%A9. Décoder fait l’inverse : rassembler les octets, puis les relire en UTF-8.

Décodez-la deux fois. %2520 signifie que le % de %20 a lui-même été encodé en %25, ce qui arrive quand un client appelle encodeURIComponent() sur une valeur déjà encodée : le bug classique du redirect_uri OAuth. Cet outil le détecte : collez la valeur en mode Decode et il signale que la première passe contient encore des échappements, montre ce que produit une seconde passe et propose un bouton « Decode again ». Le vrai correctif est en amont : encoder exactement une fois, au moment où la valeur est placée dans l’URL.

Parce que les octets échappés ne sont pas de l’UTF-8 valide. %C3%A9 est une séquence de deux octets bien formée et décode en é, mais %E9 seul est l’octet Latin-1 (ISO-8859-1) de é et n’est pas de l’UTF-8 légal : il décode donc en U+FFFD, le caractère de remplacement. Cet outil nomme les octets fautifs au lieu de lever l’URIError que lèverait decodeURIComponent(), ce qui vous dit que la valeur a été encodée depuis le mauvais encodage source plutôt que de vous laisser deviner.

Rien dans le standard des URL ne dit laquelle gagne : chaque ligne est donc listée ici et les suivantes sont marquées comme doublons. En pratique PHP et Express gardent la dernière valeur, r.URL.Query() de Go renvoie toutes les valeurs, ASP.NET les joint par des virgules, et Rails ne les regroupe que si la clé finit par []. Ce désaccord est précisément la raison pour laquelle un outil doit vous montrer toutes les valeurs au lieu d’en choisir une en silence.

Le punycode est l’encodage ASCII d’un nom de domaine internationalisé. Le DNS ne transporte que des étiquettes ASCII : münchen.example est donc converti en xn--mnchen-3ya.example avant toute résolution — et cette forme ASCII est aussi celle qu’un certificat TLS doit correspondre. Le parseur affiche ici l’hôte converti avec, juste en dessous, le nom que vous avez saisi, afin que vous repériez un domaine sosie. Il ne reconvertit délibérément pas le punycode en Unicode : afficher en joli Unicode un nom fourni par un attaquant, c’est exactement le mécanisme du hameçonnage homographe.

L’ensemble non réservé de RFC 3986 §2.3 : A–Z, a–z, 0–9 et les quatre marques - . _ ~. Ils sont sûrs partout et ne doivent jamais être encodés gratuitement, car %2D et - sont la même URL et les réencoder casse les schémas de signature qui hachent la chaîne brute. À noter : encodeURIComponent() laisse aussi tranquilles ! ' ( ) *, un héritage de l’ancien ensemble « mark » de RFC 2396. RFC 3986 range ces cinq caractères parmi les sous-délimiteurs : le mode composant d’ici les échappe donc, et vous prévient quand il s’écarte de la fonction native du navigateur.

Plus aujourd’hui. HTML a un temps suggéré que les serveurs acceptent ; à côté de & comme séparateur de paramètres, et ce conseil a été retiré de la spécification en 2014. Les navigateurs et URLSearchParams ne l’ont jamais traité comme un séparateur : a=1;b=2 est donc un unique paramètre nommé a dont la valeur est le littéral 1;b=2. Cet outil reproduit ce comportement et vous prévient quand il voit un point-virgule, car un backend historique peut encore découper dessus et contredire le navigateur qui se trouve devant lui.

Oui : l’outil entier est une page statique sans serveur derrière. L’analyse, l’encodage et le décodage s’exécutent dans votre onglet, rien n’est envoyé, il n’y a aucun journal et aucun compte. Cela compte ici plus que pour la plupart des outils, car les chaînes de requête sont précisément là où finissent les jetons d’accès, les URL signées, les identifiants de session et les adresses e-mail. Si vous voulez un second avis, ouvrez le panneau réseau des outils de développement pendant que vous tapez : il n’y a aucune requête à voir.