BrowserTools
Publicité
Accueil / Réseau / Analyseur d'URL

Analyseur d'URL

Décomposez n'importe quelle URL en son schéma, son hôte, son port, son chemin, ses paramètres de requête et son hash, analysé localement dans votre navigateur.

Chargement de Analyseur d'URL… Si rien ne se passe, activez JavaScript.

Une URL (Uniform Resource Locator) ressemble à une simple chaîne, mais c'est en réalité un enregistrement structuré composé de plusieurs éléments distincts, chacun ayant sa propre signification. Une URL complète telle que https://user:pass@example.com:8443/path/page?q=hello&lang=en#section regroupe un schéma, des identifiants optionnels, un hôte, un port optionnel, un chemin, une query string et un fragment. Lire ces parties à l'oeil est facile à mal interpréter, surtout lorsque la query string est longue, contient des caractères encodés en pourcentage ou répète la même clé plus d'une fois. Un analyseur découpe l'URL avec précision selon les règles définies dans le WHATWG URL Standard, les mêmes règles que suit tout navigateur moderne.

Questions fréquentes

L'URL que je colle est-elle envoyée à un serveur ?
Non. L'analyse se déroule entièrement dans votre navigateur à l'aide des API intégrées URL et URLSearchParams. L'URL que vous saisissez, y compris tout jeton ou identifiant qu'elle contient, n'est jamais transmise, stockée ni journalisée où que ce soit. L'outil fonctionne entièrement hors ligne une fois la page chargée.
Quelles sont les parties d'une URL ?
Une URL comporte jusqu'à sept parties : le schéma (tel que https), les userinfo optionnels (nom d'utilisateur et mot de passe), l'hôte (un domaine ou une adresse IP), un port optionnel, le chemin, une query string optionnelle (la partie après le point d'interrogation) et un fragment optionnel (la partie après le hash). Pour https://example.com:8443/a/b?x=1#top, le schéma est https, l'hôte est example.com, le port est 8443, le chemin est /a/b, la requête est x=1 et le fragment est top.
Pourquoi le port s'affiche-t-il comme par défaut pour certaines URL ?
Lorsqu'une URL utilise le port standard de son schéma (443 pour https, 80 pour http), le navigateur laisse le champ du port vide car il est implicite. Cet outil étiquette ce cas comme par défaut. Si vous incluez explicitement un port non standard tel que :8443, il est affiché exactement tel qu'il est écrit.
Quelle est la différence entre host et hostname ?
Le hostname n'est que le domaine ou l'adresse IP, par exemple example.com. Le host comprend le hostname plus le port lorsqu'un port non par défaut est présent, par exemple example.com:8443. S'il n'y a pas de port explicite dans l'URL, host et hostname sont identiques.
Comment les paramètres de requête répétés sont-ils gérés ?
URLSearchParams conserve chaque occurrence d'une clé dans l'ordre, de sorte qu'une query string comme a=1&a=2 produit deux lignes distinctes dans le tableau plutôt que de les fusionner. Cela correspond à la façon dont les serveurs et les frameworks reçoivent généralement les données, où les clés répétées sont courantes pour les filtres à sélection multiple et les paramètres de type tableau.
Décode-t-il les caractères encodés en pourcentage dans les valeurs de requête ?
Oui. URLSearchParams décode automatiquement en pourcentage à la fois les clés et les valeurs, de sorte que %20 apparaît comme un espace et %40 apparaît comme @ dans le tableau. Si vous devez encoder ou décoder une valeur pour la remettre dans une URL, l'outil URL Encoder gère cette direction.
Pourquoi est-ce que j'obtiens une erreur d'URL invalide ?
L'analyseur URL natif exige une URL absolue avec un schéma, telle que https://example.com. Les entrées nues comme example.com/page ou les chemins relatifs comme /page sont rejetés car il n'y a aucune base sur laquelle les résoudre. Ajoutez un schéma tel que https:// au début et l'URL s'analysera correctement.
Peut-il analyser des schémas non web comme mailto ou ftp ?
Oui, tant que l'entrée est une URL absolue valide. Les schémas tels que ftp, ws, wss, file et mailto s'analysent tous, bien que certains composants (comme l'hôte ou le port) puissent être vides pour les schémas qui ne les utilisent pas. Les champs affichés reflètent ce que le standard URL extrait pour ce schéma.

À propos de Analyseur d'URL

Cet outil utilise les API natives URL et URLSearchParams intégrées à votre navigateur, de sorte que les résultats correspondent exactement à la façon dont un navigateur, un appel fetch ou un framework serveur interpréteraient l'adresse. Il affiche le schéma et le protocole complet, tout nom d'utilisateur et mot de passe intégrés dans l'autorité, l'hôte et le hostname, le port (ou une note indiquant que celui par défaut du schéma s'applique), le pathname, l'origin calculé et le fragment hash. La query string est éclatée en un tableau net de paires clé-valeur, chaque valeur étant copiable individuellement, ce qui est bien plus rapide que de fouiller dans un mur d'esperluettes et de signes égal.

Tout s'exécute localement dans votre navigateur. L'URL que vous collez n'est jamais téléversée, journalisée ni envoyée à un serveur, il est donc sûr d'inspecter des liens contenant des jetons d'accès, des identifiants de session, des paramètres signés ou d'autres valeurs de requête sensibles. Les développeurs se tournent vers un analyseur d'URL lorsqu'ils déboguent des redirections, des URL de rappel OAuth, la soupe de paramètres de suivi des campagnes marketing, des points d'accès d'API avec de nombreuses options de requête ou des liens profonds dans les applications mobiles. Si l'entrée n'est pas une URL absolue valide, l'outil affiche une erreur claire plutôt que de deviner.

Le standard d'URL sur lequel personne ne s'est entendu pendant des décennies

Les URL ont d'abord été formalisées par Tim Berners-Lee dans le RFC 1738 en 1994, mais pendant des années par la suite, chaque navigateur, bibliothèque et langage les analysait de manière légèrement différente. Les cas limites tels que les barres obliques inverses, les espaces en début et en fin, les deux-points placés bizarrement et l'encodage en pourcentage dans l'hôte provoquaient de véritables failles de sécurité, car un analyseur sur le serveur et un analyseur dans le navigateur pouvaient être en désaccord sur l'hôte vers lequel une URL pointait réellement. Les attaquants exploitaient ces désaccords pour se faufiler au-delà des listes d'autorisation d'URL et déclencher des falsifications de requête côté serveur.

Pour mettre fin au chaos, le WHATWG a publié le URL Standard, une spécification vivante qui définit l'analyse comme une machine à états précise plutôt que comme une grammaire approximative. Fait crucial, la spécification a été écrite pour décrire ce que les navigateurs font réellement, y compris leurs bizarreries, de sorte que l'algorithme soit interopérable par construction. Les classes URL et URLSearchParams exposées à JavaScript implémentent cet algorithme exact, ce qui explique pourquoi la sortie de cet outil correspond à ce que voient la barre d'adresse de votre navigateur et les appels fetch.

Un détail subtil que le standard fixe précisément est la différence entre les schémas spéciaux (http, https, ws, wss, ftp, file) et tout le reste. Les schémas spéciaux bénéficient d'une normalisation supplémentaire, comme la mise en minuscules de l'hôte et la résolution du port par défaut, tandis que les schémas non spéciaux sont traités de manière plus littérale. Cette distinction explique pourquoi une URL https et une URL personnalisée myapp avec le même texte après les deux-points peuvent être analysées en valeurs de composants assez différentes.

Publicité
Publicité
Publicité