Aller au contenu principal
ToolsByUs

JSON vers chaîne de requête

Ce convertit encode un objet JSON en chaîne de requête URL dans votre navigateur. Les objets imbriqués utilisent la convention avec crochets a[b]=c, les tableaux répètent leur clé, les valeurs sont encodées en pourcentage selon la RFC 3986 avec les espaces comme %20, et null devient une clé avec une valeur vide. Rien n’est envoyé.

100 % local

JSON vers chaîne de requête en clair

Chaque objet JSON qui a été envoyé en tant que paramètres de requête GET a été aplati en une seule ligne de paires clé=valeur, et ce processus implique des choix : comment l’imbrication est représentée, comment les tableaux répètent leur clé, et ce qui advient de null. Ce convertisseur explicite ces choix de manière conventionnelle — les objets s’imbriquent comme a[b]=c, les tableaux répètent leur clé, et le résultat est une seule ligne encodée en pourcentage, prête à être collée après un ?.

Aucune de ces conventions n’a été inventée ici. Le style avec crochets est celui émis par http_build_query de PHP et par Ruby on Rails depuis deux décennies, et chaque analyseur sérieux de chaîne de requête le réinterprète en structure. L’encodage suit la RFC 3986 : les caractères non réservés restent lisibles, les espaces deviennent %20, et un plus littéral devient %2B pour survivre aux analyseurs en mode formulaire et stricts.

Comme partout sur ce site, le travail s’effectue dans l’onglet qui a ouvert la page : votre JSON est analysé et encodé par le code de la page, et rien ne traverse le réseau. La Content-Security-Policy interdit purement et simplement les connexions sortantes, donc le fait que le panneau Réseau de DevTools reste vide pendant la conversion est la preinte même de la promesse de confidentialité, démontrée plutôt qu’affirmée.

La chaîne que cette page construit est exactement ce que le convertisseur frère du site peut le décoder en JSON donc un aller-retour est un bon test de cohérence avant que l’URL ne soit envoyée.

Si vous avez seulement besoin d’échapper une seule valeur plutôt que de structurer un objet complet, l’outil encodeur et décodeur URL gère une chaîne à la fois selon les mêmes règles de la RFC 3986.

Comment l’encodage fonctionne réellement

Le convertisseur parcourt l’objet analysé dans l’ordre des clés et émet une paire par élément, jointes par des &. Chaque valeur est transformée en chaîne avant encodage — les nombres comme chiffres simples, les booléens comme true ou false, null comme une valeur vide — puis encodée en pourcentage en UTF-8. Les règles de structure sont :

  • Objets : un objet imbriqué étend le chemin de la clé avec des crochets. {"user": {"name": "Ada"}} devient user[name]=Ada, et un niveau plus profond ajoute un autre groupe de crochets : user[address][city]=London.
  • Tableaux : un tableau de scalaires répète sa clé pour chaque élément — tag=navy&tag=math — le style que Rack et l’analyseur qs de Node réinterprètent en tableaux.
  • null : devient une clé avec une valeur vide (token=), ce qui maintient la clé présente dans l’URL plutôt que de la supprimer.
  • Objets et tableaux vides : ne produisent rien pour cette clé, car il n’y a pas de paire à écrire ; l’absence de la clé est indiquée dans l’aperçu, c’est donc une décision, pas une surprise.

Encodage en pourcentage, style RFC 3986

La RFC 3986 laisse l’ensemble des caractères non réservés — A–Z, a–z, 0–9, trait d’union, point, tiret bas et tilde — tels quels et exige que tout le reste soit encodé en pourcentage, octet par octet, en UTF-8. Un espace est %20, pas +. L’habitude du plus pour les espaces appartient à application/x-www-form-urlencoded, une convention de formulaire plus ancienne qui cause encore des bogues réels : un lecteur RFC 3986 strict décode un + comme un signe plus littéral. Émettre %20 pour les espaces et %2B pour les plus signifie que la sortie interprétée de la même manière par les deux types de lecteurs.

Une exception délibérée : les crochets dans les clés sont émis littéralement, car c’est ainsi que la convention a[b]=c apparaît dans la nature — PHP et Rails ne les échappent pas non plus. Les crochets sont de la structure, pas du contenu. Les valeurs sont strictement encodées, et le décodeur inverse de ce site accepte à la fois les crochets littéraux et ceux échappés en %5B/%5D.

