Encoder / Décoder une URL
Encodez ou décodez en pourcentage des URL et des paramètres de requête, modes sûr par composant et URI complète.
Chargement de Encoder / Décoder une URL… Si rien ne se passe, activez JavaScript.
L'encodage pour cent, communément appelé encodage d'URL, est le mécanisme défini dans le RFC 3986 pour représenter en toute sécurité des caractères arbitraires à l'intérieur d'un identifiant uniforme de ressource. Le système d'adressage d'internet a été conçu autour de l'ASCII, donc tout caractère hors d'un petit ensemble sûr (espaces, lettres accentuées, ponctuation, emoji ou binaire brut) doit être remplacé par un signe pour cent suivi de deux chiffres hexadécimaux représentant la valeur d'octet du caractère en UTF-8. Le schéma fait partie du web depuis que Tim Berners-Lee a défini les URL au CERN en 1990 et a été formellement normalisé dans le RFC 1738, plus tard remplacé par le RFC 3986 en 2005.
Exemples
hello world & co=1
hello%20world%20%26%20co%3D1
Encodage pour cent (encodeURIComponent) : l'espace devient %20.
hello world & co=1
hello+world+%26+co%3D1
Encodage de formulaire (application/x-www-form-urlencoded) : l'espace devient +.
Questions fréquentes
Mes données sont-elles téléversées vers un serveur ?
Quels caractères sont considérés comme « sûrs » et laissés non encodés ?
Quelle est la différence entre les deux modes ?
Pourquoi un espace devient-il parfois + et parfois %20 ?
Y a-t-il des caractères qui ne peuvent jamais apparaître dans une URL même encodés ?
Cet outil gère-t-il correctement l'Unicode et les emoji ?
Puis-je l'utiliser pour décoder une URL doublement encodée ?
L'encodage d'URL est-il identique à l'encodage des entités HTML ?
Quelle est la différence entre un URI et une URL ?
Pourquoi encoder une chaîne déjà encodée produit-il une sortie illisible ?
À propos de Encoder / Décoder une URL
L'encodage d'URL est incontournable dès que vous construisez ou analysez des adresses web par programmation. Les valeurs de chaîne de requête contenant des espaces, des esperluettes ou des signes égal casseraient l'analyse des paramètres si elles restaient non encodées. Les envois de formulaires utilisent par défaut application/x-www-form-urlencoded, qui encode tout en pourcentage et convertit les espaces en +. Les clients d'API REST doivent encoder les segments de chemin contenant des barres obliques ou des points d'interrogation pour que le serveur ne les interprète pas comme des caractères structurels. Les charges utiles de webhooks, les URI de redirection OAuth et les liens profonds reposent tous sur un encodage et un décodage soignés pour transmettre des données sans ambiguïté.
Cet outil gère l'encodage et le décodage pour cent entièrement dans votre navigateur. Il propose deux modes correspondant aux deux fonctions JavaScript standard. Le mode composant (équivalent à encodeURIComponent) est destiné aux valeurs individuelles (un terme de recherche, un nom de fichier, un paramètre OAuth) et échappe tout sauf les caractères non réservés A-Z, a-z, 0-9, trait d'union, tiret bas, point et tilde. Le mode URI complète (équivalent à encodeURI) préserve les caractères structurels d'une URL complète (deux-points, barre oblique, point d'interrogation, dièse, esperluette, égal) et est utile quand vous voulez normaliser une URL sans casser sa structure. Comme tout s'exécute localement, aucune saisie n'est jamais envoyée à un serveur.
Une erreur fréquente est d'encoder une URL entière avec encodeURIComponent : cela échappe les deux-points et les barres obliques, produisant une adresse cassée. Utilisez le mode composant uniquement sur les valeurs individuelles avant de les assembler en une URL. À l'inverse, oublier d'encoder des valeurs contenant & ou = dans les chaînes de requête conduit à des paramètres silencieusement scindés ou fusionnés du côté récepteur. Notez aussi que le caractère + signifie un espace uniquement à l'intérieur des corps application/x-www-form-urlencoded ; dans les segments de chemin, un + littéral doit être encodé pour cent en %2B.
D'où vient le nom de l'encodage pour cent
L'encodage pour cent tire son nom du signe pour cent (%) littéral qu'il utilise comme caractère d'échappement. Lorsque Tim Berners-Lee a défini la syntaxe des URL au CERN en 1990, il lui fallait un moyen de représenter des octets arbitraires de façon non ambiguë en texte ASCII. Il a choisi % parce qu'il était imprimable, rarement utilisé dans les identifiants et visuellement distinct, rendant les séquences encodées faciles à repérer d'un coup d'œil.
La spécification d'URL originale (RFC 1738, 1994) exigeait déjà l'encodage pour cent des caractères non sûrs, mais différents systèmes étaient en désaccord sur les caractères « non sûrs » et la gestion de l'Unicode. Il a fallu attendre 2005, et le RFC 3986, pour qu'un standard définitif émerge, accompagné d'un document complémentaire (RFC 3987) définissant les IRI (identifiants de ressource internationalisés), qui autorisent des caractères Unicode directement dans la syntaxe.
Aujourd'hui, pratiquement tous les langages de programmation livrent une fonction d'encodage d'URL dans leur bibliothèque standard, pourtant des différences subtiles subsistent : urlencode() de PHP encode les espaces en +, urllib.parse.quote() de Python utilise %20, et encodeURIComponent() de JavaScript suit le RFC 3986. Cette diversité explique pourquoi les intégrations d'API entre langages butent parfois sur des incohérences d'encodage : le même caractère peut paraître complètement différent selon la bibliothèque qui l'a sérialisé.