Command Palette

Search for a command to run...

Encodage et décodage des URL en ligne : le guide complet de l'encodage des pourcentages sans casser vos liens

Encodage et décodage des URL en ligne : le guide complet de l'encodage des pourcentages sans casser vos liens

T
Toolz Team
|Jul 11, 2026|27 min read

Le bug qui m'a appris à respecter le pourcentage de codage était une redirection OAuth qui a échoué pour exactement un client. WP Adminify avait une intégration Google Fonts qui s'authentifiait via OAuth, et un utilisateur - un revendeur d'hébergement exécutant une configuration de proxy inverse, que je ne comprends toujours pas entièrement - n'arrêtait pas de recevoir redirect_uri_mismatch erreurs. Tout le monde allait bien. J'ai passé la plus grande partie de deux jours à blâmer sa configuration de serveur. Ensuite, j'ai finalement regardé l'URL réelle que son navigateur envoyait, caractère par personnage, et c'était là : %2520 où un espace aurait dû être. Son proxy était encodant le redirect_uri. mon plugin était aussi l'encoder. Google a reçu une URL dans laquelle l'espace avait été codé deux fois — %20 devenu %2520 — et rejeté toute la poignée de main. Deux lignes de code l'ont corrigé. Deux jours pour le trouver.

Ce n'était même pas mon premier désastre d'encodage. Des années plus tôt, j'ai créé un lien de campagne pour un lancement de plugin avec un paramètre UTM contenant une esperluette brute, quelque chose comme utm_campaign=black&friday. Le tableau de bord Analytics a montré une mystérieuse campagne appelée black et un paramètre fantôme appelé friday Cela ne correspondait à rien. L'esperluette avait silencieusement divisé mon paramètre en deux. Pas d'erreur. Pas d'avertissement. Juste discrètement de mauvaises données pendant onze jours avant que j'aie remarqué que les chiffres ne s'accumulaient pas.

Voici le problème avec l'encodage des URL : c'est l'un de ces problèmes qui semble insignifiant jusqu'à ce qu'il ne soit pas. Les règles sont disponibles dans une spécification 2005 (RFC 3986), la réalité du navigateur vit dans une spécification différente (le standard d'URL Whatwg), JavaScript vous offre trois fonctions différentes qui font toutes des choses légèrement différentes, et PHP vous en donne deux autres. Ne vous trompez pas et vous n'obtenez pas de plantage - vous obtenez des paramètres tronqués, des flux OAuth cassés et des liens qui fonctionnent dans Chrome mais qui meurent dans un client de messagerie.

J'ai donc construit l'encodeur/décodeur que j'ai toujours voulu dans toolz.dev. Ce guide explique comment l'utiliser et, plus important encore, le fonctionnement réel du pourcentage de codage, de sorte que le prochain %2520 Dans vos journaux vous prend deux minutes au lieu de deux jours.

tl;dr : Pour encoder ou décoder en ligne l'URL, collez votre chaîne dans le Encodeur/décodeur d'URL d'URL d'outils.dev, choisissez un mode et appuyez sur Encoder ou décoder. Il gère correctement UTF-8 et Emoji, et le bouton d'échange renvoie la sortie dans l'entrée afin que vous puissiez décoller les valeurs à double encodage (%2520) à part une couche à la fois. Tout s'exécute côté client, donc les jetons et les ID de session dans vos URL ne touchent jamais un serveur. Encoder le paramètre valeurs Avec le mode composant, encodez uniquement les URL complètes lorsque vous savez pourquoi.

Principales caractéristiques

Encoder et décoder dans un seul outil

La moitié du temps, j'ai besoin d'encoder une valeur. L'autre moitié, je regarde une URL noueuse à partir d'un fichier journal et je dois la décoder en quelque chose de lisible. L'outil fait les deux à partir d'une boîte de saisie - encoder et décoder l'un à côté de l'autre sous forme de deux boutons, il n'y a donc pas de recherche d'une page séparée. Collez une chaîne encodée et décodez le code de frappe ; tapez une valeur brute et encodez encodage. Il s'effectue également de manière propre : encodez, décodez et vous récupérez votre chaîne d'origine, octet pour octet. Cela semble évident, mais j'ai utilisé des outils en ligne qui mutilent plus les signes lors de l'aller-retour car ils ne pouvaient pas décider quelle spécification ils suivaient. Celui-ci est explicite sur ce qu'il fait à chaque étape, ce qui est exactement ce que vous voulez lorsque vous déboguez.

