Pourquoi ton URL a cassé (Et comment y remédier)
L'encodage d'URL n'est pas optionnel. Voici pourquoi les caractères spéciaux causent des problèmes et quoi faire à ce sujet.
Tu colles une URL dans un email. Quelqu'un clique dessus. Il obtient une 404.
L'URL avait l'air bien. Mais quelque part entre ton navigateur et le leur, un espace est devenu %20, un ampersand a disparu, ou un signe plus s'est transformé en quelque chose d'autre entièrement.
L'encodage d'URL existe parce que les URLs ne peuvent contenir que certains caractères. Tout le reste doit être traduit.
Le problème avec les caractères spéciaux
Les URLs ont été conçues aux débuts d'internet avec un jeu de caractères limité. Ceux-ci sont sûrs :
A-Z a-z 0-9 - _ . ~
Tout le reste ? Potentiellement problématique.
Les espaces deviennent %20 ou + selon le contexte. Une URL avec un espace littéral cassera.
Les ampersands (&) séparent les paramètres de requête. Si tes données contiennent un ampersand, l'analyseur d'URL pense qu'il commence un nouveau paramètre.
Les points d'interrogation (?) signalent le début des chaînes de requête. Un dans tes données embrouille tout.
Quand l'encodage se fait automatiquement
Les navigateurs encodent les URLs quand tu les tapes. C'est pourquoi tu peux coller "new york restaurants" dans Google et ça fonctionne.
Mais les systèmes automatisés ne le font souvent pas. APIs, scripts, clients email—ils pourraient passer ton URL exactement telle qu'écrite. Si elle contient des caractères non sûrs, elle casse.
Le piège du double encodage
Voilà où ça devient ennuyeux.
Tu encodes une URL. Puis tu la mets dans une autre URL comme paramètre. Le système l'encode à nouveau. Maintenant %20 devient %2520.
Quand décodé, tu obtiens %20 au lieu d'un espace.
Ça arrive constamment avec les URLs de redirection, paramètres de tracking et callbacks OAuth. Si ton URL a l'air mutilée avec des signes pourcent supplémentaires, vérifie le double encodage.
Erreurs d'encodage courantes
Encoder l'URL entière. Ne le fais pas. Encode seulement les valeurs, pas la structure. https:// ne devrait pas devenir https%3A%2F%2F.
Oublier le signe plus. Dans les chaînes de requête, + signifie espace. Si tes données ont un signe plus littéral, il a besoin d'encodage ou il disparaît.
Supposer que l'encodage est idempotent. Encoder une chaîne déjà encodée produit une sortie différente. Vérifie si quelque chose est encodé avant de l'encoder.
Exemples pratiques
Une requête de recherche avec des espaces :
Avant : https://example.com/search?q=new york pizza
Après : https://example.com/search?q=new%20york%20pizza
Une URL de callback comme paramètre :
callback = https://mysite.com/auth?token=abc
Encodé : https%3A%2F%2Fmysite.com%2Fauth%3Ftoken%3Dabc
Une adresse email dans une URL :
Avant : user+tag@example.com
Après : user%2Btag%40example.com
Déboguer les problèmes d'URL
Vérifie la vraie requête. Les outils dev du navigateur te montrent ce qui est envoyé. Compare-le à ce que tu attendais.
Décode et inspecte. Si une URL ne fonctionne pas, décode-la pour voir ce que le serveur reçoit réellement.
Teste avec des caractères spéciaux. Inclus des espaces, ampersands et signes plus dans tes données de test. Si ça fonctionne avec "test" mais échoue avec "test & verify", tu as un problème d'encodage.
L'encodage d'URL est une de ces choses qui fonctionne invisiblement jusqu'à ce que ça ne fonctionne plus. Comprendre les règles t'aide à déboguer plus vite quand les URLs cassent mystérieusement.