Outils d'URL
Encodage d'URL pour les espaces : %20 ou Plus ?
Un espace URL devient %20 dans un composant URI et + uniquement dans la sérialisation de style formulaire.
Par Vigneshwaran Vijayakumar, développeur et éditeur | | Révisé sous le Politique éditoriale de ClockTools
Table des matières
Un espace dans les données URL devient généralement %20, mais la sérialisation des requêtes sous forme de formulaire le représente comme +. Les deux peuvent être corrects. La bonne sortie dépend de la destination : utilisez le codage en pourcentage pour un composant URI individuel et utilisez la convention plus uniquement lorsque le flux de travail de réception attend application/x-www-form-urlencoded données.
Le ClockTools Encodeur d'URL rend ce contexte explicite avec les profils de composant URI, d'URL complète et de données de formulaire. Coller thé vert, changez de profil et comparez la sortie avant de modifier le code de l'application.
Commencez par la destination
Ne demandez pas « Quel symbole signifie toujours espace ? » Demandez quel analyseur recevra la valeur.
Pour un segment de chemin, une valeur de fragment ou une valeur de requête individuelle, le codage en pourcentage est la représentation fiable. L'octet UTF-8 du caractère espace est hexadécimal 20, donc son triplet codé en pourcentage est %20.
Pour les données de style formulaire HTML, la convention de sérialisation utilise + pour les espaces et le pourcentage, code un plus littéral comme %2B. Le Norme d'URL WHATWG définit ce comportement de codage d'URL de formulaire séparément de l'analyse générale d'URL.
Le Syntaxe de l'URI RFC 3986 définit un octet codé en pourcentage comme % suivi de deux chiffres hexadécimaux. Il distingue également les délimiteurs réservés des caractères de données non réservés. Cette distinction est la raison pour laquelle le codage d’une valeur est différent du codage d’une adresse entière.
La table de décision %20 versus plus
| Destination | Représentation spatiale | Exemple pour thé vert | Pourquoi |
|---|---|---|---|
| Segment de chemin | %20 | /sujets/thé vert%20 | Space is data inside one path segment |
| Valeur de requête codée en tant que composant | %20 | ?q=thé vert%20 | L'encodage des composants maintient la valeur séparée des délimiteurs |
| Requête ou corps de requête codé par URL de formulaire | + | q=vert+thé | Le sérialiseur de formulaire mappe l'espace vers plus |
| Affichage complet de l'URL | %20 où un espace littéral doit être sérialisé | https://example.com/green%20tea?q=hot%20cup | Structurel :, /, ?, =, et & restent des délimiteurs |
| Littéral plus données de formulaire intérieures | %2B | q=C%2B%2B | Un simple plus décoderait comme un espace dans ce profil |
La dernière ligne évite un bug courant. Si la valeur prévue est C++, envoi C++ via un décodeur de formulaire peut produire C . Encodez chaque littéral plus comme %2B avant l'analyse du formulaire.
Quatre tests ClockTools reproductibles
Nous avons effectué quatre petites contributions dans le cadre de la mise en œuvre actuelle de l'outil. Son profil de composant URI utilise JavaScript encodeURIComponent. Form Data applique le même codage de composant, puis remplace %20 avec +. Utilisations de l'URL complète encodeURI, qui préserve la structure de l'URL.
| Entrée | Profil | Résultats observés | Interprétation |
|---|---|---|---|
thé vert | Composant URI | thé vert%20 | Un composant, espace codé en pourcentage |
thé vert | Données du formulaire | vert + thé | Convention spatiale de style formulaire |
C++ | Données du formulaire | C%2B%2B | Les signes littéraux plus sont protégés |
https://example.com/a b?q=x y | URL complète | https://example.com/a%20b?q=x%20y | Les délimiteurs d'URL restent structurels |
Il s’agit de résultats de transformation déterministes et non de preuves de classement de recherche. Vous pouvez les reproduire localement dans le navigateur. La page met immédiatement à jour la sortie, signale le pourcentage d'échappements et le nombre d'octets, et n'a pas besoin d'envoyer l'entrée à un serveur pour la conversion.
Utilisez le Décodeur d'URL pour exécuter la vérification inverse. Décoder thé vert%20 sous le profil du composant et vert + thé sous Données du formulaire. Le décodeur avertit lorsqu'un plus apparaît sous un profil non-formulaire car la signification recherchée est ambiguë.
Que protège le codage des composants ?
Une URL utilise la ponctuation comme grammaire. Dans une chaîne de requête, & peut commencer un autre paramètre et = sépare un nom d'une valeur. # commence un fragment. ? commence une requête. Si l'un de ces caractères appartient aux données utilisateur, le laisser brut peut modifier la structure.
Considérez la valeur minuterie et alarme. L'encodage des composants produit minuterie%20%26%20alarme. L'esperluette devient %26, donc un analyseur reçoit une valeur au lieu d'interpréter alarme comme nouveau paramètre.
Le codage est une représentation, pas une validation ou un cryptage. Une redirection codée en pourcentage peut toujours pointer vers un hôte non approuvé après le décodage. Un script codé n’est toujours pas une entrée fiable. Validez les schémas autorisés, les hôtes, les noms de paramètres et les règles métier après l'analyse. Évitez de mettre des mots de passe, des jetons ou d'autres secrets dans les URL, car les adresses peuvent apparaître dans l'historique, les journaux, les analyses, les captures d'écran et les données de référence.
Lorsque vous devez comparer une chaîne de requête avant et après, le Vérificateur de différences de texte rend visible chaque évasion modifiée. C'est plus fiable que d'analyser une longue URL de rappel pour en rechercher une manquante. %25.
Pourquoi le double encodage crée-t-il %2520 ?
Le double encodage se produit lorsqu'un texte déjà encodé est traité comme des données brutes et à nouveau encodé.
Commencez par un espace :
```texte
espace -> %20
```
Encoder %20 comme nouveau composant. Le signe pour cent devient %25, tandis que les chiffres restent littéraux :
```texte
%20 -> %2520
```
Un décodage change %2520 retour à %20. Un deuxième décodage change %20 à un espace. Si votre application attend une passe de décodage mais reçoit une valeur doublement codée, l'utilisateur peut voir %20 au lieu d'un blanc.
La solution consiste à ne pas décoder à plusieurs reprises jusqu'à ce que le texte semble correct. Un décodage répété peut modifier les délimiteurs délibérément codés et créer des problèmes de sécurité. Identifiez la limite de propriété : exactement une couche doit coder le composant et exactement une couche correspondante doit le décoder.
Un chemin de débogage en cas de non-concordance d'espace
Utilisez ce chemin lorsqu'un système envoie %20 et un autre affiche +, %2520, ou un blanc littéral.
1. Capturez la valeur brute avant qu'un analyseur de framework ne la modifie.
2. Identifiez si le champ est un segment de chemin, un composant de requête, une URL complète ou un corps de formulaire.
3. Enregistrez la valeur décodée attendue, y compris les signes plus littéraux.
4. Reproduisez la même entrée dans le profil ClockTools correspondant.
5. Décodez une fois avec le profil de réception.
6. Comparez le résultat avec la valeur attendue.
7. Recherchez dans le flux d'application un deuxième encodeur ou décodeur si %25 apparaît de manière inattendue.
| Symptôme | Premier contrôle | Cause probable |
|---|---|---|
vert + thé reste avec un plus | Profil du décodeur | Le décodeur de composants ne mappe pas le plus à l'espace |
C++ devient C | Encodage de l'expéditeur | Les signes littéraux plus n'étaient pas codés comme %2B |
%20 est visible par l'utilisateur | Nombre de décodages | Les données codées n'ont jamais été décodées ou ont été codées deux fois auparavant |
%2520 apparaît dans une demande | Encoder le nombre | Signe de pourcentage de %20 a été à nouveau codé |
| La requête se divise après une esperluette | Limite du composant | Une esperluette de données a été laissée brute |
Ce chemin de débogage est intentionnellement étroit. Il sépare le contexte des données des conjectures, et chaque étape a une entrée et une sortie visibles.
Quand faut-il encoder une URL complète ?
Utilisez le profil URL complète uniquement lorsque vous souhaitez que l'adresse reste une adresse. Il préserve la ponctuation structurelle telle que le schéma deux-points, les barres obliques, le point d'interrogation, le signe égal, l'esperluette et le marqueur de fragment lors du codage de caractères tels que les espaces.
Utilisez le composant URI lorsqu'une URL complète est elle-même imbriquée dans un autre paramètre. Par exemple, une adresse de rappel placée dans redirection = sont des données du point de vue de l'URL externe. Le codage de l'adresse imbriquée comme un seul composant empêche sa ? et & de rejoindre la requête externe.
Ne transmettez pas une adresse à plusieurs reprises via différents profils en espérant obtenir une chaîne universellement sûre. Écrivez explicitement la limite :
```texte
structure de l'URL externe + encodeURIComponent (URL de rappel interne)
```
L'application réceptrice doit analyser l'URL externe, extraire le composant de rappel, le décoder une fois, analyser l'URL interne résultante et valider la destination. Le codage conserve la syntaxe intacte ; la validation décide si la destination est autorisée.
Foire aux questions
Un espace d'URL doit-il être %20 ou un signe plus ?
Utilisez %20 pour un espace à l'intérieur d'un composant URI général. Utilisez + lorsque le workflow de réception attend explicitement la sérialisation application/x-www-form-urlencoded.
Pourquoi un signe plus est-il décodé comme un espace ?
Les analyseurs de style formulaire mappent + à un espace dans le cadre de la convention form-urlencoded. Un décodeur de composants généraux n'est pas obligé d'appliquer cette substitution.
Comment encoder les données d'un formulaire de connexion littéral plus ?
Encodez le plus comme %2B. Sinon, un décodeur de formulaire peut interpréter le simple plus comme un espace.
Que signifie %2520 ?
%2520 indique généralement un double encodage. Le signe de pourcentage dans un échappement %20 existant est devenu %25, donc un décodage renvoie %20 et un deuxième décodage renvoie un espace.
Dois-je encoder une URL entière avec encodeURIComponent ?
Pas quand son schéma, ses barres obliques, ses délimiteurs de requête et son marqueur de fragment doivent rester structurels. Utilisez l'encodage des composants lorsque l'URL entière est imbriquée sous forme de données dans une autre valeur.
Le codage d’URL sécurise-t-il les entrées non fiables ?
Non. L'encodage préserve les limites de syntaxe, mais le récepteur doit toujours valider les schémas, les hôtes, les redirections, les valeurs de paramètres, les autorisations et autres règles métier après l'analyse.
À propos de l'auteur
Vigneshwaran Vijayakumar
Fondateur, développeur et éditeur de ClockTools | Responsable Marketing Numérique | Inde
Vigneshwaran est un ingénieur possédant des décennies d'expérience technique, notamment un travail professionnel en tant que responsable du marketing numérique à Dubaï. Son travail relie l'analyse des données, l'optimisation des moteurs de recherche, l'optimisation du taux de conversion, les systèmes de contenu, la production visuelle, l'IA appliquée et l'apprentissage automatique. Chez ClockTools, il transforme cette expérience multidisciplinaire en utilitaires de navigation ciblés et en guides pratiques prenant en compte les sources.