Encodeur et décodeur d'URL

encodeURIComponent encode un élément d'une URL et considère que cet élément est une donnée ; il échappe donc les délimiteurs qui donnent sa forme à une URL : la barre oblique, le point d'interrogation, le croisillon, l'esperluette, le signe égal, les deux-points, l'arobase, le signe plus et le signe dollar. encodeURI encode une URL déjà assemblée et considère que ces délimiteurs sont de la structure ; il les laisse donc tels quels. En pratique, vous voulez presque toujours la version composant, car vous construisez presque toujours une URL à partir d'éléments plutôt que de réparer une URL existante. Ne recourez à la version URL complète que lorsqu'on vous donne un lien complet contenant un espace ou un caractère accentué qu'il faut nettoyer.

Parce que deux normes ont été rédigées à des époques différentes et que les deux ont survécu. La RFC 3986, qui décrit les URL en général, encode un espace en %20 partout. Le format plus ancien d'envoi des formulaires HTML, application/x-www-form-urlencoded, encode un espace en signe plus, et c'est ce que les navigateurs envoient encore lorsqu'un formulaire est soumis et ce que produit URLSearchParams. Pratiquement tous les serveurs lisent correctement les deux dans une chaîne de requête, car les analyseurs de chaînes de requête connaissent les deux conventions. Les ennuis commencent quand une valeur encodée d'une façon est décodée de l'autre : décodez une valeur encodée en formulaire avec un simple décodeur pourcent, et un nom comme Anna Marie ressort sous la forme Anna+Marie. C'est pourquoi cette page affiche les deux lectures d'un décodage plutôt que d'en choisir une pour vous.

Cela signifie un espace encodé deux fois en pourcent. Un espace devient d'abord %20. Si ce %20 repasse ensuite dans un encodeur, le signe pourcentage lui-même est encodé en %25 et vous obtenez %2520. Voir %25 suivi de deux autres chiffres hexadécimaux n'importe où dans un lien est l'empreinte d'un double encodage. Cela arrive généralement quand un paramètre de redirection est construit en encodant une URL déjà encodée, ou quand une valeur traverse deux frameworks qui l'encodent chacun par excès de zèle. Collez-la ici en mode décodage et le nombre de couches vous dit exactement combien de passes annuler.

La RFC 3986 définit un ensemble non réservé qui n'a jamais besoin d'être échappé : de A à Z, de a à z, de 0 à 9, et les quatre signes trait d'union, point, tiret bas et tilde. Tout le reste relève de l'ensemble réservé, divisé en délimiteurs généraux (deux-points, barre oblique, point d'interrogation, croisillon, crochets, arobase) et sous-délimiteurs (point d'exclamation, dollar, esperluette, apostrophe, parenthèses, astérisque, plus, virgule, point-virgule, égal). Un caractère réservé est autorisé là où il joue son rôle structurel et doit être échappé là où il est une donnée. Au-delà, l'espace et les caractères guillemet double, inférieur à, supérieur à, pourcentage, barre oblique inversée, accent circonflexe, accent grave et les accolades ne peuvent jamais apparaître tels quels. Le tableau de référence de cette page les liste un par un avec la façon dont les quatre encodeurs les traitent.

Parce que l'encodage pourcent opère sur des octets, pas sur des caractères, et que les URL modernes transportent le texte en UTF-8. En UTF-8, la lettre e accent aigu occupe deux octets, C3 et A9, et s'encode donc en %C3%A9. Un caractère CJK occupe trois octets et devient trois triplets, et un emoji occupe quatre octets et devient quatre triplets, soit douze caractères pour un seul symbole visible. C'est pourquoi une chaîne encodée peut être plusieurs fois plus longue que le texte saisi, et pourquoi une limite de longueur mesurée en caractères se comporte différemment avant et après l'encodage. La vue des octets de cette page montre cette expansion caractère par caractère.

Non, et c'est l'erreur qui produit le plus de liens cassés. Faire passer une URL déjà correcte dans un encodeur transforme chaque caractère structurel en séquence d'échappement : les barres obliques deviennent %2F, le point d'interrogation devient %3F, et le signe pourcentage de toute séquence existante devient %25. Ce qui en sort n'est plus une URL, c'est une chaîne qui se trouve y ressembler. Si le lien fonctionne déjà, n'y touchez pas. Si un lien contient un espace brut ou un caractère accentué, l'encodage d'URL complète est le bon outil, car il les corrige sans toucher aux délimiteurs. Essayez l'exemple Déjà encodé en mode encodage pour voir exactement ce qu'un réencodage fait à un lien sain.

Le système de noms de domaine ne transporte qu'un ensemble restreint de caractères ASCII : un domaine écrit en arabe, en cyrillique, en grec, en chinois ou simplement avec un tréma allemand doit donc être traduit en ASCII avant de pouvoir être résolu. Cette traduction, c'est le punycode, et elle produit des libellés qui commencent par xn--. Le navigateur fait cette conversion sans rien dire, ce qui signifie que l'hôte que vous lisez et l'hôte réellement résolu sont deux chaînes différentes. Afficher les deux est une vérification de sécurité, pas une curiosité : une attaque par homographe fonctionne précisément parce qu'un nom construit avec des caractères qui se ressemblent se lit comme une marque familière tout en menant à tout autre chose. Cette page décode le punycode en Unicode dans le navigateur, puisqu'il n'existe aucun moyen intégré de faire la conversion inverse.

Considérez tout identifiant apparu dans une URL comme déjà divulgué. La partie informations utilisateur d'une URL, tout ce qui précède l'arobase, est envoyée en clair dans la ligne de requête avec les anciens protocoles, est écrite dans les journaux d'accès du serveur et dans ceux des proxys, est enregistrée dans l'historique du navigateur et a longtemps fuité via l'en-tête Referer envoyé au site suivant que vous visitez. Certains navigateurs la suppriment ou avertissent désormais, mais les copies déjà écrites dans les journaux ne disparaissent pas. Si un lien contenant des identifiants a été partagé, collé dans un ticket ou ouvert depuis un e-mail, changez le mot de passe plutôt que de compter sur le fait que le lien reste privé. Cette page signale les identifiants chaque fois qu'elle en trouve et masque le mot de passe au lieu de l'afficher.

Il lève une URIError chaque fois que l'entrée n'est pas une chaîne UTF-8 encodée en pourcent valide, ce qui couvre un signe pourcentage suivi de rien, une paire non hexadécimale comme %ZZ, un caractère multioctet tronqué comme un %C3 isolé, un encodage trop long et une moitié de paire de substitution échappée. L'erreur n'indique ni la position ni la cause, si bien qu'en production elle se transforme généralement en page blanche ou en erreur 500. Dans votre propre code, la solution est d'encadrer l'appel et de gérer l'échec explicitement au lieu de le laisser remonter. Pendant le débogage, la solution est de coller la valeur ici : le décodeur de cette page parcourt la chaîne à la main et vous dit quel caractère est en cause et pourquoi, au lieu de refuser de le dire.

Non. Tous les encodeurs, le décodeur, l'analyseur d'URL, le décodeur punycode et l'éditeur de requête s'exécutent dans cet onglet en JavaScript simple, et aucun lien n'est jamais chargé. C'est plus important ici que pour la plupart des outils, car les URL que l'on apporte à un décodeur sont justement celles qui contiennent des jetons de session, des liens de téléchargement signés, des paramètres de réinitialisation de mot de passe et des noms d'hôte internes. La saisie est limitée à 100,000 caractères, bien au-delà de toute URL utilisable, et rien n'est conservé d'une visite à l'autre.