Composant vs Modes d'encodage complets en URL

Cette distinction est la source de la plupart des bogues d'encodage. Le mode composant code tout ce qui n'est pas réservé, y compris /, ?, &, et = — C'est ce que vous voulez pour une valeur de paramètre unique. Le mode URL complète laisse les caractères structurels seuls, de sorte que l'URL fonctionne toujours comme une URL, ce que vous voulez lorsque vous nettoyez une adresse complète. L'utilisation du mauvais soit casse la structure de votre URL ou laisse les caractères dangereux non codés. L'outil sépare les deux modes d'un clic en une seule liste déroulante, étiquetée avec la fonction JavaScript à laquelle correspondent les éléments : encodeURIComponent, encodeURI, application/x-www-form-urlencoded. J'ai fait des allers-retours sur cette dénomination. Les étiquettes d'intention ("encoder une valeur", "encoder une URL entière") liraient mieux le froid, mais les noms de fonction signifient que le panneau de référence sous la correspondance est un à un sur le code que vous êtes sur le point d'écrire, et c'est le moment où la plupart des gens sont réellement dans lesquels se trouvent. Si vous avez déjà tapé encodeURI Quand tu voulais dire encodeURIComponent — J'ai, plus d'une fois, le panneau est là pour l'attraper avant d'expédier.

Gère les personnages UTF-8, emoji et internationaux

taper à la café Et tu reçois caf%C3%A9 — le é correctement étendu à ses deux octets UTF-8. Tapez un emoji et vous obtenez un octet de 4 %. C'est là que les outils plus anciens et le Javascript obsolète escape() Fonction s'effondrer : ils supposent latin-1 ou produisent des %uXXXX Séquences qu'aucun serveur ne peut analyser. Si vous créez des URL avec du contenu généré par les utilisateurs - noms, requêtes de recherche, noms de ville dans une langue qui n'est pas anglaise - la gestion correcte de l'UTF-8 n'est pas une bonne chose à avoir. Texte bengali, limaces arabes, termes de recherche chinois : tous encodent en des séquences de 3 986 pourcentage valides qui décodent de la même manière à l'autre extrémité.

Un bouton d'échange pour les valeurs à double encodage

le %2520 Trap — un déjà codé %20 Être encodé à nouveau - me coûte deux jours une fois, donc celui-ci est personnel. Le décodage est une opération monocouche : %2520 Décodes %20, pas à un espace, car %25 est Le codage de %. Un passage vous donne une couche. Le bouton d'échange () Replace la sortie dans la zone de saisie afin que le prochain passage soit à un clic. J'ai déballé les URL de trois couches après leur passage dans un proxy, un service de redirection et un lien de messagerie électronique - échanger, décoder, échanger, décoder, jusqu'à ce que la chaîne cesse de changer. Ce "arrêt de changement" est le signal que vous recherchez. Soyez honnête à propos de ce que c'est : c'est une boucle manuelle, pas un détecteur. L'outil n'est pas signalé %25XX Pour vous, et je vais et je vais et je vais sur la question de savoir si cela devrait être le cas - le décodage automatique jusqu'à ce que Stable convienne jusqu'à ce qu'il détruise silencieusement une valeur qui contenait légitimement un pourcentage de signe.

Trois modes, un panneau de référence explicite

