Zum Hauptinhalt springen
ToolsByUs

JSON zu Query-String

Dieser Konverter wandelt ein JSON-Objekt in einen URL-Query-String in Ihrem Browser um. Verschachtelte Objekte verwenden die a[b]=c-Klammerkonvention, Arrays wiederholen ihren Schlüssel, Werte werden laut RFC 3986 percent-kodiert, mit Leerzeichen als %20, und null wird zu einem Schlüssel mit leerem Wert. Nichts wird hochgeladen.

Nur lokal

JSON zu Query-String erklärt

Jedes JSON-Objekt, das je als GET-Anfrage-Parameter reiste, wurde zu einer einzigen Zeile Schlüssel=Wert-Paaren abgeflacht, und das Abflachten erforderte Entscheidungen: wie Verschachtelung geschrieben wird, wie Arrays wiederholt werden, was mit null passiert. Dieser Konverter macht diese Entscheidungen explizit und konventionell – Objekte verschachteln als a[b]=c, Arrays wiederholen ihren Schlüssel, und das Ergebnis ist eine percent-kodierte Zeile, bereit zum Einfügen nach einem ?.

Keine dieser Konventionen wurde hier erfunden. Die Klammerschreibweise ist die, die PHPs http_build_query und Ruby on Rails seit zwei Jahrzehnten ausgeben, und jeder ernsthafte Query-String-Parser liest sie zurück in die Struktur. Die Kodierung folgt RFC 3986: die unreservierten Zeichen bleiben lesbar, Leerzeichen werden zu %20, und ein wörtliches Plus wird zu %2B, damit es sowohl Formular- als auch strikte Parser überlebt.

Wie überall auf dieser Seite geschieht die Arbeit im Browser-Tab, der die Seite geöffnet hat: Ihr JSON wird von Code auf der Seite geparst und kodiert, und nichts kreuzt das Netzwerk. Die Content-Security-Policy verbietet ausgehende Verbindungen kategorisch, also ist das leere Network-Panel in DevTools während der Konvertierung der ganze Privatsphäre-Anspruch, demonstriert statt behauptet.

Der String, den diese Seite erstellt, ist genau das, was der Schwesterkonverter auf der Seite zurück zu JSON dekodieren kann, also ist eine Hin-und-Rück-Fahrt ein guter Sanity-Check, bevor die URL versendet wird.

Wenn Sie nur einen einzelnen Wert escapen müssen statt ein ganzes Objekt zu strukturieren, der eigenständige URL-Kodierer und -Dekodierer handelt eine Zeichenfolge nach denselben RFC-3986-Regeln.

Wie die Kodierung tatsächlich funktioniert

Der Konverter durchläuft das geparste Objekt in Schlüsselreihenfolge und gibt ein Paar pro Element aus, mit & verbunden. Jeder Wert wird vor der Kodierung zu einer Zeichenfolge gemacht – Zahlen als reine Ziffern, Booleans als true oder false, null als leerer Wert – und dann als UTF-8 percent-kodiert. Die Strukturregeln sind:

  • Objekte: ein verschachteltes Objekt erweitert den Schlüsselpfad mit Klammern. {"user": {"name": "Ada"}} wird zu user[name]=Ada, und eine tiefere Ebene fügt eine weitere Klammergruppe hinzu: user[address][city]=London.
  • Arrays: ein Array von Skalaren wiederholt seinen Schlüssel einmal pro Element – tag=navy&tag=math – der Stil, den Rack und der qs-Parser von Node zurück in Arrays einlesen.
  • null: wird zu einem Schlüssel mit leerem Wert (token=), der den Schlüssel in der URL behält, anstatt ihn zu entfernen.
  • Leere Objekte und Arrays: geben nichts für diesen Schlüssel aus, da es kein Paar zum Schreiben gibt; das Fehlen des Schlüssels wird in der Vorschau angezeigt, damit es eine Entscheidung ist, keine Überraschung.

Percent-Kodierung, RFC-3986-Stil

RFC 3986 lässt die unreservierte Menge – A–Z, a–z, 0–9, Bindestrich, Punkt, Unterstrich und Tilde – genau geschrieben und verlangt, dass alles else byte-weise als UTF-8 percent-kodiert wird. Ein Leerzeichen ist %20, nicht +. Die Gewohnheit, Plus für Leerzeichen zu verwenden, gehört zu application/x-www-form-urlencoded, einer älteren Formkonvention, die echte Fehler verursacht: ein strikter RFC-3986-Leser dekodiert ein bloßes + als wörtliches Plus-Zeichen. Die Ausgabe von %20 für Leerzeichen und %2B für Plus-Zeichen bedeutet, dass die Ausgabe für beide Arten von Lesern dasselbe bedeutet.

Eine bewusste Ausnahme: die eckigen Klammern in Schlüsseln werden wörtlich ausgegeben, weil das die a[b]=c-Konvention im Wilden aussieht – PHP und Rails escapen sie auch nicht. Klammern sind Struktur, kein Inhalt. Werte werden streng kodiert, und der umgekehrte Dekodierer auf dieser Seite akzeptiert sowohl wörtliche als auch %5B/%5D-escapte Klammern.

