Parser & Builder URL
Analyse les URLs en 8 composants avec table query et détection IDN/Punycode. Construit des URLs. Résolveur relatif.
Resolved
Query parameters
| Key | Value |
|---|---|
No query parameters.
À propos de cet outil
URL Parser & Builder décompose toute URL en ses huit composants RFC 3986 — schéma, userinfo, host, port, chemin, requête, fragment et la forme originale encodée — et les présente dans un formulaire éditable. Changez n'importe quel champ et l'URL assemblée se met à jour instantanément. La chaîne de requête est affichée comme une table de paires nom/valeur, avec l'encodage pourcent approprié appliqué aux caractères spéciaux.
L'outil gère également les opérations connexes : détection punycode/IDN sur l'hôte (un label xn-- se décode en sa forme Unicode, un hôte Unicode s'encode en xn--), résolution d'URL relative contre une base (appliquez ../foo?bar à https://example.com/a/b/c et obtenez https://example.com/a/foo?bar), et validation contre la spécification URL WHATWG (qui est plus stricte que RFC 3986 dans certains domaines, notamment l'analyse d'autorité).
Quand utiliser cet outil
- Déboguer la gestion d'URL. Une redirection qui arrive comme
%25au lieu de%— trouvez l'étape de double-encodage dans votre stack. - Construire des liens sûrs. Construisez des URL à partir d'entrée utilisateur avec un échappement approprié au lieu de concaténation de chaînes.
- Vérifier une URL suspecte. Décodez les tentatives de traversée
%2E%2Eobscurcies, les astuces homographes IDN et le phishing userinfo en vue claire. - Travailler avec OAuth et redirections. Confirmez que les paramètres
redirect_urisont encodés correctement avant que le serveur d'auth les rejette.
À propos de l'encodage pourcent
RFC 3986 réserve une poignée de caractères avec une signification structurelle (:/?#[]@!$&'()*+,;=). À l'intérieur des segments de chemin et des valeurs de requête ils doivent être encodés en pourcent lorsqu'ils apparaissent comme données plutôt que syntaxe. Les parsers URL modernes le font automatiquement ; la concaténation manuelle de chaînes ne le fait pas. Si vous vous retrouvez à écrire "?key=" + value en code, vous avez presque certainement un bug d'injection — utilisez URLSearchParams ou notre builder à la place.
Questions fréquentes
Quelle est la différence entre userinfo et le chemin ?
:// et l'hôte : https://user:[email protected]/path. C'est techniquement légal dans les URL mais Chrome / Firefox le retirent de la barre d'adresse pour empêcher le phishing (https://[email protected]). Les clients HTTP modernes avertissent ou le refusent. Si vous avez besoin d'identifiants dans une URL, encodez-les correctement et préférez les en-têtes Authorization à la place — userinfo dans les URL est une odeur de sécurité.
Pourquoi mes valeurs de chaîne de requête reviennent-elles avec %20 au lieu d'espaces ?
%20 (encodage pourcent), soit + (la forme plus ancienne form-urlencoded pour les chaînes de requête). Les deux se décodent en espace sur le serveur. %20 est la forme universelle ; + ne fonctionne qu'à l'intérieur des chaînes de requête, jamais dans les chemins. Notre builder utilise %20 partout pour la sécurité.
Comment fonctionne la résolution d'URL relative ?
./ et ../ dans le chemin résultant. Exemples : ../x appliqué à /a/b/c/d donne /a/b/x ; //other.com/path appliqué à n'importe quoi donne //other.com/path (une référence « relative au schéma »). Notre outil exécute cet algorithme et montre l'URL résolue.
Le parser détecte-t-il les attaques homographes IDN ?
xn--) et les décode en Unicode, afin que vous puissiez voir quels caractères sont réellement présents. Un « google.com » avec un о cyrillique au lieu du o latin se décodera en une forme Unicode qui contient visiblement le sosie. Combinez avec l'outil Punycode pour une inspection plus profonde ; les navigateurs modernes affichent également ceux-ci dans la barre d'adresse.