Parseur d'URL : brisez n'importe quel lien dans ses parties et lisez la chaîne de requête

J'ai perdu un après-midi une fois à cause d'une URL qui avait l'air bien. Un rappel OAuth n'a cessé d'échouer, l'URI de redirection "correspondant" à celui enregistré auprès du fournisseur, et je ne voyais pas pourquoi la poignée de main s'est cassée. La réponse, lorsque j'ai finalement collé la chose dans un analyseur, était une barre oblique sur le chemin à un endroit et aucune dans l'autre, plus un state Paramètre qui avait été doublement encodé %20 était devenu %2520. Pour l'œil humain, les deux URL étaient identiques. Pour le serveur OAuth, il s'agissait de différentes chaînes, et il était juste de rejeter la non-concordance.

C'est le problème avec les URL : elles sont denses, elles sont faciles à mal lire et les détails qui cassent les choses - une barre oblique codée, un port errant, une clé de requête répétée, un fragment où vous attendiez un chemin - sont exactement ceux qui se cachent dans un mur de caractères. je construis toolz.dev, et je passe suffisamment de temps à regarder les chaînes de requête lors du débogage que j'ai construit un Analyseur d'URL Pour me faire le regard. Collez un lien, obtenez chaque composant étiqueté et chaque paramètre de requête décodé dans une table. Ce guide explique ce que sont ces composants, pourquoi les distinctions sont importantes et comment les utiliser.