Wie die Ausgabe aussieht

Das Arbeitsbeispiel unten ist das exakte Paar, das der Button Beispielladung erzeugt: Suchparameter mit einem verschachtelten user-Objekt, einem wiederholten tag-Schlüssel und einem null-Token. Die Schlüsselreihenfolge folgt dem JSON-Dokument, also ist die Neu-Kodierung eines neu-geparsten Strings stabil – dasselbe Objekt erzeugt immer dieselbe URL, was wichtig ist, wenn Sie Links vergleichen, cachen oder Tests dagegen schreiben.

Kanten, die dieser Konverter verarbeitet statt zu verzerren

Zwei Formen haben unter diesen Konventionen keine ehrliche Kodierung, und beide werden mit einem benannten Fehler abgelehnt statt einem kreativen Versuch:

  • Ein Array auf oberster Ebene – ein Query-String hat keinen schlüssellosen Slot. Packen Sie das Array in ein Objekt unter einem Schlüssel, und die Wiederholungskonvention erledigt den Rest.
  • Arrays von Objekten – tag[name]=a&tag[name]=b würde zwei Datensätze zu einem Schlüsselpfad zusammenfassen, und das Erfinden von Indizes wie tag[0][name] fügt Struktur hinzu, die Sie nie verlangt haben. Der Konverter lehnt ab und benannt den problematischen Schlüssel.

Häufig gestellte Fragen

Lädt die Konvertierung von JSON zu einem Query String irgendwo meine Daten hoch?

Nein. Das JSON wird vollständig in diesem Browser-Tab geparst und kodiert; die Seite hat keinen Upload-Endpunkt, und ihre Content-Security-Policy verbietet Verbindungen an anderer Stelle, also ist ein Datenabfluss strukturell unmöglich, nicht nur versprochen. Überzeugen Sie sich in dreißig Sekunden: Öffnen Sie DevTools, wechseln Sie zum Network-Panel, konvertieren Sie, und beobachten, dass keine Anfrage erscheint.

Warum wird ein Leerzeichen als %20 und nicht + kodiert?

Weil Plus-für-Leerzeichen die application/x-www-form-urlencoded-Konvention ist, während RFC 3986 – die URI-Grammatik selbst – %20 verlangt und ein wörtliches Plus als Plus-Zeichen behandelt. Die Kodierung mit %20 und %2B bedeutet unmissverständlich, dass form-mode- und strikte Parser Ihren Wert identisch dekodieren. Browser sind tolerant beides; das Risiko ist der strenge Leser in einer signierten URL oder einer Caching-Schicht, genau wo Mehrdeutigkeit teuer ist.

Warum verwendet die Verschachtelung die a[b]=c-Notation?

Es ist die de-facto-Standard-Klammer-Schreibweise, die von PHPs http_build_query und Ruby on Rails seit zwei Jahrzehnten ausgegeben und von Bibliotheken wie qs (Node) und Rack (Ruby) zurück in verschachtelte Struktur geparst wird. Alternativen existieren – Punkte, Doppelpunkte, wiederholte tiefe Schlüssel – aber keine hat annähernd die Leserunterstützung, und ein Austauschformat sollte für die breitesten Zielgruppe optimieren.

Wie werden Arrays kodiert, und warum keine tag[]-Schreibweise?

Arrays von Skalaren wiederholen den Schlüssel: tag=navy&tag=math. Server wie Rack und qs von Node sammeln wiederholte Schlüssel beim Parsen in Arrays, also ist die Hin-und-Rück-Konvertierung sauber. Die Ausnahme ist PHP, das tag[] braucht, um ein Array zu bauen – eine Schreibweise, die dieser Konverter nie ausgibt, weil eckige Klammern hier für Objektverschachtelung reserviert sind. Wenn PHP das Ziel ist, hängen Sie die leeren Klammern an den Schlüssel nach der Konvertierung an.

Was wird aus null, Booleans und Zahlen?

null wird zu einem Schlüssel mit leerem Wert – token= – was den Schlüssel in der URL behält. Booleans werden zum wörtlichen Text true oder false, und Zahlen werden zu reinen Dezimalziffern ohne Lokalformatierung und ohne Tausendertrennzeichen. Die leere Zeichenfolge wird auch zu einem leeren Wert; ein Query-String kann sie nicht von null unterscheiden, und der umgekehrte Dekodierer liest einen leeren Wert absichtlich als null zurück.

Welche Zeichen werden uncodiert gelassen?

Genau die unreservierte Menge von RFC 3986: A–Z, a–z, 0–9, Bindestrich, Punkt, Unterstrich und Tilde. Alles andere – Leerzeichen, Und-Zeichen, Schrägstriche, akzentuierte Buchstaben, Emoji – wird byte-weise als UTF-8 percent-kodiert. Die eckigen Klammern in Schlüsseln sind die einzige sichtbare Ausnahme, wörtlich ausgegeben, weil sie die Verschachtelungskonvention selbst sind; Werte erhalten niemals diese Behandlung.

ToolsByUs-Team · Wie wir unsere Tools prüfen