Le sélecteur de mode propose trois options - composant, URL complète et form-urlencoded - et le panneau en dessous précise exactement les caractères de ce mode, qu'il conserve, et montre un exemple travaillé. Je l'ai ajouté parce que je ne me souvenais jamais si encodeURIComponent feuilles ~ seul (c'est le cas) ou si ! et * Survivre (ils le font, ce qui surprend les gens, puisque la RFC 3986 les classe comme des sous-délims plutôt que non réservés). Au lieu de mémoriser trois fonctions JavaScript, vous choisissez le mode par intention et relisez ce qu'il est sur le point de faire. Ce texte de référence est la partie que j'utilise le plus, et c'est ce que je voudrais si j'atterris sur la page froide à 1 h du matin.

100 % côté client, rien ne quitte votre navigateur

Pensez à ce qui se trouve réellement à l'intérieur des URL que vous décodez : codes d'autorisation OAuth, jetons de réinitialisation de mot de passe, ID de session, adresses e-mail dans les liens de désabonnement, clés d'API, un framework utilement rempli dans une chaîne de requête. Collez-les dans un outil côté serveur et ils atterrissent dans les journaux d'accès de quelqu'un, liés à votre IP, conservés pour qui sait combien de temps. L'encodeur Toolz.dev s'exécute entièrement dans votre navigateur. La conversion est quelques lignes d'exécution localement JavaScript et aucune demande n'est effectuée avec vos données. Ouvrez DevTools et regardez l'onglet Réseau si vous ne me croyez pas. Pour tout ce qui est adjacent à la sécurité, le côté client n'est pas une fonctionnalité, c'est la barre minimale.

Gratuit, pas d'inscription, pas de limites

Pas de mur de compte, pas de quota quotidien n'agissant pour un outil qui effectue la transformation de chaînes, pas de "mise à niveau vers Pro pour décoder plus de 1 000 caractères." J'ai créé Toolz.dev parce que j'en avais assez des sites utilitaires qui interrompent une tâche de dix secondes avec une fenêtre contextuelle. Marquez-le, utilisez-le cinquante fois par jour, c'est fait.

Comment utiliser l'encodeur et le décodeur d'URL

Étape 1 : ouvrez l'outil et choisissez votre direction

se porter toolz.dev/tools/encoder URL et déposez votre ficelle dans la boîte de gauche. Il existe deux boutons d'action, encoder et décoder, et vous en choisissez un après avoir collé plutôt que de définir une direction en premier. Si vous partez de quelque chose de lisible (une requête de recherche, une URL de redirection que vous êtes sur le point d'intégrer), appuyez sur Encode. Si vous partez de quelque chose de plein de signes de pourcentage (une entrée de journal, un en-tête de référence), appuyez sur Decoder. La sortie atterrit dans le volet de droite avec un bouton de copie dans son en-tête, et échangez et s'assoient à côté des deux boutons d'action.

Étape 2 : Choisissez le composant, l'URL complète ou le mode de formulaire

encoder un évaluer Cela se situera dans un paramètre - un redirect_uri, un terme de recherche, n'importe quoi après un = Signe ? Utilisez le mode composant. il encode /, ?, &, et = Votre valeur ne peut donc pas casser l'URL environnante. encoder un URL complète qui n'a besoin que d'espaces et de caractères non ASCII nettoyés ? Utilisez le mode Full-URL, qui préserve les caractères structurels. Le troisième mode, form-urlencoded, est un encodage de composants avec des espaces écrits comme + au lieu de %20 — Choisissez-le lorsque vous construisez à la main un application/x-www-form-urlencoded corps. Notez que le mode affecte également le décodage : en mode Formulaire, + est reconvertie en espace avant décodage ; dans les deux autres, il reste un plus littéral. En cas de doute : mode composant pour les pièces, mode URL complète pour les ensembles.

Étape 3 : Lisez la sortie et surveillez les signes de pourcentage restants

La sortie apparaît dans le volet de droite. Pour le décodage, vérifiez si le résultat contient toujours %XX Séquences — Si c'est le cas, la valeur a été codée plusieurs fois. Appuyez sur Swap pour déplacer cette sortie dans l'entrée, décodez à nouveau et répétez jusqu'à ce que la chaîne cesse de changer. Si l'entrée est mal formée (un parasite % Non suivi de deux chiffres hexadécimaux, comme un littéral 100%), vous obtiendrez une erreur explicite plutôt qu'un demi-décode silencieux, quel est le comportement que vous souhaitez lorsque vous déboguez.

Étape 4 : Copiez et vérifiez

Appuyez sur le bouton Copier et collez le résultat à l'endroit où il appartient. Pour tout ce qui est important - OAuth redirige en particulier - effectuez une vérification de santé mentale finale : collez la valeur codée en mode décodage et confirmez-la à exactement ce que vous avez commencé. Trente secondes de vérification bat deux jours de redirect_uri_mismatch.

