Coder et décoder une URL

L'encodage et le décodage d'URL appliquent le codage en pourcentage RFC 3986 au texte et inverse les séquences « %HH » en caractères. Le mode composant code les caractères réservés tels que /, ? et & afin qu'ils puissent être placés en toute sécurité dans un seul paramètre de requête. Le mode Full-URI préserve les délimiteurs structurels afin qu'une adresse complète reste un lien utilisable. La gestion de l'espace offre à la fois « %20 » et le signe plus d'encodage de formulaire.

Tout l’encodage et le décodage s’exécutent dans votre navigateur. Rien de ce que vous collez n'est envoyé à un serveur.

Encoder du texte pour une utilisation sûre dans une URL

Le codage en pourcentage remplace les octets non sécurisés ou réservés par un signe de pourcentage suivi de deux chiffres hexadécimaux. Les chiffres sont la valeur de l'octet, généralement en UTF-8. Entrez une chaîne, choisissez le mode composant ou URI complet et copiez le résultat codé dans une chaîne de requête, un segment de chemin ou une cible de redirection.

Les personnages déjà présents dans l'ensemble non réservé passent inchangés. Tout le reste devient des séquences %HH en mode composant. L'encodage est réversible lorsque les mêmes règles sont utilisées lors du décodage ; le mélange de signes plus d'encodage de formulaire avec le style de chemin « %20 » est la source habituelle d'allers-retours interrompus.

Décoder une chaîne codée en pourcentage

Le décodage trouve chaque « % » suivi de deux chiffres hexadécimaux, convertit cette paire en octet et reconstruit le texte original avec l'encodage de caractères sélectionné. Un « % » isolé ou un « % » avec des chiffres non hexadécimaux est une erreur. Les signes plus peuvent éventuellement être traités comme des espaces lorsque l'entrée provient des corps application/x-www-form-urlencoded.

L'encodage imbriqué apparaît lorsqu'une valeur a été codée deux fois. Le décodage une fois peut toujours laisser des séquences « %25 » qui représentent un pourcentage littéral. Décodez à nouveau uniquement lorsque cette deuxième couche était intentionnelle ; le double décodage aveugle corrompt les données qui contenaient un vrai caractère %.

Comprendre les caractères réservés et non réservés

La RFC 3986 divise l'ASCII en caractères non réservés qui n'ont jamais besoin d'être codés dans un URI et en caractères réservés qui portent une signification structurelle telle que des délimiteurs. Les lettres, chiffres et -_.~ non réservés restent littéraux. Les marques réservées telles que /, ? et & doivent être codées en pourcentage lorsqu'elles apparaissent sous forme de données plutôt que sous forme de syntaxe encadrant l'URL.

Sans réserve : A à Z, a à z, 0 à 9, trait d'union -, trait de soulignement _, point ., tilde ~

