Encoder et décoder une URL
Encodeur et décodeur d’URL encode en pourcentage et décode du texte dans votre navigateur. Le mode compte plus qu’il n’y paraît : dans une chaîne de requête, un espace est +, dans un chemin c’est %20, et décoder un corps de formulaire avec le mauvais transforme « a + b » en « a b » sans aucune erreur.
Comment fonctionne Encoder et décoder une URL ?
« Encodage d’URL » désigne trois encodages différents, et choisir le mauvais produit un bug qui ne lève jamais d’erreur.
L’encodage en pourcentage n’est pas l’encodage de formulaire
L’encodage en pourcentage de RFC 3986 écrit un espace %20. Le format application/x-www-form-urlencoded — ce qu’utilisent réellement une chaîne de requête et un corps de POST de formulaire — l’écrit +, ce qui signifie qu’un plus littéral doit s’écrire %2B. Décodez un corps de formulaire avec decodeURIComponent et le + reste intact, donc la recherche « a + b » arrive comme « a + b » quand l’utilisateur a tapé un plus, et comme « a+b » quand il a tapé des espaces. L’une des deux est fausse, et aucune ne lève d’erreur.
encodeURIComponent laisse cinq caractères que le RFC réserve
!, ', (, ) et * sont réservés par RFC 3986 et laissés tels quels par encodeURIComponent. C'est inoffensif en général ; ça ne l'est plus quand une signature est calculée sur la forme encodée — c'est pourquoi chaque bibliothèque AWS SigV4 et OAuth 1.0a embarque son propre encodeur. L'option stricte les encode.
Chaque composant d’URL a ses propres règles
Un chemin peut contenir / ; une valeur de requête ne peut pas contenir de & non encodé, sans quoi elle se scinde en deux paramètres. C’est la différence entre le mode composant et le mode URL complète : le premier encode tout ce qui n’est pas non-réservé, le second préserve les caractères qui donnent sa structure à une URL. Encoder une URL entière avec encodeURIComponent produit une chaîne qui n’est plus une URL.
Le double encodage, et comment le repérer
%2520 est un espace passé deux fois dans un encodeur : le % de %20 a lui-même été encodé %25. À la lecture rapide d’un log, on voit « %20 », et la valeur décodée contient un %20 littéral. L’outil compte combien de passes de décodage l’entrée survit, si bien qu’une couche en trop est visible plutôt que mystérieuse.
Décomposer une URL passe par le parseur de la plateforme
La ventilation des composants vient de l’implémentation URL du navigateur elle-même plutôt que d’une expression régulière, car l’analyse d’URL compte assez de cas limites — userinfo, littéraux IPv6, ports par défaut, hôtes encodés en pourcentage — pour que l’algorithme WHATWG déjà présent dans la plateforme soit à la fois plus court et plus correct que n’importe quel motif. Les clés de requête dupliquées sont conservées dans l’ordre, car nombre d’API leur donnent un sens.
Entrée
q=a + b
Encodé
component: q%3Da%20%2B%20b form: q%3Da+%2B+b
Quelles options et quels cas limites Encoder et décoder une URL prend en charge ?
| Paramètre | Type | Valeur par défaut | Comportement et cas limites |
|---|---|---|---|
| Composant | encodeURIComponent | par défaut | Pour une seule valeur de requête ou un segment de chemin. Encode tout sauf A–Z a–z 0–9 - _ . ~ et les cinq caractères ci-dessous. |
| URL complète | encodeURI | — | Pour une URL entière. Conserve : / ? # [ ] @ ! $ & ' ( ) * + , ; = pour que l’URL reste une URL. Utiliser le mode composant ici détruit la structure. |
| Formulaire | x-www-form-urlencoded | — | Pour une chaîne de requête ou un corps POST. Un espace devient +, un + littéral devient %2B. Décoder correctement impose d’annuler le + avant le décodage pourcentage, sinon un plus littéral devient un espace. |
| base64url | RFC 4648 §5 | — | L’alphabet base64 compatible URL : - et _ plutôt que + et /, padding retiré. C’est ce qu’utilisent les segments JWT. |
| RFC 3986 strict | booléen | désactivé | Encode aussi ! ' ( ) *, que encodeURIComponent laisse tranquilles. Indispensable quand la forme encodée alimente une signature. |
| Tout encoder | booléen | désactivé | Encode en pourcentage chaque octet, y compris les non réservés. Moche, valide, et parfois la seule chose qu’accepte une passerelle pointilleuse. |
| Jeu de caractères | UTF-8 | toujours | Ce qui n’est pas ASCII est encodé comme ses octets UTF-8, un %XX chacun — c’est ce qu’attendent tous les navigateurs et serveurs actuels. |
| Entrée malformée | signalée | avec position | decodeURIComponent lance un simple URIError. Ici, la séquence fautive est localisée et nommée. |
Questions fréquentes
Pourquoi mon espace est-il un + au lieu de %20 ?
Parce que vous êtes en mode formulaire, qui est correct pour une chaîne de requête ou un corps de POST de formulaire — ce format définit un espace comme +. Dans un segment de chemin ou un fragment, un espace est %20 et un + est un plus littéral. Les deux encodages sont corrects ; c’est d’utiliser le mauvais pour la position qui corrompt la valeur.
encodeURI ou encodeURIComponent ?
encodeURIComponent pour un élément unique — une valeur de requête, un segment de chemin, un fragment. encodeURI pour une URL entière qui doit rester une URL. Le test est simple : si le texte encodé contient des caractères structurels (un ?, un &, un /) et que vous voulez qu’ils continuent de fonctionner, il faut encodeURI ; si vous voulez qu’ils deviennent des données, il faut encodeURIComponent.
Qu’est-ce que %2520 et comment ai-je pu l’obtenir ?
Un espace, encodé deux fois. La première passe a produit %20 ; la seconde a encodé ce % en %25, d’où %2520. Cela signifie généralement qu’une valeur a été encodée par le code applicatif, puis à nouveau par un framework ou un proxy. Le compteur de profondeur ci-dessus montre combien de passes votre entrée survit, donc vous pouvez savoir si une couche est de trop.
Pourquoi !'()* ne sont-ils pas encodés ?
encodeURIComponent les laisse délibérément de côté, alors même que RFC 3986 les réserve. C’est presque toujours inoffensif — jusqu’à ce que la chaîne encodée serve d’entrée à une signature, où signataire et vérificateur doivent concorder octet pour octet. C’est pourquoi AWS SigV4 et OAuth 1.0a spécifient chacun leur propre encodeur. Activez le mode strict si vous êtes dans cette situation.
base64url est-il identique à base64 ?
Même algorithme, alphabet différent. base64 utilise + et /, qui ont tous deux un sens dans une URL, donc base64url les remplace par - et _ et supprime le remplissage =, qui a un sens dans une chaîne de requête. Un JWT, c’est trois segments base64url joints par des points — voilà pourquoi un JWT se colle tel quel dans une URL, et pas un bloc base64.
Mon entrée est-elle envoyée ?
Non. Encoder et décoder sont des opérations sur des chaînes qui s’exécutent dans votre navigateur — ouvrez le panneau Network et regardez pendant que vous tapez. C’est important ici parce que les URL que l’on doit décoder sont fréquemment des URL de rappel signées, des redirections OAuth et des tokens de session, autrement dit des identifiants sous une forme qui paraît inoffensive.
Quels outils liés devriez-vous utiliser ensuite ?
- Encoder et décoder en Base64Base64 standard et URL-safe, téléchargement binaire inclus
- Décoder un JWTLit un JSON Web Token et explique chaque champ
- Générer un hashCalcule l’empreinte de n’importe quelle donnée, algorithmes faibles signalés
- Formater du JSONIndente, trie les clés et supprime les commentaires