Analyseur/Constructeur de chaîne de requête

Analyser et construire des chaînes de requête URL

L'outil Query String Parser/Builder convertit dans les deux sens entre les chaînes de requête URL et les paires clé-valeur structurées, en gérant correctement l'encodage URL, les objets imbriqués, la notation de tableaux et les clés dupliquées. Collez une chaîne de requête comme ?user[name]=alice&colors[]=red&colors[]=blue&q=hello+world et obtenez un tableau clair de paramètres décodés, ou saisissez des paires clé-valeur et obtenez une chaîne de requête correctement encodée prête à être ajoutée à n'importe quelle URL.

Comprendre les chaînes de requête URL

Les chaînes de requête sont la partie d'une URL qui suit le caractère ?, et elles constituent l'un des moyens les plus courants de transmettre des données dans les applications web. Chaque fois que vous filtrez une liste de produits, soumettez un formulaire de recherche ou cliquez sur un lien paginé, les paramètres voyagent sous forme de paires clé-valeur dans la chaîne de requête. Elles semblent simples en apparence -- juste des paires key=value jointes par & -- mais les règles d'encodage, les conventions de tableaux et les cas limites les rendent étonnamment complexes à manipuler manuellement.

Le problème fondamental est que les URL ont un jeu de caractères restreint. Les espaces, les esperluettes, les signes égal et la plupart des caractères non-ASCII ne peuvent pas apparaître littéralement dans une chaîne de requête car ils ont une signification spéciale ou ne sont pas valides dans les URI. Le standard d'encodage application/x-www-form-urlencoded gère cela en remplaçant les caractères non sûrs par des séquences encodées en pourcentage (%20 pour un espace) ou le raccourci + pour les espaces. Quand vous voyez q=hello+world ou q=hello%20world dans une URL, les deux signifient que le terme de recherche est "hello world" -- mais savoir quel encodage attendre dépend du contexte.

Au-delà de l'encodage de base, différents frameworks serveur ont inventé des conventions concurrentes pour passer des données structurées comme les tableaux et les objets imbriqués. PHP et Rails utilisent la notation entre crochets (colors[]=red&colors[]=blue), Java et Go utilisent les clés répétées (colors=red&colors=blue), et certains frameworks supportent la notation par points (user.address.city=NYC). Cet outil reconnaît toutes ces conventions et vous montre exactement quelle structure le serveur recevrait, ce qui le rend inestimable pour le débogage des appels API et des payloads de webhooks où les problèmes d'encodage des paramètres sont une source fréquente de bugs.

Comment analyser une chaîne de requête

  1. Collez la chaîne de requête dans le champ de saisie (avec ou sans le ? initial).
  2. Cliquez sur Parse pour extraire tous les paramètres dans un tableau structuré.
  3. Examinez la valeur décodée de chaque paramètre à côté de sa forme encodée originale.
  4. Modifiez les valeurs individuelles ou copiez la sortie structurée pour l'utiliser dans votre code.

Comment construire une chaîne de requête

  1. Saisissez les paires clé-valeur en JSON, une par ligne (key=value) ou en format form data.
  2. Sélectionnez les options d'encodage (tri des paramètres, standard d'encodage).
  3. Cliquez sur Build pour générer une chaîne de requête correctement encodée.
  4. Copiez le résultat et ajoutez-le à votre URL de base.

Exemples d'analyse de chaînes de requête

Chaîne de requête en entréeClé analyséeValeur analysée
?name=John%20DoenameJohn Doe
?q=hello+worldqhello world
?colors[]=red&colors[]=bluecolors[]["red", "blue"]
?user[name]=alice&user[role]=adminuser[name], user[role]alice, admin
?tag=js&tag=reacttag (doublon)["js", "react"]
?redirect=https%3A%2F%2Fexample.com%2Fpathredirecthttps://example.com/path
?price=9.99&currency=%E2%82%ACcurrency€

Quand utiliser le parseur/constructeur de chaînes de requête

  • Débogage de flux OAuth -- Extrayez et inspectez les paramètres state, code, redirect_uri et token depuis les URL de callback.
  • Construction de requêtes API -- Construisez des chaînes de requête correctement encodées pour les API REST avec filtres, pagination et paramètres de tri.
  • Analyse de liens marketing -- Décomposez les paramètres de tracking UTM et les identifiants de campagne depuis les URL partagées.
  • Débogage de webhooks -- Analysez les URL de callback des webhooks entrants pour comprendre les paramètres envoyés par le service.
  • Inspection de données de formulaire -- Décodez les données POST au format application/x-www-form-urlencoded qui utilisent le format de chaîne de requête.
  • Tests de migration -- Vérifiez que les réécritures d'URL et les règles de redirection préservent correctement les paramètres de requête lors des migrations de sites.

Fonctionnement de l'encodage des chaînes de requête URL

Les chaînes de requête suivent le standard d'encodage application/x-www-form-urlencoded, qui s'appuie sur le percent-encoding de la RFC 3986.

Règles du percent-encoding

Les caractères non sûrs dans les URL sont remplacés par % suivi de leur code hexadécimal à deux chiffres :

CaractèreForme encodéeRaison
Espace%20 ou +Délimiteur dans de nombreux contextes
&%26Sépare les paires clé-valeur
=%3DSépare la clé de la valeur
#%23Début de l'identifiant de fragment
/%2FSéparateur de chemin
@%40Utilisé dans le composant d'autorité

Notation des tableaux et objets imbriqués