tl;dr : Une URL est composée d'un schéma (https), les informations d'identification facultatives (user:pass@), un hôte (example.com) avec un port optionnel, un chemin (/blog/post), une chaîne de requête (?id=42), et un fragment (#section). le Analyseur d'URL Fractionne tout lien dans ces parties à l'aide du moteur d'URL Whatwg du navigateur, décode la requête en une table clé-valeur ordonnée (clés répétées séparées), affiche le port effectif du schéma et suppose https:// Si vous collez un domaine nu. Il s'exécute entièrement dans votre navigateur, de sorte que les liens avec les jetons restent privés.

Quelles sont les parties d'une URL ?

Chaque URL suit la même grammaire, définie par la norme d'URL Whatwg - les navigateurs de spécification implémentent réellement. Une fois que vous pouvez nommer les parties, la plupart des bogues d'URL deviennent évidents. Voici l'anatomie complète, en utilisant un exemple délibérément occupé :

https://john:[email protected]:8443/catalog/shoes?color=red&size=42#reviews
└─┬─┘   └──┬──┘└─┬──┘└──────┬────────┘└─┬─┘└──────┬──────┘└──────┬──────┘ └──┬──┘
scheme   user  pass       hostname     port      path          query      fragment

Décomposer ça :

L'analyseur dépose chacun de ces éléments comme sa propre ligne avec un bouton de copie, de sorte que vous n'aurez plus jamais à extraire un nom d'hôte d'une URL de monstre. Il marque également plusieurs éléments que la chaîne brute cache : que le port affiché soit explicite ou par défaut du schéma, et si l'hôte est un domaine nommé ou une adresse IP brute.

Quelle est la différence entre le nom d'hôte, l'hôte et l'origine ?

Ces trois personnes font régulièrement le voyage, et la confusion provoque de véritables bugs - échecs de COR, erreurs de portée des cookies, réorientation des incompatibilités. Ce ne sont pas des synonymes.

nom d'hôte est juste le domaine ou l'IP : shop.example.co.uk. Pas de port, pas de schéma. C'est ce que vous mettriez dans une recherche DNS.

hôte est le nom d'hôte plus le port, Mais seulement lorsqu'un port est présent dans l'URL. pour shop.example.co.uk:8443 L'hôte est shop.example.co.uk:8443. pour une plaine https://shop.example.co.uk/ L'hôte et le nom d'hôte sont identiques, car le port 443 par défaut est implicite plutôt qu'écrit. Cette règle "seulement lorsqu'elle est présente" est subtile et c'est pourquoi le même site peut sembler avoir deux hôtes différents.

origine est un hôte de schéma plus : https://shop.example.co.uk:8443. C'est celui dont les navigateurs se soucient le plus, car la politique de même origine - la fondation de la sécurité Web - compare les origines, et non les noms d'hôte. Deux URL ne partagent une origine que si leur schéma, nom d'hôte, et Portez tout le match. http://example.com et https://example.com sont des origines différentes car le schéma diffère. https://example.com et https://example.com:8443 sont des origines différentes car le port diffère, même si le nom d'hôte est le même. Si un extraction échoue avec une erreur CORS, comparer côte à côte les deux origines de l'analyseur est généralement le moyen le plus rapide de repérer la non-concordance.

Comment analyser une chaîne de requête ?

La chaîne de requête est l'endroit où vit la plupart des douleurs quotidiennes, car il s'agit d'une goutte plate et d'apparence non évadée qui est réellement structurée et encodée en pourcentage. L'analyseur le divise pour vous : tout après le ?, cassé le &, avec chaque key=value Paire décodée et répertoriée dans un tableau dans sa commande d'origine.

Deux comportements sont importants ici. Premièrement, décodage. un paramètre écrit comme q=trail%20runner sur le fil est indiqué comme trail runner dans la colonne Valeur, car %20 est un espace en pourcentage. le brut search La chaîne est toujours affichée intacte dans la liste des composants, de sorte que vous pouvez comparer les formulaires codés et décodés, inestimables lorsque vous soupçonnez un double encodage, comme mon %2520 OAuth Bug.

Deuxièmement, Touches répétées. Une URL peut légitimement porter la même clé plus d'une fois : ?tag=react&tag=typescript&tag=node. De nombreux analyseurs naïfs les effondrent, ne conservant que la première ou la dernière valeur et perdent silencieusement des données. Ce qui est faux : les clés répétées expliquent comment les formulaires HTML soumettent des champs multi-sélections et comment de nombreux tableaux API expriment. L'analyseur conserve chaque occurrence comme sa propre ligne, afin que vous voyiez les trois balises. Lorsque vous copiez la requête en JSON, les touches répétées deviennent un tableau, dont le code est le plus attendu.

Vous n'avez même pas besoin d'une URL complète pour l'utiliser. Coller une chaîne de requête — color=red&size=42 — et l'outil l'analyse par lui-même. C'est le moyen le plus rapide que je connaisse de donner un sens à une charge utile de webhook ou à un lien de suivi que quelqu'un vous a transmis.

Comment utiliser l'analyseur d'URL ?

L'outil est conçu pour s'écarter de votre chemin. Collez une URL dans l'entrée unique et elle analyse en direct au fur et à mesure que vous tapez - aucun bouton sur lequel appuyer. Un exemple de lien est préchargé afin que vous puissiez voir la ventilation complète immédiatement, et un bouton clair vide le champ.

Vous n'êtes pas obligé de taper le schéma. Coller un hôte nu comme example.com/pricing Et l'analyseur s'y installe https:// Automatiquement, puis vous dit qu'il l'a fait avec une petite note, afin que vous ne soyez jamais confus quant à l'origine du schéma. Coller un schéma explicite — http://, ftp://, ssh:// — Et il respecte cela à la place.

La sortie a quatre zones. Au sommet, le URL normalisée — Le moteur canonique du moteur produit par le moteur, avec un bouton de copie, qui est pratique pour attraper de subtiles différences de normalisation. En dessous, le composants table, une ligne étiquetée par pièce, chacune étant copiable indépendamment. à ce moment- Segments de chemin, divisé en puces indexées, donc un chemin profond comme /api/v2/users/42/orders est lisible en un coup d'œil. Enfin le Paramètres de requête Table, décodée et ordonnée, avec une action "copier en JSON" qui transforme l'ensemble de la requête en un objet propre.

Tout s'exécute dans votre navigateur en utilisant son moteur d'URL natif. C'est un choix délibéré : les URL contiennent régulièrement des jetons d'accès, des ID de session, des paramètres signés et des noms d'hôte internes, et aucune de ces informations ne doit être expédiée à un serveur juste pour être lu. Rien de ce que vous collez quitte votre appareil et l'outil continue de fonctionner hors ligne. C'est la même approche de confidentialité qui se fonde sur toute la boîte à outils, dans laquelle j'aborde le Guide d'outils pour les développeurs Web.

Quand dois-je accéder à un analyseur d'URL ?

Quelques situations reviennent encore et encore dans mon propre travail. Débogage des redirections et des rappels est le plus important - OAuth Flows, Payment Return URL, SSO Handshakes, qui échouent tous sur de minuscules incompatibilités qui ne deviennent visibles que lorsque vous décomposez les deux URL. Auditer les liens de suivi En est une autre : les URL de marketing sont souvent une page de base plus une douzaine de paramètres UTM et de plate-forme AD, et les lire comme une table bat les yeux à une chaîne de 300 caractères. Si vous créez ces liens plutôt que de les lire, le Constructeur UTM est l'autre moitié du même flux de travail.

Ensuite, il y a API Travail — Inspection des paramètres de requête d'un client réellement envoyé ou inversion de la manière dont un point de terminaison attend ses filtres. et Examen de sécurité: Un lien inconnu dans un e-mail ou un journal est beaucoup plus sûr à comprendre en analysant ses parties (quel hôte cela vraiment Point à ? Est-ce que ce nom d'hôte est une adresse IP ?) qu'en cliquant dessus. L'analyseur expose le véritable nom d'hôte et les hôtes ip-literal de drapeaux, qui correspond exactement aux informations que vous souhaitez avant de faire confiance à un lien. J'ai écrit plus sur l'assemblage de ce type de kit d'inspection dans le Guide des outils de débogage de l'API.