Pourcentage de codage, RFC 3986, et pourquoi les espaces deviennent soit 20 ou +

Les URL ne peuvent contenir en toute sécurité qu'un ensemble limité de caractères. Tout le reste doit être introduit en contrebande sous forme de pourcentage d'octets codés. Le livret de règles est RFC 3986 (2005), et il divise les personnages en deux camps.

Personnages non réservés N'ayez jamais besoin d'encodage : les lettres A–Z et a–z, chiffres 0–9, et quatre symboles — trait d'union -, période ., souligner _, et Tilde ~. Les encoder est légal mais inutile.

Personnages réservés Ayez des travaux structurels dans une URL : : / ? # [ ] @ (les délimiteurs généraux) et ! $ & ' ( ) * + , ; = (les sous-délimiteurs). Le côlon sépare le schéma de l'hôte. Le point d'interrogation démarre la chaîne de requête. L'esperluette sépare les paramètres. Le fait qu'un caractère réservé ait besoin d'un encodage dépend entièrement de Où il apparaît. un / dans le chemin est la structure ; un / Dans une valeur de paramètre REDIRECT_URI, il y a des données, et il doit devenir %2F Ou le serveur analysera mal votre URL.

La mécanique : prenez le caractère, obtenez son ou ses octets UTF-8 et écrivez chaque octet comme % suivi de deux chiffres hexadécimaux. Les caractères ASCII sont un octet — l'espace est %20, l'esperluette est %26. Mais UTF-8 est un encodage multi-octets, donc é est de deux octets : %C3%A9. Un emoji typique est de quatre octets - 🚀 encode comme %F0%9F%9A%80. C'est pourquoi les outils qui supposent qu'un caractère est égal à un octet corrompt tout ce qui est en dehors de l'anglais simple.

Maintenant, le problème de l'espace - la chose la plus déroutante dans l'encodage d'URL. Selon la RFC 3986, un espace devient %20. Mais les soumissions de formulaires HTML utilisent une sérialisation différente, application/x-www-form-urlencoded, défini aujourd'hui dans le WhatWG URL standard, et celui Le format encode les espaces comme +. Les deux sont corrects - dans leur propre contexte. ce qui signifie + Dans une chaîne de requête est ambigu : il peut s'agir d'un signe plus littéral (lecture RFC 3986) ou d'un espace codé (lecture de code de forme). Si vous avez déjà vu un numéro de téléphone arriver comme 1234 5678 Quand quelqu'un a envoyé +1234..., vous avez rencontré ce bug. Mon conseil : toujours émettre %20 Pour les espaces et %2B Pour les signes plus littéraux. Personne ne les a mal analysés.

JavaScript vous donne trois fonctions, et elles ne sont pas interchangeables. Étant donné la chaîne a=b&c d:

const s = "a=b&c d";

encodeURIComponent(s); // "a%3Db%26c%20d"  — encodes =, &, and space
encodeURI(s);          // "a=b&c%20d"      — leaves = and & alone
escape(s);             // "a%3Db%26c%20d"  — deprecated; breaks on Unicode

