Aller au contenu principal
ToolsByUs

Chaîne de requête vers JSON

Ce convertit décode une chaîne de requête URL en JSON structuré dans votre navigateur. Les valeurs sont décodées avec percent-decoding, le + est traité comme un espace, les clés répétées deviennent des tableaux, les chemins a[b]=c sont imbriqués dans des objets, et les valeurs vides décodent en null. Un codage percent incorrect est rejeté avec la position nommée. Rien n’est envoyé.

100 % local

Chaîne de requête vers JSON en clair

Une chaîne de requête semble du bruit — des esperluettes, des signes égal, des échappements percent — mais c’est un enregistrement, et les enregistrements méritent une structure. Ce décodeur transforme cela en un objet JSON : les clés à gauche de chaque =, les valeurs décodées à droite, les clés répétées rassemblées en tableaux et les chemins a[b]=c repliés en objets imbriqués. C’est l’inverse exact du convertisseur JSON vers Chaîne de requête de ce site, donc le couple fait un aller-retour parfait.

Deux conventions sont importantes et toutes deux sont respectées. Le signe plus signifie un espace — la habitude application/x-www-form-urlencoded que virtuellement chaque formulaire, navigateur et serveur utilise encore — tandis que %2B se décode en un vrai plus. Et les valeurs restent des chaînes : une chaîne de requête ne transporte aucune information de type, donc page=2 arrive comme « 2 », honnêtement, plutôt qu’une supposition qu’un code postal finirait par être pénalisé.

Le décodage se produit entièrement dans cet onglet de navigateur. La chaîne est découpée et déséchappée par le code de la page ; aucune requête ne quitte la page, et la politique de sécurité du contenu interdit purement et simplement les connexions sortantes. Vérifiez-le dans le panneau Réseau si vous le souhaitez — il reste silencieux, et ce silence est la promesse de confidentialité qui tient.

Construire la chaîne que vous êtes sur le point d’analyser, c’est le travail de l’outil voisin, le convertisseur JSON vers chaîne de requête, qui émet la même convention a[b]=c que celle que lit ce décodeur.

Une fois que la sortie JSON semble suspecte — une accolade en trop, une citation manquante — collez-la dans le Validateur JSON et le caractère exact en cause est pointé.

Comment le décodage fonctionne réellement

Le convertisseur accepte la chaîne de requête avec ou sans son point d’interrogation initial ?. Il découpe sur &, puis découpe chaque paire à son premier =, donc une clé ne peut contenir un signe égal que s’il est échappé en percent — ce que l’encodeur de l’autre côté de ce couple fait exactement. Ensuite, par paire :

  • Décoder : la clé et la valeur sont décodées en UTF-8, avec + lu comme un espace dans les valeurs.
  • Imbriquer : les segments entre crochets dans une clé deviennent des objets imbriqués — user[name] atterrit à {"user": {"name": ...}}, et a[user][city] imbrique deux niveaux.
  • Rassembler : une clé vue plus d’une fois devient un tableau de ses valeurs dans l’ordre d’arrivée ; une clé vue exactement une fois reste un scalaire.
  • Vide : une paire avec une valeur vide ou manquante (token=, ou un token nu sans =) se décode en null.

Les conventions, entrée par entrée

Le tableau ci-dessous est le contrat du décodeur en miniature — chaque ligne est une règle documentée plutôt qu’un accident d’implémentation :

Entrée paireJSON décodé
page=2{"page": "2"} — une chaîne, sans devinette de type
tag=navy&tag=math{"tag": ["navy", "math"]}
user[name]=Ada{"user": {"name": "Ada"}}
q=a%20b{"q": "a b"} — %20 décodé
q=a+b{"q": "a b"} — + est un espace
q=a%2Bb{"q": "+b"} — le plus échappé survit
token={"token": null}

À quoi ressemble la sortie

