Outils de développement · Encodeur et décodeur d'URL
Ce que le constructeur d'URL encode pour vous : les ensembles d'encodage en pourcentage du navigateur
· Comment ça marche
encodage d'URL javascript quoi API Web
L'API URL encode silencieusement certains caractères et en laisse d'autres seuls, en fonction de la partie de l'URL dans laquelle ils atterrissent. Cet article explique les jeux d'encodage WHATWG et comment prédire la sortie.
L'espace devenu %20 et le | qui est resté - un cas concret où new URL() a partiellement codé un chemin
Lorsque la nouvelle URL ("https://example.com/hello world") s'exécute, l'espace devient %20 silencieusement. Mais new URL("https://example.com/hello|world") laisse le tube intact. Cette différence n'est pas aléatoire. La norme d'URL WHATWG définit des jeux de caractères distincts à coder pour chaque composant d'URL : le chemin, la requête, le fragment et les informations utilisateur ont chacun leurs propres règles. Comprendre ces ensembles signifie prédire ce que fera le constructeur.
L'espace nécessite un codage en pourcentage car il n'est pas sécurisé sur HTTP et altère la lisibilité. Le tube est différent : il ne s'agit pas d'un caractère réservé qui divise la structure, donc le navigateur le laisse tranquille. La frontière entre sécurité et lisibilité est tracée par WHATWG, et non par des conjectures. Le test de « hello world » montre l'encodage ; tester "hello|world" révèle les limites de chaque partie de l'URL.
Une URL, plusieurs jeux d'encodage : le chemin, la requête, le fragment et les informations utilisateur ont chacun leur propre liste de caractères à échapper.
Une URL contient plusieurs régions, chacune avec ses propres règles de codage. Le chemin suit un ensemble, interroge un autre, fragmente un troisième, userinfo un quatrième. Un espace devient %20 dans le chemin et la requête. Un signe égal reste dans la requête, où il sépare les clés et les valeurs, mais encodeURIComponent le transforme en %3D. Le constructeur d'URL connaît son contexte et applique les bonnes règles pour chaque partie.
Les jeux d'encodages sont précis et petits. Path a sa propre liste de caractères ; la requête a une liste similaire mais différente. Cela reflète quels personnages ont une signification structurelle. Une barre oblique divise les segments de chemin, donc encodeURIComponent le code en %2F. Dans le fragment, une barre oblique peut exister sans rien casser. Comprendre les règles WHATWG signifie prédire la sortie sans exécuter de code.
Pourquoi le codage en pourcentage est à sens unique : ce qui reste codé le reste
Le constructeur d'URL effectue une normalisation unidirectionnelle. Transmettez "%20" à la nouvelle URL et cela produit %20 inchangé. Le constructeur le reconnaît comme déjà codé et le laisse tranquille. C'est pourquoi le double encodage est important : encoder une fois, passer par le constructeur et les bâtons d'encodage. Le constructeur ne décode pas, ne réinterprète pas et ne réencode pas ; il lit en avant.
Cette propriété unidirectionnelle affecte les applications qui considèrent URL.href comme canonique. Si vous concaténez l'entrée utilisateur avec votre chemin, l'entrée est normalisée mais pas décodée. Une valeur telle que « mon+fichier » reste telle quelle ou devient « mon%2Bfichier » dans certains contextes. Le code ultérieur utilisant decodeURIComponent peut lire plus sous forme d'espace s'il provient des données du formulaire. Le constructeur normalise une fois ; après cela, votre valeur est fixe.
Exemple pratique : transmettre la même chaîne désordonnée via new URL() et lire href, pathname et searchParams – trois vues différentes
Prenez "hello world&foo=bar|test#anchor" et placez-le via une nouvelle URL avec différents composants. L'espace devient %20 partout. L'esperluette dans le chemin reste (aucune signification structurelle là-bas), mais dans la requête, elle reste également (sépare les paramètres, donc la normalisation perdrait la frontière entre "q=" et "foo=bar"). Le tuyau et le hachage se comportent différemment selon l'emplacement.
La lecture de href, pathname et searchParams affiche trois vues différentes. pathname affiche le chemin codé sans schéma, hôte ou requête. searchParams donne des paramètres décodés, donc "hello+world" à partir des données du formulaire devient un espace. La propriété de recherche préserve la chaîne littérale. href affiche l'URL normalisée complète. Ceux-ci coexistent sur un même objet ; lequel utiliser dépend de votre prochaine étape.
URLSearchParams et la règle d'encodage de formulaire - pourquoi il produit + pour les espaces alors que le chemin produit %20
URLSearchParams applique le codage de formulaire : l'espace devient un plus, et non %20. new URLSearchParams({q: "hello world"}) produit "q=hello+world", et non "q=hello%20world". Il s’agit de la règle d’application historique/x-www-form-urlencoded. Mais si vous transmettez cette chaîne sous forme de requête brute à une nouvelle URL, le plus reste plus ; seul URLSearchParams le décode sous forme d'espace. Le constructeur est fidèle à ce qu'il voit.
Cette différence de signe plus provoque des bugs courants. Une URL de la barre d'adresse utilise %20 pour les espaces. Les données du formulaire utilisent plus. Si vous décodez avec decodeURIComponent (qui lit littéralement plus) au lieu de URLSearchParams.get, les espaces deviennent des caractères plus. L'encodeur et le décodeur d'URL affichent les deux : collez "hello+world" et comparez les modes de composant et de formulaire pour voir où l'espace apparaît.
Comparaison avec encodeURI - où les deux concordent et où ils divergent
Le constructeur d'URL et encodeURIComponent sont des outils différents. encodeURIComponent encode presque tout sauf les lettres, chiffres et - _ non réservés. ! ~ *' ( ). Cela ne suppose aucun contexte. Le constructeur d'URL analyse une URL réelle et applique les règles WHATWG par composant. encodeURIComponent transforme "hello/world" en "hello%2Fworld" ; la nouvelle URL considère les barres obliques comme séparateurs de chemin. Même entrée, sortie différente.
Utilisez encodeURIComponent lors de la création d'une URL en concaténant des éléments. Utilisez URLSearchParams ou le constructeur d'URL pour les URL complètes ou partielles. N'utilisez pas encodeURIComponent sur une URL entière ; vous allez détruire le schéma. Comparez le résultat avec l’intention. Le navigateur applique les opinions sur la structure des URL et la nouvelle URL les implémente. L'encodeur et le décodeur d'URL affichent les deux vues côte à côte.
Ce que cela ne couvre pas : analyse d'hôte, IDNA et schémas spéciaux ou non spéciaux
La norme d'URL WHATWG est la source de vérité, même si sa lecture demande de la patience. Les jeux de codage sont définis dans des fragments d'algorithme, et non dans des listes simples. En pratique, la compréhension du principe compte plus que la mémorisation des ensembles. Le chemin autorise plus de caractères (les barres obliques sont structurelles) ; la requête a ses propres règles ; le fragment a le moins de restrictions (géré côté client, jamais envoyé aux serveurs). Chaque composant a ses propres règles ; savoir cela vous indique où chercher.
La normalisation et la validation sont des limites différentes. Le constructeur normalise : nettoie le codage en pourcentage, applique les règles des composants, donne une forme canonique. Il ne valide pas : les caractères invalides sont lancés, mais les hôtes vides sont acceptés. Le constructeur est strict sur le format mais indulgent sur l'interprétation. Pour une conformité exacte aux spécifications, lisez la section des octets codés en pourcentage de WHATWG. Pour la création quotidienne, utilisez URLSearchParams, l'API URL et des exemples réels.
À retenir : l'analyseur a des opinions – comment l'encodeur et le décodeur d'URL vous montrent le simple codage en pourcentage d'une valeur ou d'une adresse afin que vous puissiez la comparer avec ce que le navigateur a produit
Les fonctionnalités WHATWG non prises en charge ici incluent l'analyse de l'hôte avec la conversion IDNA (noms de domaine internationaux en ASCII) et la gestion des schémas spéciaux et non spéciaux. Fichier : les URL utilisent l'autorité d'une double barre oblique ; données : les URL ne le font pas. Le constructeur applique ces règles. La conversion des noms d'hôte et la détermination d'un statut spécial relèvent de la lecture des spécifications et non du codage en pourcentage. Cela est important lors de la création d’URL sur différents schémas.
Testez la construction de votre URL en comparant l'interprétation du navigateur avec les attentes. Créez avec une nouvelle URL, lisez les propriétés qui comptent : href pour le formulaire complet, pathname pour le chemin, recherche de requête brute, searchParams pour décodé. Si le résultat vous surprend, collez-le dans l'encodeur et le décodeur d'URL et suivez la transformation étape par étape. L'outil affiche une sortie normalisée ainsi qu'un encodage brut, révélant la différence. Comprendre les ensembles WHATWG signifie comprendre les choix du navigateur et comment les utiliser.