Quel est le lien entre l'analyse et l'encodage et les limaces ?

Un analyseur d'URL est un coin d'une petite famille d'outils de liaison, et sachant lequel vous avez besoin, vous fait gagner du temps. analyseur lit Une URL existante et la sépare. codage Est-ce que la direction opposée au niveau du personnage est la transformation d'espaces et de caractères spéciaux en leurs formes en pourcentage afin qu'ils survivent dans une URL, et vice-versa. Lorsque vous devez intégrer en toute sécurité une valeur dans une chaîne de requête ou décoder une valeur muée, c'est-à-dire Encodeur/décodeur d'URL, et il se couple naturellement avec l'analyseur : analyser la structure, encoder pour fixer une valeur cassée.

Génération de limaces est un troisième travail connexe - prendre un titre humain comme "10 conseils pour des constructions plus rapides" et le transformer en un nettoyage 10-tips-for-faster-builds Segment de chemin. C'est ce que le générateur de limace gère, et c'est ce qui produit le bien rangé path Composant L'analyseur réitère plus tard. Considérez-le comme un pipeline : Slugify pour construire de bons chemins, encodez pour rendre les valeurs URL-safe, analysez pour inspecter le lien terminé. Chaque outil fait une partie du cycle de vie de l'URL et le fait dans le navigateur.

Qu'en est-il des adresses IP et des domaines internationalisés ?

Tous les hôtes ne sont pas un hébergeur example.com. Certaines URL pointent vers des adresses IP brutes et l'analyseur reconnaît les deux formes. Un littéral IPv4 comme http://192.168.1.10:3000/ a un nom d'hôte de 192.168.1.10, et l'outil le signale comme une adresse IP plutôt qu'un domaine - utile lorsque vous auditez un lien et que vous souhaitez savoir instantanément s'il cible un site nommé ou une adresse nue, ce qui est un signal courant dans les liens suspects. Les littéraux IPv6 sont enveloppés entre crochets dans une URL, comme dans http://[2001:db8::1]:8080/, et les crochets font partie de la syntaxe de l'hôte, pas la décoration; les poignées de l'analyseur qui se forment entre parenthèses se forment correctement au lieu de s'étouffer avec les deux-points, qui ressembleraient autrement à des séparateurs de ports.

Les noms de domaine internationalisés sont l'autre cas de bord. Un hôte écrit en caractères non ASCII - disons un domaine avec des lettres accentuées ou non latines - est converti par le moteur d'URL du navigateur en son code PunyCode xn-- Formulaire pour la demande réelle, car DNS ne parle que ASCII. Voir le normalisé href Dans l'analyseur, vous montre exactement ce que le navigateur résoudra, ce qui surprend parfois les personnes qui s'attendaient à ce que leur domaine de joli Unicode se déplace inchangé. Pour le domaine de premier niveau, l'analyseur extrait l'étiquette finale d'un hôte nommé, donc shop.example.co.uk rapporte un TLD de uk. C'est une règle délibérément simple - elle n'essaie pas de décocher les suffixes en plusieurs parties comme .co.uk dans un domaine enregistrable, car cela nécessite la liste des suffixes publics, qui est un grand jeu de données mobile. Pour une inspection rapide, la dernière étiquette est le signal utile, et pour tout ce qui est plus rigoureux, vous recherchez une bibliothèque dédiée.

