Outils de développement · Encodeur et décodeur d'URL
encodeURI vs encodeURIComponent : quels caractères chacun laisse seul
· Comment ça marche
encodage d'URL javascript workflow de développeur
Les deux fonctions JavaScript diffèrent d'exactement onze caractères, et choisir la mauvaise soit rompt une URL, soit ne parvient pas à échapper une valeur. Cet article détaille les ensembles et donne une règle dont vous vous souviendrez.
La recherche qui a tout renvoyé parce que le & dans 'R&D' a divisé la requête - un bug concret provenant d'une mauvaise fonction
Une recherche de R&D peut accidentellement renvoyer des résultats pour R si le code construit ?q=R&D à la main. L'esperluette est un séparateur entre les paramètres de requête ; il n'est pas conservé dans le cadre de q sauf si vous codez la valeur. Choisir encodeURI pour ce petit morceau est une erreur, pas un bug du serveur. L'option la plus sûre dans le code d'application est souvent URLSearchParams, mais la compréhension des deux primitives JavaScript facilite grandement le débogage du code existant.
Ce que les deux fonctions partagent : l'ensemble sans réserve qu'elles ne touchent jamais et le codage en pourcentage UTF-8 qu'elles appliquent toutes les deux.
Les deux méthodes laissent les lettres ASCII, les chiffres et la ponctuation sans réserve - _ . ! ~ * ' ( ) intact selon les règles d'encodage de JavaScript. Ils convertissent les caractères non-ASCII en UTF-8 bytes avant d'écrire des triplets de pourcentage : é devient %C3%A9, pas un seul Latin-1 byte. Ils codent également un espace en %20. Le codage en pourcentage consiste à préserver la structure d'un URI ; il ne s'agit pas d'un échappement HTML, d'une validation d'entrée ou d'une protection contre les scripts malveillants sur la page de réception.
Les onze caractères que seul encodeURI préserve — ; , /? : @ & = + $ # et pourquoi chacun a une signification structurelle dans une URL
encodeURI conserve en outre onze caractères structurels qui encodeURIComponent code : ; , /? : @ & = + $ #. Pour une adresse complète, laisser la barre oblique et le point d'interrogation seuls préserve son chemin et sa syntaxe de requête. Pour une valeur de requête, laisser & ou = passer modifierait la liste des paramètres, tandis qu'un # sans échappement peut démarrer un fragment. Les fonctions diffèrent précisément parce que l’une est destinée à une adresse entière et l’autre à un composant à l’intérieur de cette adresse.
Une règle qui s'applique : les valeurs obtiennent encodeURIComponent, les URL complètes obtiennent encodeURI - et pourquoi les "URL complètes" sont plus rares qu'il n'y paraît
Les valeurs obtiennent presque toujours encodeURIComponent ; les adresses complètes et déjà structurées sont le cas le moins courant pour encodeURI. Pour une URL que vous construisez par programme, utilisez l'API d'URL pour gérer les paramètres de chemin et de recherche au lieu de concaténer un mélange d'éléments codés et bruts. N'encodez pas une URL entière avec encodeURIComponent et attendez-vous ensuite à ce que les barres obliques et les deux-points continuent à se comporter comme des séparateurs. À l’inverse, n’alimentez pas le terme de requête d’un utilisateur via encodeURI et laissez son esperluette active.
Exemple concret : la même chaîne dans les deux fonctions – un tableau de sorties pour une valeur avec des espaces, &, / et un accent
Prenez R&D / café comme valeur de requête. encodeURIComponent renvoie R%26D%20%2F%20caf%C3%A9, en protégeant l'esperluette et la barre oblique. encodeURI renvoie R&D%20/%20caf%C3%A9, en préservant la ponctuation structurelle ; un préfixe naïf ?q= créerait désormais un délimiteur involontaire. Les deux codent l’espace et l’accent, de sorte qu’un test utilisant uniquement « hello world » manque la distinction importante. Comparez les chaînes générées dans ToolAcre, puis collez-les dans un analyseur d'URL et vérifiez combien de paramètres de requête apparaissent.
Erreurs courantes : encodage d'une URL complète avec encodeURIComponent et décodage avec la mauvaise contrepartie
L'encodage d'une URL complète en tant que composant produit %3A%2F%2F là où un consommateur attendait ://. Décoder une adresse entière avant de la valider peut réintroduire des séparateurs réservés avec de nouvelles significations. Évitez également de doubler le codage d'une valeur contenant déjà %26 : le signe de pourcentage lui-même peut devenir %25, donc une deuxième couche de décodage peut à nouveau changer de sens. Associez encodeURIComponent à decodeURIComponent pour un composant et traitez les pourcentages d'échappement mal formés comme des erreurs d'entrée.
Ce que cela ne couvre pas : encodage de formulaire avec + et création d'URL avec URLSearchParams
Le codage des requêtes de formulaire HTML utilise un signe plus pour un espace dans application/x-www-form-urlencoded, qui est distinct de la sortie %20 de ces deux fonctions. URLSearchParams gère ces règles de formulaire pour vous. Cet article ne couvre pas la normalisation du chemin, la conversion du nom d'hôte Unicode ou la décision de savoir si une URL décodée peut être demandée en toute sécurité ; Le codage d'URL est une étape de représentation et non une politique d'autorisation.
À retenir : encodez les parties, pas le tout – comment l'encodeur et le décodeur d'URL affichent les deux modes afin que vous puissiez voir la différence sur votre propre entrée
La limite mémorisable est celle des parties par rapport au tout : une valeur de paramètre est une partie, utilisez donc encodeURIComponent ou URLSearchParams. L'encodeur et le décodeur d'URL affichent les deux fonctions du navigateur pour la même chaîne et conservent l'expérience locale. Testez l'entrée contenant &, =, #, une barre oblique et un accent avant de décider que deux encodeurs sont interchangeables.