L’exemple ci-dessous est la paire exacte que le bouton Charger l’exemple produit : la même chaîne que la page JSON vers Chaîne de requête émet, relue. Notez que page reste « 2 » et admin reste « true » — des chaînes, parce que l’URL n’a rien dit sur les types. Les consommateurs qui veulent des nombres castent délibérément au bord du programme, avec le schéma en main, au lieu de faire confiance à une inférence qu’un code postal avec zéro de tête casserait.

Des refus, pas des devinettes

Les échappements malformés sont là où les outils de décodage corrompent discrètement les données, donc ce converticiel refuse au lieu d’improviser. Un signe percent doit commencer un échappement valide — deux chiffres hexadécimaux formant un UTF-8 valide — et le reste provoque une erreur nommée :

  • %ZZ ou %2 — pas hexadécimal, donc l’erreur nomme la clé et la position du caractère au lieu d’émettre un percent littéral ou un octet supprimé.
  • %FF tout seul — hexadécimalement valide mais pas UTF-8 valide, donc il est rejeté plutôt que d’être livré comme mojibake en aval.
  • Un % nu à la fin de la chaîne — un échappement tronqué, rejeté avec sa position pour que la source puisse être corrigée plutôt qu' devinée.

Questions fréquentes

Le décodage d’une chaîne de requête l’envoie quelque part ?

Non. La chaîne est découpée et décodée par du JavaScript dans la page, dans cet onglet de navigateur. La page ne définit aucun point de terminaison API pour envoyer des données, et sa politique de sécurité du contenu bloque les requêtes sortantes, donc il n’y a rien à envoyer même si le code essayait. Ouvrez DevTools, convertissez une chaîne, et le panneau Réseau reste vide — la promesse se vérifie d’un seul coup d’œil.

Pourquoi toutes les valeurs sont-elles des chaînes ?

Parce qu’une chaîne de requête ne transporte aucune information de type : page=2 est les deux caractères 2 du point de vue de l’URL. Le décodeur refuse de deviner, donc 2 reste « 2 » et true reste « true » — la même politique que le côté encodeur suit. Cast là où le schéma est connu à la place ; un code postal 02134 devenant silencieusement le nombre 2134 est la raison classique pour laquelle l’inférence est nuisible.

Que signifie + lors du décodage ?

Un espace. C’est la convention application/x-www-form-urlencoded que les navigateurs et les serveurs parlent depuis des décennies, et les chaînes de requête à l’état brut proviennent quasi exclusivement de formulaires. Un plus littéral doit arriver échappé en percent comme %2B — l’encodeur de ce site l’émet ainsi, et les deux orthographes se décodent de la même manière ici. La direction inverse est cohérente : les espaces sortent en %20, les plus en %2B.

Les clés répétées sont-elles gérées ?

Une clé qui apparaît plus d’une fois devient un tableau de ses valeurs dans l’ordre où elles sont arrivées : tag=navy&tag=math donne {"tag": ["navy", "math"]}. Une clé vue exactement une fois reste un scalaire. Cela correspond au comportement des analyseurs de Rack et de Node qs, et c’est l’inverse précis de l’encodeur de ce site, qui répète la clé une fois par élément de tableau.

La notation a[b]=c est-elle décodée ?

Les segments entre crochets deviennent des objets imbriqués : user[name]=Ada se décode en {"user": {"name": "Ada"}}, et a[user][city] imbrique deux niveaux. Les segments numériques restent des clés chaîne — a[0] devient la clé « 0 » — car inventer des tableaux à partir d’indices est une devinette que ce décodeur refuse de faire. Les crochets littéraux et leurs formes échappées %5B/%5D sont acceptés, puisque les encodeurs diffèrent sur ce point.

Que devient une paire sans valeur ?

Une valeur vide — token=, ou un token nu sans = du tout — se décode en null plutôt qu’en une chaîne vide. C’est l’inverse délibéré du convertisseur JSON vers Chaîne de requête de ce site, qui émet null comme une valeur vide, donc null survit à l’aller-retour intact. Si vous besoin de distinguer une chaîne vide d’une valeur absente, une chaîne de requête ne peut fondamentalement pas exprimer la différence.

Équipe ToolsByUs · Comment nous vérifions nos outils