Un exemple travaillé le relie. Supposons qu'un fournisseur de paiement continue de rejeter votre URL de retour. vous vous êtes inscrit https://app.example.com/checkout/return Mais la demande d'échec s'affiche https://app.example.com:443/checkout/return/. analyser les deux. L'analyseur montre que le premier a un hôte app.example.com (Port par défaut, pas de barre oblique sur le chemin) et le second a un hôte app.example.com aussi - mais son chemin est /checkout/return/ avec une barre oblique, et son port a été écrit explicitement comme :443. Deux différences que l'œil glisse, les deux fatales à un contrôle exact de la correspondance. Une fois que vous pouvez les voir comme des composants étiquetés séparés, le correctif est évident : normalisez la barre oblique et supprimez le port explicite redondant.

Erreurs courantes lors de la lecture d'URL

Les erreurs récurrentes méritent d'être nommées. Confondre le fragment avec le chemin ou la requête — tout après # est le fragment, il est entièrement géré par le navigateur et n'est jamais envoyé au serveur, donc un paramètre que vous mettez après # n'atteindra pas votre backend. Supposer un port manquant signifie qu'aucun port — Un port omis signifie le schéma par défaut (443 pour HTTPS, 80 pour HTTP), que l'analyseur rend explicite afin que vous sachiez quel port une requête sera réellement atteinte.

Ignorer le double encodage — Si une valeur ressemble à %2520 au lieu de %20, il a été codé deux fois, analysez-le et si la valeur décodée contient toujours un pourcentage de séquence, décodez à nouveau. Faire confiance au texte visible d'un lien — le texte que vous voyez et le réel href Peut différer complètement, ce qui est le mécanisme de l'hameçonnage, l'analyse révèle le véritable hôte de destination. et Traiter les clés de requête répétées comme des doublons à ignorer — Ce sont souvent des tableaux significatifs et leur suppression perd des données.

Questions fréquentes

Quelles sont les parties d'une URL ?

Une URL a un schéma (https), des informations d'identification facultatives (utilisateur:pass@), un hôte (exemple.com) avec un port optionnel, un chemin (/blog/poste), une chaîne de requête facultative (?id=42) et un fragment facultatif (#section). Cet analyseur sépare et étiquette chacun.

Comment analyser une chaîne de requête ?

Collez l'URL complète et lisez la table de requête, ou collez la chaîne de requête seule. L'analyseur le divise sur des esperluettes, décode l'encodage en pourcentage et répertorie chaque paire clé-valeur dans l'ordre. Les clés répétées telles que TAG=A&tag=b sont conservées comme des lignes séparées.

Quelle est la différence entre le nom d'hôte, l'hôte et l'origine ?

Le nom d'hôte n'est que le domaine ou l'adresse IP (exemple.com). Host ajoute le port lorsqu'un est présent (exemple.com:8443). L'origine est le schéma plus hôte (https://example.com:8443) et est ce que les navigateurs utilisent pour la même vérification de sécurité d'origine.

Quel port est utilisé lorsqu'une URL n'a pas de numéro de port ?

Le régime décide. Par défaut, HTTPS est de 443, HTTP à 80, SSH à 22 et FTP à 21. Cet analyseur affiche le port effectif et le marque comme étant le port par défaut, afin que vous sachiez quel port une requête utiliserait réellement.

L'analyseur décode-t-il les caractères encodés en pourcentage ?

Oui, pour les valeurs de requête. Un paramètre comme name=John%20doe est affiché comme "John Doe" dans le tableau. La chaîne de recherche brute est également affichée intacte afin que vous puissiez comparer les formes codées et décodées.

Puis-je analyser une URL sans taper la partie HTTPS ?

Oui. Si vous collez un hôte ou un chemin d'accès nu tel que exemple.com/prix, l'analyseur présuppose https:// automatiquement et note qu'il a supposé le schéma. Collez un schéma explicitement, tel que http:// ou ftp://, pour annuler cette hypothèse.

Pourquoi mon URL ne parvient-elle pas à analyser ?

Habituellement, l'hôte est manquant ou mal formé, le schéma est mal écrit ou la chaîne contient des caractères illégaux dans une URL et qui ne sont pas codés en pourcentage. Vérifiez les espaces, les crochets non échappés ou une barre oblique manquante après le schéma.

Est-il sûr de coller des URL avec des jetons ou des ID de session ?

Oui. L'analyse s'exécute entièrement dans votre navigateur à l'aide de son moteur d'URL natif. Le lien n'est jamais envoyé à un serveur, jamais enregistré et jamais stocké, de sorte que les URL contenant des jetons d'accès, des clés d'API ou des noms d'hôte internes restent sur votre appareil.