Réservé (gen-delims) : `: /?

Réservé (sous-délimiteurs) :  ! $ & ' ( ) * + , ; =

Les caractères non réservés restent littéraux. Les caractères réservés doivent être codés lorsqu'ils apparaissent sous forme de données plutôt que de délimiteurs. Un point d'interrogation à l'intérieur d'une valeur de paramètre correspond à des données ; un point d'interrogation qui démarre la chaîne de requête est la structure. La sélection de mode permet à la calculatrice de savoir quel rôle joue chaque personnage.

Encoder une URL entière plutôt qu'un seul paramètre

L'encodage URI complet, similaire à JavaScript « encodeURI », laisse les caractères structurels seuls afin que « https:// » et les barres obliques de chemin survivent. L'encodage des composants, similaire à « encodeURIComponent », encode ces caractères afin qu'une valeur puisse rester à l'intérieur d'un paramètre sans casser l'URL environnante. Choisir le mauvais mode détruit un lien ou laisse des délimiteurs qui divisent incorrectement la requête.

Input	Full-URI style	Component style
https://example.com/a b	https://example.com/a%20b	https%3A%2F%2Fexample.com%2Fa%20b
red&blue	red&blue	red%26blue
a=b	a=b	a%3Db

Encoder une URL entière en mode composant la détruit en tant que lien : le schéma deux-points et les barres obliques deviennent %3A et %2F. L'encodage d'un seul paramètre avec le mode URI complet laisse & et = intacts, ce qui divise la requête de manière incorrecte. Choisissez le mode qui correspond à l'emplacement que la chaîne occupera.

Encoder une barre oblique et un point d'interrogation

La chaîne de luminaire / et ? en mode composant devient %2F%20and%20%3F. La barre oblique et le point d'interrogation sont des délimiteurs réservés traités ici comme du texte de charge utile, chacun étant donc échappé. Les espaces deviennent « %20 », tandis que les lettres dans « et » ne sont pas réservées et passent inchangées de gauche à droite à travers la chaîne.

Character	Reason	Encoded
/	reserved path delimiter	%2F
space	not unreserved	%20
a, n, d	unreserved letters	unchanged
?	reserved query delimiter	%3F

Parcourez la chaîne de gauche à droite : encodez /, encodez l'espace, passez et, encodez l'espace, encodez ?. Le résultat %2F%20and%20%3F peut être placé en toute sécurité dans un paramètre de requête nommé, par exemple, q. L'utilisation du mode URI complet sur la même chaîne laisserait / et ? littéraux, ce qui n'est correct que lorsque ces caractères sont considérés comme une structure plutôt que comme un texte de charge utile.

Comprendre %20 par rapport au signe plus

Un espace est codé sous la forme « %20 » dans les chemins URI et dans les chaînes de requête modernes qui suivent la RFC 3986. Les formulaires HTML qui sont soumis sous la forme « application/x-www-form-urlencoded » encodent historiquement les espaces sous la forme « + » à la place. Les deux conventions apparaissent dans le trafic de production, et les traiter comme identiques est le bug de codage spatial le plus courant lors du décodage d’entrées mixtes.

Context	Space encoding
Path segment	%20
RFC 3986 query	%20
Form body / legacy query	+

Les données de connexion littérales plus doivent être codées comme « %2B », sinon un décodeur de formulaire les traitera comme un espace. La calculatrice indique quelle convention d'espace est active afin qu'un « + » décodé ne soit pas confondu avec un caractère plus lorsque le mode formulaire est activé, et qu'un « %20 » ne soit pas rejeté lorsque le mode chemin est activé.

Décomposer une URL en plusieurs parties

Une URL typique a un schéma, un hôte, un port facultatif, un chemin, une chaîne de requête et un fragment, et les règles de codage diffèrent selon les parties. Les délimiteurs structurels tels que ://, /, ?, &, = et # restent littéraux lorsqu'ils encadrent l'adresse.

Les noms de paramètres, les valeurs de paramètres et les segments de chemin qui transportent des données sont codés individuellement en mode composant avant que ces délimiteurs ne les rejoignent.

https://example.com:443/search?q=a%20b&lang=en#top
└─┬─┘   └─────┬─────┘ └─┬──┘ └───────┬───────┘ └┬┘
scheme       host     path        query      fragment

Part	Role
Scheme	Protocol, such as https
Host	Domain or IP, with optional port
Path	Resource location, slash-separated
Query	Parameter list after ?, joined by &
Fragment	Client-side location after #, not sent to the server in the request URI the same way

Encodez les noms et les valeurs des paramètres individuellement en mode composant, puis joignez-les avec les littéraux & et =. Encodez les segments de chemin individuellement s'ils contiennent des espaces ou des caractères réservés, en conservant les barres obliques qui séparent les segments littéraux.

Lire le tableau d'encodage des caractères

Le tableau ci-dessous répertorie les caractères réservés et dangereux courants avec leurs formes en pourcentage sous le codage d'octets UTF-8. Un espace devient « %20 », une esperluette « %26 » et un hachage « %23 ». Les caractères non-ASCII s'étendent en plusieurs unités « %HH » car chaque octet UTF-8 est codé séparément plutôt que comme un seul glyphe abstrait.

Char	Percent	Notes
space	%20	Or + in form encoding
!	%21
#	%23	Fragment delimiter
$	%24
&	%26	Query pair delimiter
'	%27
(	%28
)	%29
+	%2B	Literal plus
,	%2C
/	%2F	Path delimiter
:	%3A	Scheme / host separator
;	%3B
=	%3D	Parameter assignment
?	%3F	Query start
@	%40	Userinfo separator
[	%5B
]	%5D

Le texte non-ASCII est d'abord exprimé en octets UTF-8, puis chaque octet est codé en pourcentage. Un seul caractère peut donc s'étendre en deux ou trois unités %HH. Des analyses approfondies du codage de caractères pour Shift JIS et des ensembles hérités similaires en direct avec l'outil Base64 ; cette page renvoie plutôt que de répéter ce catalogue.

Questions fréquemment posées

Qu’est-ce que le codage en pourcentage ?

Le codage en pourcentage remplace un octet par un « % » suivi de deux chiffres hexadécimaux de la valeur de cet octet. Il permet aux caractères réservés et non-ASCII de voyager dans les URL sans être lus comme syntaxe. Le décodage inverse la substitution.

Quand faut-il utiliser le codage des composants ?

Utilisez le codage de composant pour un nom ou une valeur de paramètre unique, un segment de chemin constitué de données pures ou toute chaîne qui sera insérée à côté des délimiteurs structurels. Il code /, ?, & et = afin qu'ils ne puissent pas diviser l'URL.

Quand faut-il utiliser le codage URI complet ?

Utilisez le codage URI complet lorsque l'entrée est déjà une URL complète et que seuls les caractères illégaux tels que les espaces doivent changer. Les deux-points et les barres obliques structurelles restent littéraux, le résultat reste donc une adresse cliquable.

Pourquoi / et ? deviennent %2F%20and%20%3F ?

En mode composant, la barre oblique et le point d'interrogation sont traités comme des données, ils sont donc codés en %2F et %3F. Les espaces deviennent %20. Les lettres dans « et » ne sont pas réservées et restent telles quelles.

Est-ce que + est identique à %20 ?

Non. %20 est le codage RFC 3986 pour un espace. + signifie un espace uniquement dans les données application/x-www-form-urlencoded. Un plus littéral doit être « %2B », sinon les décodeurs de formulaire le transformeront en espace.

Quels caractères n’ont jamais besoin d’être codés ?

L'ensemble non réservé : lettres, chiffres, trait d'union, trait de soulignement, point et tilde. Ces caractères restent littéraux dans les deux modes. Les coder fonctionne toujours mais ajoute une longueur inutile.

Comment les caractères non-ASCII sont-ils codés ?

Ils sont d'abord convertis en octets UTF-8, puis chaque octet est codé en pourcentage. Un caractère visible peut devenir plusieurs séquences %HH. Le décodage doit utiliser UTF-8 pour reconstruire le texte original.

Le décodage deux fois corrige-t-il une URL cassée ?

Seulement si la valeur a été délibérément codée deux fois. Sinon, la deuxième passe corrompt les séquences littérales % qui faisaient partie des données. Décodez une fois, inspectez et décodez à nouveau uniquement lorsque les modèles %25 affichent une deuxième couche.

Est-ce la même chose que Base64 ?

Non. Le codage en pourcentage échappe aux caractères pour les URI. Base64 mappe des octets arbitraires sur un alphabet de 64 caractères pour le transport dans les protocoles texte. Utilisez chacun pour son propre travail.

Les URL collées sont-elles téléchargées ?

Non. L’encodage et le décodage s’exécutent uniquement dans le navigateur. Les chaînes de requête contenant des jetons ou des fragments de session ne sont pas transmises à un serveur par cet outil.

Résumé

Encoder et décoder URL encode et décode en pourcentage le texte selon les règles RFC 3986, avec des modes séparés pour les URI complets et les composants individuels. Le luminaire / et ? devient %2F%20and%20%3F en mode composant. Les espaces utilisent « %20 » dans les contextes URI et peuvent utiliser « + » dans l'encodage de formulaire, ce qui est une convention différente.

Les caractères réservés ne conservent leur signification que lorsqu'ils restent littéraux en tant que structure ; codez-les lorsqu’ils sont en charge utile. Tout le travail reste sur l'appareil.