Outils de développement · Encodeur et décodeur d'URL
RFC 3986 caractères réservés et non réservés : ce que dit la norme URI
· Contexte
encodage d'URL rfc3986 rotation encodage en pourcentage développeur
RFC 3986 divise les caractères en caractères réservés, non réservés et tout le reste, et cette répartition explique chaque règle de codage en pourcentage que vous avez respectée. Cet article lit clairement les sections pertinentes.
RFC 3986 caractères réservés et non réservés : ce qui compte lorsque vous créez des URL
RFC 3986 divise les caractères en trois catégories : non réservés, réservés et tout ce qui doit être codé. Les caractères non réservés n'ont jamais besoin d'être codés : ce sont les lettres, les chiffres, le trait d'union, le point, le trait de soulignement et le tilde. La RFC les répertorie explicitement dans la section 2.3, indiquant qu'ils peuvent être laissés non codés en toute sécurité dans n'importe quel contexte d'URI. Les tests dans l'encodeur et le décodeur d'URL avec ces caractères montrent qu'ils passent inchangés. Les caractères réservés se subdivisent en délimiteurs génériques (: / ? # [ ] @) et sous-délimiteurs (! $ & ' ( ) * + , ; =), chacun ayant une signification structurelle dans différents composants d'URL.
Quand un caractère doit-il être codé ? Les caractères réservés doivent être codés en pourcentage uniquement lorsqu'ils créent une ambiguïté. Une barre oblique marque les segments de chemin ; dans une valeur de requête, elle doit être %2F. Une esperluette sépare les paramètres ; & dans une valeur nécessite %26. Les caractères non réservés n’ont jamais besoin d’être codés : un trait d’union reste un trait d’union. La norme URL garantit une analyse correcte. Test avec l'encodeur et le décodeur d'URL : saisir "hello/world" avec encodeURIComponent produit "hello%2Fworld" ; avec encodeURI, il préserve la barre oblique.
Non réservé : lettres, chiffres, tiret, point, trait de soulignement et tilde – les caractères qui n'ont jamais besoin d'être codés et ne doivent jamais être codés
Le codage en pourcentage utilise %HH où HH est une notation hexadécimale. La lettre ASCII A (code 65) devient %41. É non-ASCII nécessite un encodage UTF-8 : é (U+00E9) devient %C3%A9. Les normes modernes spécifient UTF-8 uniformément dans tous les navigateurs.
Les URL complètes doivent avoir une syntaxe structurelle intacte ; les valeurs de requête nécessitent des caractères réservés internes inoffensifs. Le paramètre de requête ?q=R&D doit coder le & comme %26 s'il est manuel, sinon l'esperluette devient un séparateur. Les valeurs avec des barres obliques deviennent %2F en mode composant. L'encodage des composants (encodeURIComponent) gère cela en encodant tout sauf les lettres, chiffres et - _ non réservés. ! ~ *' ( ). Les tests montrent clairement la différence entre les méthodes.
Réservé : gen-delims et sub-delims — les deux groupes, leurs membres et leurs rôles structurels
Les chaînes de requête démontrent pourquoi les caractères réservés sont importants. L'esperluette sépare les paires clé=valeur : ?utm_source=email&utm_campaign=sale signifie deux paramètres. À l’intérieur d’une valeur, une esperluette non échappée termine la paire. Equals sépare les clés des valeurs. L'analyse s'effectue sur plusieurs couches ; chacun applique les mêmes règles.
Les caractères nécessitant un codage dans les valeurs de requête incluent l'esperluette, les égaux, le hachage, le point d'interrogation, les espaces et les lettres non-ASCII. Le hachage est le plus sournois : #anything devient un identifiant de fragment, jamais envoyé au serveur. Les noms de campagne se terminant par un hachage perdent tout ce qui les suit avant que la requête ne quitte le navigateur. Les espaces doivent devenir %20. Les tests avec l'encodeur et le décodeur d'URL montrent les modes de composant et de formulaire. Comprendre la position détermine le besoin de codage.
Lorsque les caractères réservés doivent être codés — uniquement lorsqu'ils seraient confondus avec un délimiteur, composant par composant
Le codage en pourcentage persiste dans la RFC 3986. L'ensemble non réservé reste petit pour garantir la portabilité. Les caractères non réservés codés en pourcentage peuvent être décodés sans changement significatif. Le décodage de %41 en A est correct car A n'est pas réservé. Le décodage de %2F en / change de signification lorsque la barre oblique est une donnée et non un séparateur. La section de normalisation 6 de la RFC 3986 couvre les approches syntaxiques.
Les personnages réservés dans différentes positions ont des rôles différents. Deux points dans le schéma des marques schéma : limite d'autorité ; Les deux points dans userinfo sont des données. Le point d'interrogation ouvre la section de requête ; la barre oblique dans la valeur de la requête est littérale. Le hachage marque le début du fragment. La position détermine le besoin de codage. Les chaînes de requête transportent des valeurs qui sont elles-mêmes des URI. L'encodage d'une URL de redirection telle que https://example.com/page?param=value en tant que paramètre nécessite l'encodage des barres obliques et des deux-points en %2F et %3A. Le contexte définit toujours les caractères sûrs.
Exemple pratique : classer chaque caractère d'une URL réelle : non réservé, réservé comme délimiteur, réservé comme données
RFC 1738 (1994) considérait de nombreux caractères comme dangereux. À mesure que les déploiements se sont standardisés sur UTF-8, les normes ultérieures ont assoupli les restrictions. Tilde (~) illustre l'évolution : RFC 1738 requis %7E, RFC 2396 (1998) a déplacé le tilde vers non réservé, RFC 3986 a confirmé le statut non réservé. L'évolution reflète les leçons du déploiement. Les normes préservent la compatibilité ascendante.
La normalisation RFC permet de décoder les caractères non réservés inutilement codés en pourcentage. %41 se normalise en toute sécurité en A. Les caractères réservés codés comme %2F ne sont jamais décodés ; changer de sens brise la structure. Le consensus moderne utilise la RFC 3986 comme référence de référence. 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 URL Standard ajoute des ensembles de codage spécifiques aux composants au-delà de RFC. Des normes coexistent : RFC 3986 pour l'analyse générale des URL, WHATWG pour les navigateurs Web. Les bibliothèques diffèrent ; vérifier la documentation.
Conseils de normalisation dans la section 6 — cas hexadécimal, décodage sans réserve et règles de segment de chemin
Les tests par rapport à la RFC 3986 garantissent que les URL fonctionnent sur plusieurs logiciels sur plusieurs décennies. L'encodeur et le décodeur d'URL donnent la ligne de base d'encodage RFC 3986 à appliquer aux composants construits. Lisez la documentation standard expliquant chaque décision d'encodage dans les bibliothèques d'URL. L'URL WHATWG s'appuie sur la RFC 3986 plutôt que de la remplacer entièrement. Créer des URL pour les navigateurs généraux ? Suivez la RFC 3986 ; les navigateurs appliquent les règles WHATWG par-dessus. Des systèmes plus anciens ? Testez les implémentations réelles. Normalisation pour le stockage ? Appliquez la RFC 3986 de manière cohérente. Comprendre la distinction réservée/unreserved vous indique les caractères sûrs.
L'encodage d'URL ne constitue pas une vérification de sécurité. Chaque contexte (SQL, HTML, JavaScript, URI) nécessite son propre codage de sortie. Le codage en pourcentage protège uniquement la structure de l'URL. Appliquez la bonne défense sur la bonne couche.
Ce que ceci ne couvre pas : les différents jeux d'encodages et la gestion IRI de la norme d'URL WHATWG.
RFC 2396 (1998) a clarifié les jeux de caractères de manière plus rigoureuse que la RFC 1738. Il formalise des caractères réservés servant de structure URI et non réservés comme données littérales. Développé sans réserve, y compris le trait d'union, le point, le trait de soulignement et le tilde par rapport aux définitions originales. La RFC 2396 a introduit la distinction entre les gen-delims (:, /, ?, #, [, ], @) et les sous-delims (!, $, &, ', (, ), *, +, ,, ;, =). Chaque groupe a des rôles structurels différents dans les URL. La dénomination clarifie les caractères réservés divisés en deux groupes. Connaître les noms facilite les discussions techniques.
RFC 3986 (2005) est une référence moderne. Il a conservé la distinction réservée/unreserved mais une notation simplifiée. Les organismes de normalisation ne brisent pas le Web de manière rétroactive. Encodez délibérément en connaissant votre standard. L'encodeur et le décodeur d'URL fournissent une référence RFC 3986.
À retenir : la norme est courte et précise : comment les deux modes de l'encodeur et du décodeur d'URL correspondent au codage des données par rapport à la préservation des délimiteurs
Le choix des normes dépend du contexte. Créer des URL pour les navigateurs généraux ? Suivez la RFC 3986 ; les navigateurs appliquent les règles WHATWG. Des systèmes plus anciens ? Testez les implémentations réelles. Normalisation pour le stockage ? Appliquez la RFC 3986 de manière cohérente. Les règles de codage en pourcentage ont évolué de la RFC 1738 conservatrice à la RFC 2396 et RFC 3986 clarifiées jusqu'à la norme d'URL WHATWG en couches. Chaque génération reflétait l'expérience. Les constructeurs modernes suivent RFC 3986 ou WHATWG contextuellement. Les anciennes et nouvelles URL coexistent, ce qui nécessite une réflexion sur la compatibilité. Comprendre les catégories évite les erreurs d’encodage.
Vérifiez que les URL sont correctement encodées avant le déploiement. L'encodeur et le décodeur d'URL démontrent les règles RFC 3986 de bout en bout. Consultez les valeurs hexadécimales exactes et comprenez quels caractères codent. Utilisez cet outil lors de la création d'URL en concaténant des éléments. Jeux de caractères de partition de catégories réservées et non réservées RFC 3986 pour une analyse URI cohérente.