Différents frameworks utilisent des conventions différentes pour les tableaux et objets dans les chaînes de requête :

  • Notation entre crochets : colors[]=red&colors[]=blue (PHP, Rails)
  • Notation indexée : colors[0]=red&colors[1]=blue (ordonnancement explicite)
  • Clés répétées : colors=red&colors=blue (Java, Go)
  • Objets imbriqués : user[address][city]=NYC (imbrication profonde)
  • Notation par points : user.address.city=NYC (certains frameworks Java)

Pièges courants de l'encodage

Un bug fréquent dans les chaînes de requête construites manuellement est le double encodage. Si vous encodez une valeur déjà encodée, %20 devient %2520 (le % lui-même est encodé), et le serveur reçoit la chaîne littérale %20 au lieu d'un espace. Le parseur détecte et signale les potentiels doubles encodages pour que vous puissiez repérer ces problèmes immédiatement.

Conseils pratiques pour travailler avec les chaînes de requête

L'une des erreurs les plus courantes des développeurs consiste à construire les chaînes de requête par concaténation de chaînes plutôt qu'en utilisant un constructeur d'URL approprié. Il semble rapide d'écrire url + "?key=" + value, mais dès que value contient une esperluette, un espace ou un caractère Unicode, l'URL résultante est malformée. Chaque langage majeur dispose d'un constructeur d'URL ou de chaîne de requête intégré -- URLSearchParams en JavaScript, urllib.parse.urlencode en Python, http_build_query en PHP -- et vous devriez toujours les utiliser.

Lors du débogage d'appels API, prêtez attention à la différence entre + et %20 pour les espaces. Les deux sont valides dans les chaînes de requête selon le standard application/x-www-form-urlencoded, mais ils se comportent différemment dans les segments de chemin. Un + dans le chemin d'une URL est un signe plus littéral, pas un espace. Si votre endpoint API reçoit search/hello+world dans le chemin plutôt que dans la chaîne de requête, ce n'est pas un espace -- c'est hello+world. Cette distinction cause des bugs subtils lors du déplacement de paramètres entre le chemin et la chaîne de requête.

Si vous travaillez avec des URL de callback OAuth, analysez toujours la chaîne de requête plutôt que d'utiliser des expressions régulières ou du découpage de chaînes. Les callbacks OAuth peuvent contenir des tokens encodés en base64 comme valeurs de paramètres, et ces tokens peuvent inclure des caractères comme = et + qui cassent une analyse naïve. Un parseur de chaîne de requête approprié gère l'encodage correctement et vous épargne des bugs d'authentification qui n'apparaissent qu'avec certaines valeurs de tokens.

Questions fréquentes

Quelle est la différence entre %20 et + pour les espaces ?

En encodage application/x-www-form-urlencoded (formulaires HTML), les espaces sont encodés en +. En percent-encoding standard (RFC 3986), les espaces sont %20. La plupart des serveurs acceptent les deux dans les chaînes de requête, mais %20 est techniquement correct dans les segments de chemin où + est un signe plus littéral.

Comment gérer les clés dupliquées dans une chaîne de requête ?

Le comportement dépend de votre framework serveur. La plupart des frameworks (Express.js, Django, Rails) regroupent les clés dupliquées dans un tableau. Certains ne conservent que la première ou la dernière valeur. Le parseur affiche toutes les occurrences pour que vous puissiez voir exactement ce qui a été envoyé.

L'ordre des paramètres a-t-il une importance dans les chaînes de requête ?

Techniquement, l'ordre des chaînes de requête est significatif selon la spécification HTTP. En pratique, la plupart des serveurs ignorent l'ordre. Si vous avez besoin de chaînes cohérentes pour le cache ou la comparaison, utilisez l'option de tri lors de la construction.

Quelle est la longueur maximale d'une chaîne de requête ?

Il n'y a pas de limite stricte dans la spécification HTTP, mais les navigateurs et les serveurs imposent des limites pratiques. La plupart des navigateurs supportent des URL d'environ 2 000 caractères au total. Les serveurs web comme Apache limitent par défaut la ligne de requête entière (méthode + URL + version HTTP) à 8 190 octets. Si vous approchez de ces limites, envisagez de déplacer les paramètres dans le corps de la requête en utilisant POST au lieu de GET.

Comment passer des données JSON dans une chaîne de requête ?

Vous pouvez encoder une chaîne JSON entière comme valeur d'un seul paramètre : ?data=%7B%22key%22%3A%22value%22%7D. Cependant, c'est fragile et difficile à déboguer. Pour des données complexes, il est préférable d'utiliser une requête POST avec un corps JSON. Si vous devez utiliser GET, aplatissez le JSON en paramètres individuels (?key=value&nested.field=data).

Les noms de paramètres de chaîne de requête peuvent-ils contenir des caractères spéciaux ?

Oui, mais ils doivent être encodés en pourcentage. Un paramètre nommé user[name] est envoyé sous la forme user%5Bname%5D=value dans l'URL brute. La plupart des frameworks décodent cela automatiquement. Le parseur affiche à la fois les formes encodée et décodée.

Outils associés

  • URL Parser - Analyser les URL complètes en composants schéma, hôte, port, chemin et requête
  • URL Normalizer - Normaliser les URL en triant les paramètres et en supprimant les valeurs par défaut
  • Bulk Add/Remove Query Params - Ajouter ou supprimer des paramètres de requête sur plusieurs URL à la fois
  • Cookie Header Parser - Analyser les en-têtes Cookie et Set-Cookie qui accompagnent souvent les requêtes basées sur les chaînes de requête
  • curl Command Builder - Construire des commandes curl avec des paramètres de requête correctement encodés
IPparse•Outils de calcul réseau et sous-réseau gratuits

© 2026 IPparse. All tools run locally in your browser.

100% Privacy-First • No Data Collected