JSON zu GET-Parametern

Lokale Verarbeitung

app.querystring.view

Daten auch über #data={"name":"Ada"} oder #url=... einfügen; nach dem Lesen wird die Adressleiste geleert.

Objekt und URL-Query in beide Richtungen. GET bauen oder Adressleisten-Parameter nach JSON, ohne von Hand & und Encoding zu zählen. Nested Objekte möglichst als Keys mit Klammern.

JSON → query

Nesting möglichst als a[b]=c oder ähnliche Keys. Arrays mit Indizes – Abgleich mit Backend-Binding.

Umlaute/Nicht-ASCII und Leerzeichen nach URL-Encoding.

query → JSON

Wandeln Sie page=1&q=json zurück zum Objekt. Query aus Adressleiste oder Capture kopieren.

Wiederholte Keys nach der Parser-Logik dieser Seite; komplexe Wiederholungen stichprobenartig prüfen.

Lokal

Die volle URL geht nicht zu uns. Auch Intranet-API-Parameter debuggen.

POST mit JSON-Body braucht diese Seite nicht – einfach formatieren.

Beispiel

JSON

{"page":1,"q":"json","tags":["a","b"]}

Query-String (Beispiel)

page=1&q=json&tags=a&tags=b

Leerzeichen und Nicht-ASCII?

Nach URL-Encoding. Vor dem Zurück in die Adressleiste Server-Dekodierung abstimmen.

Auch bei POST-JSON?

JSON-Body: formatieren; diese Seite für Query-Strings.

PHP-/Rails-Klammern-Keys?

Möglichst als nested Objekte. Weicht das Framework ab, Doku prüfen und anpassen.

Parameter hinter Hash (#)?

Diese Seite behandelt die Query nach ? . SPAs mit State im Hash: nur den Query-Teil kopieren.

Empfohlener Ablauf

JSON → GET oder GET → JSON wählen.
Objekt oder Query einfügen, Ergebnis prüfen.
Query an die API-URL hängen oder JSON in Tests einfügen.
Zeichensalat durch Encoding: mit Server- decodeURIComponent / Framework-Binding abgleichen.

GET hat Längenlimits. Viele Parameter oder große JSON-Blöcke: POST-Body, nicht alles in die Query.