Pourquoi une URL doit être encodée
Une URL ne peut contenir qu'un jeu restreint de caractères. Tout le reste — espaces,
accents, esperluettes, dièses — doit être remplacé par sa forme
percent-encoded : le caractère est converti en ses octets UTF-8, chacun écrit
en hexadécimal et précédé d'un %. C'est la règle posée par la RFC 3986.
Sans cet encodage, un paramètre qui contient une esperluette coupe l'URL en deux et le serveur reçoit des données tronquées. C'est une source classique de bugs difficiles à reproduire.
Les caractères qu'il faut absolument encoder
&→%26— sépare les paramètres. Non encodé, il en crée un nouveau.#→%23— démarre le fragment. Tout ce qui suit n'est jamais envoyé au serveur.?→%3F,=→%3D,/→%2F— structurent l'URL.+→%2B— sinon il peut être relu comme une espace.- Espace →
%20dans un chemin,+dans une chaîne de requête de formulaire.
Les pièges qui font perdre du temps
Le double encodage. Encoder une URL déjà encodée transforme chaque
% en %25 : %20 devient %2520. Le
serveur reçoit alors un littéral au lieu d'une espace. Si vous voyez des %25
en série dans vos journaux, c'est ça.
Encoder l'URL entière au lieu du paramètre. On n'encode pas
https:// ni les slashs de la structure : on encode la valeur d'un
paramètre. Encoder l'adresse complète la rend inutilisable.
Les accents dans les slugs. Un « é » devient %C3%A9, soit
six caractères pour une lettre. C'est valide, mais illisible dans un partage et pénible
dans les statistiques : mieux vaut des slugs sans accents.