À quoi ressemble la sortie

L’exemple ci-dessous est la paire exacte que produit le bouton Charger un exemple : des paramètres de recherche avec un objet utilisateur imbriqué, une clé tag répétée et un token null. L’ordre des clés suit le document JSON, donc réencoder une chaîne réanalysée est stable — le même objet produit toujours la même URL, ce qui est important lorsque vous comparez des liens, mettez en cache ou écrivez des tests avec.

Cas de figure que ce convertisseur refuse plutôt que de maltraiter

Deux formes n’ont pas d’encodage honnête selon ces conventions, et les deux sont rejetées avec une erreur nommée au lieu d’une supposition créative :

  • Un tableau de niveau supérieur — une chaîne de requête n’a pas de case sans clé. Enveloppez le tableau dans un objet sous une clé, et la convention de répétition fera le reste.
  • Des tableaux d’objets — tag[name]=a&tag[name]=b fusionnerait deux enregistrements en un seul chemin de clé, et inventer des indices comme tag[0][name] ajouterait une structure que vous n’avez jamais demandée. Le convertisseur refuse et nomme la clé problématique.

Questions fréquentes

La conversion de JSON en chaîne de requête envoie-t-elle mes données quelque part ?

Non. Le JSON est analysé et encodé entièrement dans cet onglet de navigateur ; la page n’envoie aucun point de terminaison, et sa Content-Security-Policy interdit les connexions ailleurs, donc l’exfiltration est structurellement impossible plutôt que simplement promise. Vérifiez-le en trente secondes : ouvrez DevTools, passez au panneau Réseau, convertissez, et observez qu’aucune requête n’apparaît.

Pourquoi un espace est-il encodé comme %20 et pas comme + ?

Car le plus pour les espaces est la convention application/x-www-form-urlencoded, alors que la RFC 3986 — la grammaire URI elle-même — exige %20 et traite un + littéral comme un signe plus. Encodé en %20 et %2B, la valeur signifie la même chose pour les analyseurs en mode formulaire et stricts. Les navigateurs sont tolérants des deux côtés ; le risque est l’analyseur strict dans une URL signée ou une couche de cache, et c’est précisément là que l’ambiguïté est coûteuse.

Pourquoi l’imbrication utilise-t-elle la notation a[b]=c ?

C’est la convention standard avec crochets, émise par http_build_query de PHP et par Ruby on Rails depuis deux décennies, et réinterprétée en structure imbriquée par des bibliothèques comme qs (Node) et Rack (Ruby). D’autres alternatives existent — points, deux-points, clés profondes répétées — mais aucune n’a un support de lecteur à l’échelle, et un format d’échange devrait optimiser pour le plus grand nombre.

Comment les tableaux sont-ils encodés, et pourquoi pas la notation tag[] ?

Les tableaux de scalaires répètent la clé : tag=navy&tag=math. Des serveurs comme Rack et l’analyseur qs de Node regroupent les clés répétées en tableaux à l’analyse, donc l’aller-retour est propre. L’exception est PHP, qui a besoin de tag[] pour construire un tableau — une notation que ce convertisseur n’émet jamais, car les crochets sont réservés à l’imbrication d’objets ici. Si la destination est PHP, ajoutez les crochets vides à la clé après conversion.

Que deviennent null, les booléens et les nombres ?

null devient une clé avec une valeur vide — token= — ce qui maintient la clé présente dans l’URL. Les booléens deviennent le texte littéral true ou false, et les nombres deviennent des chiffres décimaux simples, sans formatage local ni séparateurs de milliers. La chaîne vide devient aussi une valeur vide ; une chaîne de requête ne peut pas la distinguer de null, et le décodeur inverse lit une valeur vide comme null par conception.

Quels caractères laissent-on non encodés ?

Exactement l’ensemble des caractères non réservés de la RFC 3986 : A–Z, a–z, 0–9, trait d’union, point, tiret bas et tilde. Tout le reste — espaces, esperluettes, barres obliques, lettres accentuées, emoji — est encodé en pourcentage, octet par octet, en UTF-8. Les crochets dans les clés sont la seule exception visible, émis littéralement car ils sont la convention d’imbrication elle-même ; les valeurs ne sont jamais traitées ainsi.

Équipe ToolsByUs · Comment nous vérifions nos outils