Outils de développement · Encodeur et décodeur d'URL
URIError : URI mal formé – pourquoi decodeURIComponent est lancé et comment y remédier
· Comment ça marche
encodage d'URL javascript gestion des erreurs format de fichier
decodeURIComponent est lancé lorsqu'un signe de pourcentage n'est pas suivi de deux chiffres hexadécimaux ou lorsque les octets décodés ne sont pas valides UTF-8. Cet article montre les entrées qui le déclenchent et comment le décoder de manière défensive.
Le signe de pourcentage qui s'est écrasé - pourquoi "100% off" interrompt decodeURIComponent
Un formulaire collecte le code de réduction "100 % de réduction". JavaScript transmet cela à decodeURIComponent dans un décodeur URL. La fonction renvoie URIError : URI mal formé. Le signe pourcentage n’est pas suivi de deux chiffres hexadécimaux. Cela viole complètement les règles de codage en pourcentage. decodeURIComponent s'attend à ce que chaque % démarre un triplet comme %20 ou %C3. Un % isolé est une erreur de syntaxe qui arrête immédiatement l'exécution et génère une erreur.
La détection de cette erreur en toute sécurité empêche complètement le plantage de l'application. Les URL proviennent des entrées des utilisateurs, des redirections, des codes QR et des e-mails. Les fautes de frappe arrivent fréquemment. Un rapport de crash avec URIError vous indique où enquêter rapidement. Le décodage défensif maintient les applications en cours d'exécution et les journaux d'erreurs deviennent utiles pour le débogage.
Deux types d'échec : échappements hexadécimaux mal formés et séquences d'octets UTF-8 non valides
decodeURIComponent est lancé dans exactement deux situations. Premièrement : une séquence d'échappement mal formée. Un pourcentage non suivi de deux chiffres hexadécimaux (0-9, A-F, a-f). Exemples : %ZZ, %2, %2g. Deuxièmement : un triplet valide comme le décodage %E9 en octets UTF-8 invalides. La première est une erreur de format. La seconde est une erreur sémantique. Les deux lancent et arrêtent immédiatement l'exécution.
UTF-8 a des règles strictes concernant les séquences d'octets. Les octets 0x80 à 0xFF apparaissent uniquement dans les séquences multi-octets. Un seul %E9 ne peut pas être valide UTF-8 seul. Cet octet orphelin déclenche une erreur. Les erreurs de format sont évidentes. Les erreurs sémantiques sont subtiles mais tout aussi réelles. Les deux cas nécessitent la gestion de try/catch dans le code de production.
Codage sur un seul octet hérité – lorsque %E9 seul est lancé mais que %C3%A9 survit
La confusion vient de l'historique des normes Web. Les anciennes pages utilisaient Latin-1 au lieu de UTF-8. En latin-1, %E9 représenté é. Les navigateurs modernes utilisent exclusivement UTF-8. UTF-8 code é comme %C3%A9. Les décodeurs modernes attendent UTF-8 et rejettent %E9 comme étant mal formé. C'est un comportement correct. L'erreur signale un problème avec les données sources.
Consensus moderne : UTF-8 partout. La norme URL spécifie UTF-8. Tous les navigateurs actuels utilisent UTF-8. Si vous rencontrez %E9 sur d'anciens systèmes, détectez l'erreur et revenez à la chaîne brute. Ne décodez pas en Latin-1 dans le code moderne. Recherchez d’où proviennent les données.
Trois entrées, trois messages d'erreur : comment les moteurs diffèrent sur la même chaîne brisée
Les moteurs de navigation rejettent systématiquement les entrées mal formées, mais les erreurs de mots différemment. Chrome signale "URI mal formé". Firefox signale une « séquence URI mal formée ». Safari signale « impossible de convertir un élément défini en objet ». Les trois moteurs rejettent une entrée identique. La formulation exacte des messages n’est pas standardisée entre les différents moteurs ou versions. Ne vous fiez jamais au texte d’erreur pour guider la logique du code.
Ne faites jamais correspondre une chaîne à un message d'erreur pour les décisions du programme. Attrapez toujours URIError par type. La fonction decodeUrl encapsule decodeURIComponent et fournit un code cohérent INVALID_PERCENT_ENCODING. Cela désigne la position exacte du problème. Il fonctionne sur tous les temps d'exécution car il ne dépend pas des variations de formulation du moteur. Cette approche est plus fiable et maintenable.
Lire l'exception en toute sécurité - essayez la validation /catch, et les modèles de secours
Modèle défensif le plus simple : enveloppez decodeURIComponent dans try/catch. S'il est lancé, utilisez une chaîne brute ou un caractère de remplacement. Cela empêche les entrées mal formées de planter. Pour les valeurs de requête, affichez le formulaire codé en URL. Pour le texte destiné à l’utilisateur, insérez un caractère de remplacement. Cela empêche les mauvaises entrées de casser les applications et maintient la stabilité.
Pré-validez avec des expressions régulières pour la vitesse et la sécurité. Vérifiez que l'entrée ne contient que des triplets %XX valides avant le décodage. Le modèle /%[0-9A-Fa-f]{2}/g intercepte les échappements valides ; tout ce qui ne correspond pas est invalide. Les erreurs de format échouent rapidement en cas de déchets évidents. Les erreurs UTF-8 doivent encore être essayées./catch. Ensemble, cela fournit une protection défensive complète contre les erreurs.
Les échecs silencieux cachent les bugs : pourquoi le décodage aveugle est aussi risqué qu'un codage défectueux
Risque subtil : le décodeur ne lance pas mais produit silencieusement un texte erroné. L'ancien code utilisant une évasion obsolète laisse UTF-8 invalide en mémoire. Le texte s'affiche correctement à l'écran jusqu'à ce qu'il atteigne les systèmes qui valident strictement UTF-8. Le code moderne lance plutôt que corrompt silencieusement. Une exception est plus claire et plus sûre qu’une corruption silencieuse des données se propageant en aval.
Supposons que la saisie de l'utilisateur soit mal formée. Enveloppez toujours les appels. Enregistrez les erreurs avec l’entrée d’origine pour le débogage. Ne présumez jamais que chaque % est valide. Les fautes de frappe et les troncatures créent des échappements incomplets. Traitez-les comme des erreurs de données et non comme des erreurs de logique. Le code défensif survit gracieusement aux mauvaises entrées et maintient la fiabilité des systèmes.
Ce que les vrais outils ignorent : comportement du framework côté serveur et récupération des erreurs
Les frameworks de serveur gèrent les codages mal formés avec plus de clémence que les navigateurs. Ruby, Python et PHP proposent une configuration pour gérer les échappements non valides dans les URL. Certains caractères de remplacement sont automatiquement remplacés. D’autres abandonnent des octets en silence. Certains lancent des exceptions comme le fait JavaScript. Le comportement réel varie selon le framework et les paramètres de configuration choisis par les développeurs.
Cet article couvre uniquement le comportement JavaScript du navigateur. Si les valeurs arrivent des API du serveur, le serveur a déjà décodé ou ignoré les erreurs avant l'envoi. Les serveurs peuvent être plus indulgents que les clients. Lors de la rédaction de contrats API, précisez si les valeurs sont brutes ou pré-décodées. Les chaînes de requête d’URL doivent arriver codées en pourcentage ; JSON peut arriver pré-décodé.
Validez tôt : utilisez l'encodeur et le décodeur d'URL pour vérifier d'abord les chaînes suspectes.
Avant de transmettre des URL suspectes à decodeURIComponent, collez-les dans l'encodeur et le décodeur d'URL. L'outil affiche l'encodage exact, repère les échappements mal formés et explique les erreurs sans faire planter votre application. Testez avec %ZZ, %E9 et 100% pour voir différents échecs et leurs messages d'erreur exacts. Cela prend quelques secondes et renforce la confiance.
Validez tôt, détectez les erreurs avec élégance et enregistrez ce qui a échoué. Le décodeur défensif et l'outil de test maintiennent les applications en cours d'exécution et déboguables. L'encodeur et le décodeur d'URL transforment "URI mal formé" en informations exploitables que vous pouvez utiliser immédiatement. Appliquez ce modèle à vos propres décodeurs pour plus de résilience et de maintenabilité dans les environnements de production.