J'ai perdu une heure une fois à cause d'une chaîne de requête Un webhook tiers envoyait filter[status]=open&filter[assignee]=me, mon gestionnaire lisait filter en tant que chaîne plate, et je n'ai pas pu comprendre pourquoi chaque requête passait par non filtrée Le moment où j'ai collé l'URL brute dans un analyseur de chaîne de requête et l'ai vue se résoudre à un objet imbriqué, le bug était évident : l'expéditeur a utilisé la notation de support et mon analyseur ne l'a pas fait Ce guide traite de la façon dont j'utilise le Analyseur de chaînes de requête sur Toolz.dev, quelles sont réellement les parties délicates des chaînes de requête et pourquoi la même clé codée de deux manières différentes peut discrètement rompre une intégration.
tl;dr : Une chaîne de requête est la partie d'une URL après le point d'interrogation qui transporte les paramètres sous forme de paires clé-valeur. Un analyseur de chaîne de requête convertit cela en JSON structuré, décodant le codage en pourcentage et gérant les clés répétées et les tableaux de parenthèses, et peut reconstruire une chaîne de requête correctement codée à partir de JSON. Le Analyseur de chaînes de requête effectue les deux directions dans votre navigateur, afin que vous puissiez inspecter une URL désordonnée ou en assembler une propre sans quitter la page.
Qu'est-ce qu'une chaîne de requête ?
Une chaîne de requête est la section d'une URL qui commence après le premier point d'interrogation et se termine au fragment, la partie après un hachage. Il transporte les paramètres comme key=value paires reliées par des esperluettes, donc ?q=json&page=2 passe deux paramètres Les serveurs et le code client lisent ceux pour filtrer une recherche, suivre une campagne, paginer une liste ou transporter un état entre les pages Les règles génériques pour ce qui est et n'est pas légal dans ce composant proviennent RFC 3986, la norme URI et les règles spécifiques suivies par les navigateurs pour les paramètres de style formulaire proviennent du WhatWG URL standard.
Le problème est que la RFC 3986 définit la syntaxe du composant de requête mais pas sa signification. Il indique quels caractères sont autorisés et comment ils doivent être codés en pourcentage, mais il ne dit rien sur la façon dont key=value les paires correspondent à une structure de données Cette interprétation a été héritée de la soumission de formulaires HTML, et différentes plates-formes l'ont étendue de manière incompatible C'est pourquoi la même chaîne de requête peut signifier des choses légèrement différentes pour un back-end PHP, un contrôleur Rails et un front-end JavaScript, et pourquoi un analyseur doit rendre ses conventions explicites.
Chaque clé et valeur d'une chaîne de requête est codée par URL afin que les caractères réservés survivent Un espace devient %20 ou un signe plus, un esperluette à l’intérieur d’une valeur devient %26 il n’est donc pas confondu avec un séparateur, et une barre oblique devient %2F. Analyser signifie diviser les paires, puis décoder chaque face, et construire signifie coder chaque face et joindre les paires. Se tromper d'encodage dans les deux sens et corrompre silencieusement les valeurs.
Que fait réellement un analyseur de chaînes de requête ?
Un analyseur prend une URL ou une chaîne de requête nue et la transforme en données structurées et lisibles Sur la façon dont il dépouille tout jusqu'au point d'interrogation inclus, ignore le fragment après le hachage, divise les paires, décode chaque clé et valeur et décide comment représenter les clés répétées et les clés entre crochets La sortie est un objet JSON que vous pouvez lire et copier, plus une table plate de chaque paire décodée donc les doublons et les valeurs vides sont évidents.
Sur Toolz.dev l'outil s'exécute dans deux directions En mode analyse vous collez une URL complète ou juste sa chaîne de requête et obtenez le JSON et la table des paramètres En mode build vous collez un objet JSON et obtenez une chaîne de requête correctement codée, avec un choix de la façon dont les tableaux sont représentés Chargez l'échantillon et vous pouvez regarder une URL réelle avec un fragment, un tableau de style répété, et un espace codé résoudre en JSON propre, puis reconstruisez-le.
La raison d'utiliser un analyseur dédié plutôt que de regarder l'URL est que les chaînes de requête cachent leur structure Une longue URL avec des caractères codés, des touches répétées et une notation entre parenthèses est presque impossible à lire correctement en la scannant, et les parties les plus difficiles à lire, l'encodage et les doublons, sont exactement les parties qui provoquent des bugs Voir la table décodée à côté du JSON supprime les conjectures.
Comment les clés répétées sont-elles gérées ?
La même clé peut légalement apparaître plus d'une fois dans une chaîne de requête, comme dans tags=react&tags=laravel[traduction] ?, et il n'existe pas de façon correcte unique d'interpréter cela, ce qui est la racine de beaucoup de confusion Différents systèmes résolvent les doublons différemment, donc un analyseur doit vous laisser choisir.
La convention la plus courante, et la valeur par défaut de l'outil Toolz.dev, consiste donc à collecter des clés répétées dans un tableau tags=react&tags=laravel se transforme {"tags":["react","laravel"]}. Cela correspond à la façon dont le navigateur & #39 ; propre URLSearchParams.getAll expose les valeurs et le comportement de la plupart des back-ends modernes Mais certains frameworks ne conservent que la première occurrence et certains ne conservent que la dernière, de sorte que l'outil offre également des options keep-first et keep-last Lorsque vous déboguez une intégration, faire correspondre le comportement parser' ; s au système qui a produit ou consomme l'URL est ce qui donne du sens au JSON.
Cette ambiguïté n'est pas académique Un problème classique de sécurité et d'exactitude appelé pollution par paramètres HTTP existe précisément parce que deux systèmes dans un chemin de requête peuvent résoudre id=1&id=2 autrement, une vue 1 et l'autre voyant 2. Pouvoir voir explicitement comment un analyseur donné résout les doublons est le moyen le plus rapide de raisonner sur cette classe de bogues.
Que signifient les crochets comme les balises [] ou le filtre [couleur] ?
La notation de support est une convention pour coder des tableaux et des objets imbriqués à l'intérieur d'une chaîne de requête plate, et c'est là que les analyseurs ne sont pas d'accord le plus. Un support vide final marque un tableau, donc tags[]=react&tags[]=laravel construit {"tags":["react","laravel"]}. Un support nommé marque un objet imbriqué, donc filter[color]=red&filter[size]=l construit {"filter":{"color":"red","size":"l"}}. Les supports peuvent nicher, donc a[b][c]=1 construit {"a":{"b":{"c":"1"}}}.
Cette syntaxe provient de la façon dont PHP et Ruby on Rails sérialisent les données de formulaire, et de nombreuses bibliothèques JavaScript telles que qs suivez-le. Cela ne fait partie d’aucune norme d’URL principale, c’est exactement pourquoi une simple URLSearchParams dans le navigateur ne l'étendra pas, vous donnant une clé littérale de tags[] au lieu d'un tableau L'analyseur Toolz.dev comprend la convention et l'étend dans la structure correspondante, et il vous permet d'éteindre ce comportement lorsque vous voulez les clés littérales à la place.
Voici comment s'alignent les principales conventions, tant lors de l'analyse que lors de la construction :
| Style de tableau | Encodé comme | Analyse à | Fréquent en |
|---|---|---|---|
| Clé répétée | tags=a&tags=b |
["a","b"] |
Navigateurs, la plupart des back-ends |
| Support vide | tags[]=a&tags[]=b |
["a","b"] |
PHP, Rails, bibliothèque qs |
| Tranche indexée | tags[0]=a&tags[1]=b |
["a","b"] |
bibliothèque QS, données ordonnées |
| En commun | tags=a,b |
une chaîne à diviser | Quelques API, URL compactes |
Lorsque vous construisez une chaîne de requête avec l'outil, vous choisissez laquelle de celles-ci émettre, de sorte que la sortie correspond à ce que le système récepteur attend Lorsque vous analysez, l'outil détecte les touches répétées et la notation de parenthèse pour vous, et les valeurs jointes en virgule restent comme une seule chaîne car vous seul savez si une virgule est un séparateur ou une partie des données.
Pourquoi les panneaux plus se transforment-ils en espaces ?
Dans la chaîne de requête d'une URL, un espace littéral est très souvent codé sous forme de signe plus plutôt que de %20. C'est une règle héritée du application/x-www-form-urlencoded format utilisé par les formulaires HTML, et le WhatWG URL standard le codifie : lors de l'analyse des données codées par formulaire, a + est décodé en un espace. Donc q=json+parser devrait analyser json parser20, et l'outil Toolz.dev le fait par défaut.
La subtilité est que cette règle s'applique au composant de requête, pas au chemin A + dans un segment de chemin se trouve un plus littéral. Et parfois, vos données contiennent véritablement des signes plus qui doivent être préservés, comme un numéro de téléphone ou une recherche C++. Pour ces cas, l'outil dispose d'un interrupteur pour désactiver plus-comme-espace, donc le plus survit à l'aller-retour. C'est le genre de détail qu'un usage général Encodeur d'URL ne décidera pas pour vous, car il ne sait pas s'il s'agit d'une requête ou d'un chemin.
Obtenir ce droit compte lors de la construction, aussi Lorsque l'outil code une valeur, il pour cent-encode les caractères réservés et, par défaut, utilise un plus pour les espaces dans le style codé par formulaire, donc la chaîne qu'il produit est une chaîne que les navigateurs et les back-ends décoderont comme vous l'aviez prévu.
En quoi cela diffère-t-il d'un analyseur d'URL complet ?
Un analyseur de chaîne de requête et un analyseur d'URL complet se chevauchent mais répondent à différentes questions, et en utilisant la bonne enregistre une étape Un analyseur d'URL brise un lien complet dans ses composants, le schéma, l'hôte, le port, le chemin, la requête et le fragment, et c'est ce que vous voulez lorsque vous déboguez où va une requête ou pourquoi une redirection ou une vérification CORS se comporte bizarrement Un analyseur de chaîne de requête se concentre sur la requête seule et la transforme en JSON structuré et modifiable, comprenant des tableaux et des clés imbriquées, et peut reconstruire la requête.
le Analyseur d'URL sur Toolz.dev est l'outil pour l'anatomie : donnez-lui un lien et il vous montre la distinction hôte contre origine, le port par défaut, et les morceaux du chemin L'analyseur de chaînes de requêtes est l'outil pour travailler avec des paramètres : donnez-lui le même lien et il vous donne les paramètres que JSON que vous pouvez éditer, et puis reconstruit une chaîne de requêtes à partir de vos modifications En pratique je les utilise ensemble, l'analyseur d'URL pour comprendre un lien et l'analyseur de chaînes de requêtes pour changer ses paramètres, et si j'assemble un lien de campagne j'atteins pour le Constructeur UTM au lieu de cela, il s’agit d’un générateur de chaînes de requête spécialisé dans les balises d’analyse.
Quand est-ce que je cherche réellement ça ?
La réponse honnête est chaque fois qu'une URL fait plus que pointer sur une page Je l'utilise pour déboguer des webhooks et des redirections OAuth, où les paramètres transportent la totalité de la charge utile et une valeur mal codée brise le flux Je l'utilise pour lire les paramètres de suivi sur un lien marketing afin de voir exactement ce qu'une campagne passe Je l'utilise pour convertir une chaîne de requête collée par un collègue dans un chat en JSON Je peux la déposer dans un luminaire de test, et pour faire l'inverse, en transformant un petit objet en chaîne de requête pour une requête manuelle rapide.
Un exemple travaillé rend le gain concret Un fournisseur OAuth redirige vers votre application avec quelque chose comme ?code=abc123&state=xyz789&scope=read%20write&error=. Cassé dans l'analyseur, qui se résout en un objet propre : code et state comme leurs valeurs littérales, scope décodé en read write parce que %20 est un espace, et error en tant que chaîne vide plutôt qu'en tant que clé manquante, ce qui vous indique que le fournisseur a envoyé le paramètre mais l'a laissé vide En lisant cela à partir de l'URL brute à l'œil nu, vous manqueriez probablement l'espace codé scope et mal lu le vide error2, et ces deux éléments sont exactement les détails qui décident si votre gestionnaire de rappel se branche correctement. Voir la table décodée supprime l'ambiguïté, et si vous devez ensuite reproduire la requête, le mode de construction transforme votre objet modifié en une URL de rappel valide en une seule étape.
Parce qu'une grande partie de ce travail implique des URL qui transportent des jetons, des valeurs signées et des identifiants de suivi, le faire dans un outil qui s'exécute entièrement dans votre navigateur est important Rien que vous collez n'est transmis, enregistré ou stocké, et l'outil continue de travailler avec le réseau, de sorte que vous pouvez inspecter en toute sécurité une URL de rappel signée de la production plutôt qu'une copie aseptisée Je fais le plus large cas pour garder ce genre de travail côté client dans le Confidentialité des données dans les outils en ligne guide, et cet analyseur se trouve aux côtés des autres utilitaires de lien et de texte que j'ai décrits dans le Boîte à outils pour les développeurs Web. Si une partie de votre travail consiste à transformer une entrée désordonnée en slugs et identifiants propres, le Slug Générateur est un compagnon naturel pour le côté sortie du travail d'URL.
Questions fréquentes
Qu'est-ce qu'une chaîne de requête ?
Une chaîne de requête est la partie d'une URL après le point d'interrogation qui transporte des paramètres sous forme de paires clé-valeur jointes par des ampersands, tels que ?q=json& ; page=2. Les serveurs et le code client la lisent pour filtrer les résultats, suivre les campagnes ou passer l'état Chaque clé et valeur est codée par URL afin que les espaces et les caractères réservés survivent, et le fragment après un hachage n'en fait pas partie.
Comment les clés répétées sont-elles gérées lors de l'analyse ?
Par défaut, une clé qui apparaît plus d'une fois est combinée dans un tableau, donc tags=react& ;tags=laravel analyse vers {" ; tags" ; : [" ;react" ;," ;laravel" ;]}. Vous pouvez basculer pour conserver uniquement la première valeur ou seulement la dernière valeur à la place, car différents back-ends résolvent les doublons différemment et vous souhaitez que le JSON corresponde au système que vous ciblez.
Que signifient les crochets comme les balises [] ou le filtre [couleur] ?
La notation de support code les tableaux et les objets imbriqués à l'intérieur d'une chaîne de requête plate. tags []=react& ;tags []=laravel construit un tableau, et filter [color]=red& ;filter [size]=l construit l'objet imbriqué {" ; filter" ; : {" ;color" ; :" ;size" ; :" ;}}. Il est courant dans les bibliothèques PHP, Rails et formulaires, afin que l'analyseur l'étende dans la structure correspondante, et vous pouvez désactiver pour conserver les touches littérales.
Pourquoi un signe plus devient-il un espace ?
Dans la chaîne de requête d'une URL, un espace littéral est souvent codé sous forme de signe plus, une règle héritée de la soumission de formulaire HTML, de sorte que l'analyseur convertit + en un espace par défaut Si vos données contiennent des signes plus réels qui doivent être conservés, tels que C++ ou un numéro de téléphone, désactivez l'option plus-comme-espace et le plus est conservé.
Puis-je créer une chaîne de requête à partir de JSON ?
Oui. Basculez pour créer le mode et collez un objet JSON de paires clé-valeur. Le pourcentage d'outil code chaque clé et valeur et les joint à des ampersands, et vous pouvez choisir comment les tableaux sont codés : clés répétées, crochets vides, crochets indexés ou liste séparée par des virgules, de sorte que la sortie correspond à ce que le système de réception attend.
Quelle est la différence entre ceci et un analyseur d'URL complet ?
Un analyseur d'URL complet divise une URL entière en schéma, hôte, port, chemin, requête et fragment Un analyseur de chaîne de requête se concentre uniquement sur la requête, la transforme en JSON modifiable structuré comprenant des tableaux et des clés imbriquées, et peut reconstruire la requête Utilisez l'analyseur d'URL pour inspecter un lien, et cet outil pour lire ou modifier ses paramètres.
Gère-t-il une URL complète ou uniquement la partie requête ?
Les deux. Si vous collez une URL complète, l'analyseur laisse tout tomber jusqu'au point d'interrogation inclus et ignore le fragment après le hachage, vous obtenez donc uniquement les paramètres Si vous collez une chaîne de requête nue sans point d'interrogation, elle est analysée telle quelle, ce qui est pratique lorsque vous avez seulement copié les paramètres.
Mon URL est-elle envoyée quelque part ?
Non. L'analyse, le décodage et l'encodage s'exécutent tous en JavaScript dans votre navigateur, donc rien n'est transmis, enregistré ou stocké. Vous pouvez le confirmer en regardant l'onglet réseau pendant que vous analysez une URL, ou en vous déconnectant d'Internet, car l'outil continue de fonctionner hors ligne une fois la page chargée.
Inspectez ou assemblez les paramètres gratuitement Analyseur de chaînes de requête. Il analyse une URL dans JSON et construit une chaîne de requête, gérant les clés répétées, les tableaux de parenthèses et l'encodage, entièrement dans votre navigateur.