encodeURIComponent Encode tout sauf les caractères non réservés (plus !'()* — Une bizarrerie héritée), ce qui le rend sûr pour les valeurs des paramètres. encodeURI Conserve les caractères réservés de sorte qu'une URL complète reste fonctionnelle, mais cela signifie également qu'elle ne sera pas protéger un & à l'intérieur de vos données. et escape() est obsolète pour une bonne raison : il produit des produits non standard %uXXXX Séquences pour les caractères non latins-1. Ne l'utilisez jamais dans un nouveau code.

PHP reflète la même répartition avec une torsion : urlencode() Produit un encodage de style forme (les espaces deviennent +), tandis que rawurlencode() Suit la RFC 3986 (les espaces deviennent %20). Si vous créez des URL pour autre chose qu'un corps de poste de formulaire, rawurlencode() est celui que vous voulez. J'ai expédié le code d'administration WP avec le mauvais dès le début ; WordPress's Own add_query_arg() m'a fait gagner plus de fois que je ne voudrais l'admettre.

Enfin, le piège à double encodage. %20 est un espace, codé. encoder cette chaîne encore et le % lui-même devient %25, vous donnant %2520. décodez-le une fois et vous obtenez %20 Retour — toujours encodé. Cela se produit chaque fois que deux couches d'un système encodent chaque "de manière utile" : votre code plus un proxy, un service de redirection plus un lien-enrouleur de messagerie. La règle qui l'empêche : encodez une fois exactement, au dernier moment possible avant que la valeur n'entre dans l'URL, et n'encodez jamais quelque chose que vous n'avez pas simplement décodé ou généré.

Cas d'utilisation courants

Créer des chaînes de requête avec une entrée utilisateur

À chaque fois que le texte saisi par l'utilisateur est envoyé dans une URL (zones de recherche, filtres, valeurs de formulaire transmises via GET), il doit être codé en composant. Un utilisateur recherche Q&A tips se transforme ?q=Q%26A%20tips; non encodé, le serveur voit une recherche Q et un paramètre mystère A tips. Pendant le développement, j'utilise le Encodeur d'URL Pour générer des valeurs attendues avant d'écrire le code, j'ai donc une référence connue correcte à tester. C'est aussi le moyen le plus rapide de régler "ce caractère doit être encodé ?" Arguments dans la revue de code : collez-le en mode composant et regardez. Les API modernes comme JavaScript URLSearchParams Gérez-le automatiquement et vous devez les utiliser, mais vous devez toujours vérifier Leur sortie lorsque quelque chose se casse, et c'est un travail de décodage.

Déboguer les liens UTM et campagne

Les liens marketing sont l'encodage des champs de mines. Les valeurs UTM avec des espaces, des tuyaux ou des esperluettes, des liens qui passent par un raccourcisseur d'URL, puis un service de messagerie, un suivi des clics, puis une redirection, chaque couche étant une chance d'ajouter ou de mutiquer l'encodage. Lorsqu'une campagne apparaît mal dans Analytics, mon premier coup est toujours le même : collez le lien complet en mode décodage et lisez ce que le serveur d'analyse a réellement reçu. Neuf fois sur dix, le coupable est visible en quelques secondes - un brut & fractionnement d'un paramètre, un + qui était censé être un plus littéral, ou un %2520 trahir le double encodage. mon black&friday L'incident aurait été une solution de onze secondes au lieu d'un trou de données de onze jours si je l'avais fait le premier jour.

OAuth redirect_uri et URL de rappel

OAuth est l'endroit où les erreurs d'encodage coûtent cher, car les fournisseurs Correspondance exacte des chaînes sur les URI de redirection. Le redirect_uri est une URL complète intégrée en tant que valeur de paramètre dans une autre URL. Elle doit donc être codée par composant, exactement une fois. sous-coder le et le ? ou & À l'intérieur, il casse l'URL d'autorisation externe. Double-encodez et le fournisseur compare https%3A%2F%2F... contre votre enregistré https://... et revient redirect_uri_mismatch Avec zéro détail supplémentaire. Lorsque cette erreur apparaît, décodez l'URL d'autorisation réelle à partir de la barre d'adresse de votre navigateur et comparez le caractère par caractère de redirect_uri avec la valeur enregistrée de votre application. associez-le à la Décodeur JWT Pour inspecter les jetons qui reviennent, et vous pouvez déboguer un flux OAuth entier sans quitter le navigateur.

Décodage des URL noueuses des journaux et des en-têtes de référent

Les journaux de serveurs et les en-têtes de référence sont remplis de soupes en pourcentage : %D0%9F%D1%80%D0%B8%D0%B2%D0%B5%D1%82 Dans un référent de recherche, les chemins à triple codé du trafic de bot, les charges utiles codées dans les requêtes suspectes. Les décoder est la façon dont vous découvrez ce qui s'est réellement passé, que ce 404 étrange soit un utilisateur avec une requête cyrillique ou un script pour ../../etc/passwd Derrière trois couches d'encodage. C'est aussi exactement la situation où l'angle de confidentialité est le plus important : les URL de journaux contiennent régulièrement des jetons de session et des adresses e-mail. Décodez-les dans un outil côté client, et non sur un serveur aléatoire qui conserve ses propres journaux. J'ai écrit plus sur ce flux de travail dans le Guide des outils de débogage de l'API.

Test d'API avec curl

Votre coque et votre boucle forment un deuxième champ de mines en plus de l'encodage d'URL. & Arrière-plan un processus en bash, ? Déclenche l'extension Glob en ZSH - une URL non codée et non codée échoue de manière confuse avant même qu'elle n'atteigne le réseau. Mon workflow : encodez chaque valeur de paramètre dans l'outil, assemblez l'URL, enveloppez-la entre guillemets simples, puis exécutez curl. Lorsqu'une API renvoie un 400 pour une requête qui "a bien l'air", je décode l'URL exacte à partir de la sortie verbeuse (curl -v) pour voir ce qui a été réellement envoyé - plus d'une fois, le bogue était mon terminal, pas mon API. --data-urlencode FLAG gère l'encodage pour les corps de poste, mais pour obtenir des chaînes de requête, vous êtes principalement seul, et un encodeur fiable vaut de deviner.

Partage de liens avec du texte non-ASCII

Articles Wikipedia dans d'autres langues, liens Google Maps avec des noms de lieux locaux, URL de documents avec bengali ou limaces arabes - copiez-en un à partir de votre barre d'adresse et vous pouvez obtenir la forme Pretty Unicode ou un mur de %E0%A6%AC-Style Bytes, selon l'humeur du navigateur. Certaines applications de chat et clients de messagerie tronquent ou mutilent la forme Unicode brute. L'encodage de l'URL avant de partager produit une chaîne Pure-ASCII qui survit à chaque messager, liste de diffusion et rendu Markdown que j'ai essayé. Dans l'autre sens, le décodage transforme un lien partagé illisible en quelque chose qu'un humain peut vérifier avant de cliquer, ça vaut la peine d'être fait avant de transmettre tout ce qui est arrivé ressemblant à un bruit de ligne.

EncodeURIComponent vs EncodeURI vs Escape() : Lequel utiliser ?

Trois fonctions, une par défaut correcte. Voici la comparaison honnête :

encodeURIComponent() encodeURI() escape()
encoder Tout sauf A-Z a-z 0-9 - . _ ~ ! ' ( ) * Tout sauf non réservé + tous les caractères réservés (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) Tout sauf A-Z a-z 0-9 @ * _ + - . /
L'espace devient %20 %20 %20
& et = encodé (%26, %3D) Non encodé encodé
Gestion des Unicodes Corriger les octets UTF-8 Corriger les octets UTF-8 Cassé — non standard %uXXXX
utiliser pour Valeurs de paramètres, segments de chemin, tout ce qui se trouve dans une URL Une URL complète que vous ne souhaitez pas restructurer nullité
situation Standard, recommandé Standard, niche obsolète

Ma position, et je mourrai sur cette colline : manier encodeURIComponent Pour les valeurs, presque toujours. Le modèle mental est simple - si la chaîne va à l'intérieur Une URL (une valeur de requête, un segment de chemin, un redirection_URI), c'est un composant, et il obtient encodeURIComponent. les cas où encodeURI Il est vraiment rare de savoir que vous avez une URL complète, déjà structurée, contenant des espaces ou des caractères non ASCII, et vous souhaitez la désinfecter sans toucher sa structure. C'est peut-être 5 % des appels d'encodage dans le monde réel. et escape() Ne devrait jamais apparaître dans le code écrit après environ 2010 - sa sortie Unicode n'est pas valide en pourcentage, et chaque linter moderne le signalera de toute façon.

Une autre nuance : encodeURIComponent feuilles ! ' ( ) * Non codé pour des raisons historiques, même si RFC 3986 les répertorie comme des sous-délimiteurs réservés. Pour les API OAuth et parsage stricte, certaines bibliothèques ajoutent également un deuxième passage pour encoder ces cinq. Si une API difficile rejette vos valeurs, c'est un endroit à regarder - et le Encodeur d'URL Le mode composant vous indique exactement quels caractères ont été convertis afin que vous puissiez comparer.

Questions fréquentes

Qu'est-ce que l'encodage d'URL ?

L'encodage d'URL (encodage en pourcentage) est le mécanisme de représentation des caractères dans une URL qui serait autrement dangereuse ou structurellement significative. Chaque caractère problématique est converti en ses octets UTF-8, et chaque octet est écrit sous la forme d'un signe de pourcentage suivi de deux chiffres hexadécimaux - un espace devient %20, un esperlu devient %26. Les règles sont définies dans la RFC 3986. Il existe parce que les URL ne permettent qu'un jeu de caractères limité et que des caractères comme ? et & ont des travaux à faire dans la structure d'URL.

Pourquoi les espaces se transforment-ils parfois en %20 et + d'autres fois ?

Deux spécifications différentes. RFC 3986, qui régit les URL eux-mêmes, encode un espace à %20. Le format application/x-www-form-urlencode utilisé par les soumissions de formulaires HTML, défini dans la norme d'URL Whatwg, encode un espace comme +. Les deux sont valides dans leur propre contexte, c'est pourquoi + dans une chaîne de requête est ambigu. La pratique sûre : produisez toujours %20 pour les espaces et %2b pour les signes littéraux et les signes plus — chaque analyseur les gère correctement.

Quelle est la différence entre EncodeURI et EncodeURIComponent ?

EncodeURIComponent encode presque tout, y compris /, ?, &, et =, ce qui le rend sûr pour les valeurs individuelles placées dans une URL. EncodeURI conserve les caractères réservés afin qu'une URL complète sa structure. Utilisez EncodeURIComponent pour les valeurs des paramètres et les segments de chemin, ce qui est presque tous les cas réels, et EncodeURI uniquement lors de la désinfection d'une URL complète sans la restructurer. L'utilisation d'EncodeURI sur une valeur contenant & va interrompre silencieusement votre chaîne de requête.

Comment réparer une URL à double encodage ?

Le double encodage se produit lorsqu'une chaîne déjà codée est de nouveau encodée — %20 devient %2520 car le % lui-même se transforme en %25. Pour le réparer, décodez la chaîne de manière répétée jusqu'à ce qu'il ne reste aucune séquence %XX et que la sortie ne change pas. Ensuite, recherchez deux fois la couche de votre système encodée deux fois – généralement votre code, ainsi qu'un proxy, un service de redirection ou un lien de messagerie électronique – et supprimez l'une des étapes d'encodage. La règle : encodez une fois exactement, au dernier moment avant que la valeur n'entre dans l'URL.

Est-il sécuritaire de décoder les URL dans un outil en ligne ?

Uniquement si l'outil exécute le client. Les URL contiennent souvent des codes OAuth, des jetons de réinitialisation des mots de passe, des ID de session et des adresses e-mail. Un outil côté serveur reçoit tout cela et peut le conserver indéfiniment dans les journaux d'accès. L'encodeur/décodeur d'URL d'URL de Toolz.dev effectue toutes les conversions dans votre navigateur avec JavaScript - aucune donnée n'est transmise n'importe où, ce que vous pouvez vérifier dans l'onglet Réseau de votre navigateur. Pour tout ce qui contient des informations d'identification ou des jetons, le traitement côté client doit être non négociable.

Dois-je encoder l'intégralité de l'URL ou simplement les paramètres ?

Juste les parties de données — valeurs de paramètres individuels et, occasionnellement, segments de chemin. Les caractères structurels de l'URL elle-même (le :// après le schéma, le ? Au démarrage de la requête, le & entre les paramètres) doit rester non codé ou l'URL cesse de fonctionner. Encodez chaque valeur séparément avec un encodage de style composant, puis assemblez l'URL autour d'elles. Encoder une URL complète de bout en bout n'est correcte que lorsque cette URL devient elle-même une valeur dans une autre URL, comme un OAuth redirect_URI.

L'encodage d'URL peut-il gérer les caractères emoji et non anglais ?

Oui : le codage moderne en pourcentage fonctionne sur UTF-8 octets, donc tout caractère Unicode fonctionne. Un caractère de deux octets comme é devient %C3%A9, et un emoji de quatre octets devient quatre pour cent de séquences, comme %F0%9F%9A%80. Les problèmes ne surviennent qu'avec les outils hérités ou la fonction escape() obsolète de JavaScript, qui supposent des encodages à un octet et produisent une sortie non valide. L'encodeur Toolz.dev gère correctement l'UTF-8 dans les deux sens.

Pourquoi mon URL se casse-t-il lorsqu'un paramètre contient un esperluette ?

Parce que & est le délimiteur entre les paramètres. Si une valeur contient une esperluette brute — disons UTM_CAMPAIGN=Black&vendredi — le serveur l'analyse comme un paramètre nommé UTM_CAMPAIGN avec la valeur noire, plus un deuxième paramètre nommé vendredi. Aucune erreur n'est déclenchée, vos données sont simplement faussement fausses. Encodez l'esperluette comme %26 à l'intérieur de la valeur et le paramètre arrive intact. Il s'agit de l'un des bugs d'URL les plus courants et les moins visibles.

Que signifie %2f dans une URL ?

%2f est la barre oblique en pourcentage codée en pourcentage. Vous le verrez lorsqu'une valeur qui contient une barre oblique - un chemin de fichier, une date comme le 07/07 ou une URL imbriquée - est correctement codée avant d'être placée dans un paramètre de requête ou un segment de chemin. Sachez que certains serveurs et proxy (Apache, anciennes versions de Tomcat, diverses passerelles API) rejettent ou décodent en silence %2f dans le chemin pour des raisons de sécurité, donc si une requête avec un slash renvoie un 404, la configuration côté serveur est généralement le coupable, pas votre encodage.

Comment puis-je encoder l'URL en python, php ou sur la ligne de commande ?

python : urllib.parse.quote() pour les segments de chemin et quote_plus() pour les valeurs de requête de style de formulaire. PHP : RawUrlencode() produit une sortie RFC 3986 avec %20 pour les espaces, tandis que urlencode() produit une sortie de style forme avec +. Ligne de commande : jq -rr @uri ou curl's --data-data-urlencode Flag. Chacun de ces éléments correspond au comportement de style composant de cet outil, afin que vous puissiez prototyper l'encodage ici et vérifier que votre code produit une sortie identique à l'octet.

arrivée

L'encodage d'URL est une petite compétence avec un gain surdimensionné. Une fois que vous pouvez lire %C3%A9 Comme un é et un spot %2520 En tant qu'odeur à double encodage, toute une catégorie de "ça fonctionne sur ma machine" bugs - flux d'OAuth cassés, campagnes Phantom UTM, API rejetant des demandes parfaitement raisonnables - passe de mystérieuse à mécanique. Les règles s'adaptent à une fiche : les caractères non réservés sont transmis, tout le reste devient UTF-8 octets en tant que %hh, coder des valeurs non structures et encoder une fois exactement.

Gardez le Encodeur/décodeur d'URL marqué à côté de ses frères et sœurs - le Convertisseur de base64 Pour l'autre schéma d'encodage que vous rencontrerez dans chaque en-tête d'authentification (j'ai écrit un Guide d'encodage Base64 Quand utiliser lequel), le Encodeur/décodeur d'entités HTML Pour la troisième couche d'encodage que le contenu Web aime empiler sur le dessus (le Guide d'entité HTML Couvre la version à double échappement du même piège avec lequel j'ai frappé %2520), et le Formateur JSON pour quel que soit l'URL décodée.

Et si vous assemblez un kit de débogage basé sur un navigateur plus large, le Guide des outils de codage Parcoure la façon dont ces outils s'intègrent dans un véritable flux de travail. Tout sur Toolz.dev fonctionne côté client, ne coûte rien et fait bien un travail. C'est tout le terrain - le même que celui que j'aurais aimé m'avoir fait avant de passer deux jours sur un seul % déplacé.

Frequently Asked Questions

URL encoding (percent-encoding) is the mechanism for representing characters in a URL that would otherwise be unsafe or structurally meaningful. Each problematic character is converted to its UTF-8 bytes, and each byte is written as a percent sign followed by two hexadecimal digits — a space becomes %20, an ampersand becomes %26. The rules are defined in RFC 3986. It exists because URLs only permit a limited character set, and characters like ? and & have jobs to do inside URL structure.

Comments

0 comments

0/2000 characters

No comments yet. Be the first to share your thoughts!