Outils de développement · Encodeur et décodeur d'URL
De la RFC 1738 à la norme URL : comment les règles de codage en pourcentage ont évolué
· Contexte
encodage d'URL historique-rfc normes Web
Les règles de caractères d'échappement dans les URL ont été réécrites plusieurs fois depuis 1994. Cet article fait suite aux RFC 1738, RFC 2396, RFC 3986 et à la norme d'URL WHATWG et explique ce qui a changé à chaque fois.
De la RFC 1738 à la norme URL : évolution des règles de codage en pourcentage
Tilde (~) illustre la façon dont les règles de codage changent au fil des générations et des déploiements de normes. RFC 1738 (1994) exigeait %7E partout ; RFC 2396 (1998) a déplacé le tilde vers non réservé, autorisant le non codé. RFC 3986 (2005) a confirmé le statut non réservé. Les anciennes URL avec %7E restent valides ; sortie des nouveaux constructeurs ~. L'évolution reflète les leçons de déploiement à mesure que le Web mûrit et que l'infrastructure est standardisée. La RFC 1738 était conservatrice car les premières infrastructures étaient hétérogènes et variées.
RFC 1738 a codifié le comportement du navigateur 1994. Déploiements standardisés sur UTF-8 ; les restrictions se sont révélées inutiles. Les normes ultérieures ont assoupli les restrictions de caractère. RFC 3986 permet un décodage sécurisé des caractères non réservés.
RFC 1738 (1994) : caractères « dangereux » et premières règles d'évasion — ce qui était considéré comme dangereux et pourquoi
RFC 1738 définissait les caractères « dangereux » comme ceux en conflit avec la syntaxe URI (espace, barre oblique), historiquement utilisés dans les protocoles (caractères de contrôle), ou que les systèmes ne pouvaient pas transmettre en toute sécurité. Liste conservatrice codée en pourcentage bien plus que nécessaire pour l’Internet moderne. De nombreux premiers systèmes sont antérieurs à la RFC ; cela codifiait leur comportement. Les personnages de contrôle étaient véritablement dangereux dans les protocoles ; les espaces étaient des problèmes de transmission pour les clients HTTP lisant à partir des lignes de commande. Les systèmes modernes gèrent ces cas avec plus de grâce grâce à un codage explicite.
Les tests par rapport à la RFC 1738 révèlent les attentes des anciens systèmes. Encodez un caractère de la spécification URL des années 1990 et comparez-le avec la RFC 3986 moderne. Les différences montrent ce qui s’est détendu. Ensemble sans réserve élargi au fil du temps. Le trait d’union, le point et le trait de soulignement étaient toujours sûrs. Tilde avait besoin du RFC 2396 pour devenir en sécurité. Une approche conservatrice signifiait une compatibilité ascendante. Les anciennes URL créées selon les règles RFC 1738 restent valides aujourd'hui. La normalisation dans la section 6 de la RFC 3986 permet de décoder en toute sécurité les caractères non réservés inutilement codés en pourcentage.
RFC 2396 (1998) — réservé versus non réservé, la syntaxe générique et le tilde réhabilités
RFC 2396 (1998) a clarifié les jeux de caractères de manière plus rigoureuse que la RFC 1738. Il a formalisé les caractères réservés servant la structure URI par rapport aux caractères non réservés comme données littérales. Développé sans réserve avec trait d'union, point, trait de soulignement et tilde. Il reconnaissait une syntaxe URI générique distincte des règles spécifiques au schéma. La RFC 2396 a introduit la distinction entre les gen-delims (:, /, ?, #, [, ], @) et les sous-delims (!, $, &, ', (, ), *, +, ,, ;, =). La dénomination clarifie les caractères réservés divisés en deux groupes avec des rôles structurels différents.
RFC 2396 a introduit des directives de normalisation spécifiant quels caractères codés en pourcentage pouvaient décoder sans changement de signification. Le décodage des caractères sans réserve se normalise. Bâtons d'encodage de caractères réservés. La RFC 3986 a encore simplifié la notation. Les normes maintiennent farouchement la rétrocompatibilité.
RFC 3986 (2005) — ! * ' ( ) passe aux sous-délimiteurs, les gen-delims sont nommés et les instructions de normalisation arrivent
RFC 3986 (2005) est une norme de référence moderne pour le codage en pourcentage. Il a conservé la distinction réservée/unreserved mais a simplifié la notation et ajouté des conseils de normalisation. Tilde s'est déplacé sans ambiguïté et sans réserve. Les caractères non réservés codés en pourcentage clarifiés standard peuvent être décodés sans changement de signification. La section 3 de la RFC 3986 décrit la syntaxe URI avec précision. La section 2 définit les catégories de caractères. La section 6 consacre les règles formelles à la normalisation syntaxique. La normalisation basée sur la comparaison considère les URI identiques si les formes normalisées correspondent. La suppression des segments de points des chemins se normalise sans entraîner de changement.
La normalisation est importante pour l'analyse, la mise en cache et le suivi des liens. Les URL ne différant que par la casse des chiffres hexadécimaux (la RFC 3986 préfère les majuscules) devraient être identiques en pratique. La normalisation évite les entrées de journal en double et les échecs de cache. Les caches saisis sur des URL normalisées servent le contenu quelle que soit la préférence de codage du demandeur. Les conseils de normalisation RFC 3986 permettent aux systèmes de prendre des décisions cohérentes. Mais une application stricte empêche les URL de fonctionner correctement sur Internet actuel.
La norme d'URL WHATWG : analyse de ce que les navigateurs reçoivent réellement – ensembles de codage, schémas spéciaux et tolérance d'erreur
La norme d'URL WHATWG (2016–présent) a émergé de l'expérience du navigateur avec des URL ne suivant pas parfaitement la RFC 3986. Les navigateurs étaient confrontés à des espaces non codés, à des encodages mixtes et à des bizarreries. WHATWG décrit l'analyse réelle du navigateur, pas la grammaire théorique. Les navigateurs du monde réel ont développé des règles pratiques pour tolérer les espaces, gérer les caractères d'échappement et récupérer des entrées mal formées. La RFC 3986 est arrivée dans 2005 et a défini la grammaire formelle, mais dans la pratique, les navigateurs avaient déjà légèrement divergé.
WHATWG définit neuf jeux de codes avec des règles spécifiques au contexte. L'espace dans le chemin devient %20 ; la barre oblique dans les informations utilisateur devient %2F. Le navigateur applique une norme plus étroite pour le Web. La RFC 3986 fournit une référence ; WHATWG s'appuie sur cela.
Exemple concret : une URL avec un tilde, un espace et un caractère non-ASCII – comment chaque génération de règles l'encode
Les domaines internationalisés utilisent le codage punycode (München devient xn--mnchen-3ya). Les chemins et les requêtes utilisent toujours le codage en pourcentage. La partie domaine utilise du punycode ; Les parties de chemin et de requête utilisent un codage en pourcentage. Les couches ne se mélangent pas et n'interfèrent pas.
IDNA (Internationalized Domain Names in Applications) résout le problème du nom d'hôte. Punycode encode le non-ASCII en ASCII pour la compatibilité DNS. Le préfixe xn-- signale le codage punycode. L'algorithme est déterministe : münchen devient toujours xn--mnchen-3ya. Les caractères non-ASCII doivent être convertis avant la résolution DNS. Le codage en pourcentage ne fonctionne pas pour les noms d'hôte en raison des contraintes DNS et des limites d'étiquettes. Chaque approche résout correctement un problème différent. Les normes ont évolué séparément pour de bonnes raisons.
Ce que cela ne couvre pas : les IRI et les noms de domaine internationalisés, qui ont leur propre histoire
Le choix des normes dépend du contexte. Créer des URL pour les navigateurs ? Suivez la RFC 3986 ; les navigateurs appliquent WHATWG. Des systèmes plus anciens ? Tester les implémentations. Comprendre l’évolution évite la confusion.
Les constructeurs modernes doivent suivre RFC 3986 ou WHATWG contextuellement. Les anciennes et les nouvelles URL coexistent, ce qui nécessite une réflexion approfondie en matière de compatibilité. L'encodeur et le décodeur d'URL suivent partout la RFC 3986, offrant une référence fixe distincte du comportement du navigateur. WHATWG ajoute des ensembles de codage spécifiques aux composants au-delà des bases RFC. Savoir ce qui a changé à quel moment permet de comprendre pourquoi les systèmes ne sont pas d’accord. Tester votre URL avec les deux normes révèle quelles normes contrôlent dans votre environnement. Les deux normes sont correctes.
À retenir : sachez quel livre de règles suit votre code - comment l'encodeur et le décodeur d'URL vous donnent le comportement RFC 3986 comme point de référence fixe La normalisation
RFC 3986 permet de décoder en toute sécurité les caractères non réservés inutilement codés en pourcentage. %41 se normalise en A. Les caractères réservés codés comme %2F ne sont jamais décodés ; changer de sens brise la structure. Les organismes de normalisation maintiennent farouchement la rétrocompatibilité. Pour y remédier, il faudrait une coordination mondiale impossible après des décennies. Les livres de normes ne brisent pas le Web de manière rétroactive. Changer les décisions d’encodage brise simultanément des milliards de systèmes existants.
Le codage en pourcentage s'étend sur trois décennies d'évolution minutieuse : de RFC 1738 à RFC 2396 et RFC 3986 jusqu'à la norme d'URL moderne WHATWG. Le code moderne doit suivre la ligne de base de la RFC 3986. Les anciennes URL avec un codage antérieur restent valides. Les tests aller-retour garantissent l’exactitude et la compatibilité.