Zum Hauptinhalt springen
ToolsByUs

Query-String zu JSON

Dieser Konverter decodiert einen URL-Query-String in strukturiertes JSON in Ihrem Browser. Werte werden percent-decodiert, wobei + als Leerzeichen behandelt wird, wiederholte Schlüssel werden zu Arrays, a[b]=c-Pfade werden in verschachtelte Objekte umgewandelt, und leere Werte werden als null decodiert. Falsch formatierte Percent-Encoding wird mit der benannten Position zurückgewiesen. Nichts wird hochgeladen.

Nur lokal

Query-String zu JSON erklärt

Ein Query-String sieht aus wie ein Durcheinander – kaufmännische Und-Zeichen, Gleichheitszeichen, Prozent-Escapes – aber es ist ein Datensatz und der verdient Struktur. Dieser Decoder verwandelt einen in ein JSON-Objekt: Schlüssel vom linken Teil jedes =, Werte rechts davon decodiert, wiederholte Schlüssel zu Arrays gesammelt und a[b]=c-Pfade zu verschachtelten Objekten gefaltet. Es ist die exakte Umkehrung des JSON zu Query-String-Konverters dieser Seite, so dass das Paar rückgängig gemacht werden kann.

Zwei Konventionen sind wichtig und beide werden beachtet. Das Plus-Zeichen bedeutet ein Leerzeichen – die Gewohnheit von application/x-www-form-urlencoded, die praktisch jedes Formular, jeder Browser und jeder Server noch spricht – während %2B zu einem echten Plus decodiert wird. Und Werte bleiben Strings: Ein Query-String trägt keine Typinformation, also kommt page=2 als "2" an, ehrlich, und nicht als Vermutung, die eine Postleitzahl am Ende bestrafen würde.

Das Decodieren geschieht vollständig in diesem Browser-Tab. Der String wird von im-Code-Seite aufgeteilt und unescapt; keine Anfrage verlässt die Seite, und die Content-Security-Policy verbietet ausgehende Verbindungen kategorisch. Überprüfen Sie es im Netzwerkbereich, wenn Sie möchten – es bleibt still, und diese Stille ist die Privatsphäre-Aussage, die hält.

Den String, den Sie gerade parsen, erstellt das Schwester-Tool „JSON zu Query-String“, das dieselbe a[b]=c-Konvention ausgibt, die dieser Decoder liest.

Sobald das JSON-Output verdächtig aussieht – eine eckige Klammer, ein fehlendes Anführungszeichen – fügen Sie es in den JSON-Validator ein, und das exakte fehlerhafte Zeichen wird benannt.

Wie das Decodieren tatsächlich funktioniert

Der Konverter akzeptiert den Query-String mit oder ohne führendes ?. Er teilt an & auf, dann jedes Paar an seinem ersten =, sodass ein Schlüssel nur dann ein Gleichheitszeichen enthalten kann, wenn es percent-encoded ist – was genau der Encoder auf der anderen Seite dieses Paares tut. Dann pro Paar:

  • Decodieren: Schlüssel und Wert werden als UTF-8 percent-decodiert, mit + als Leerzeichen in Werten.
  • Verschachteln: Klammerteile in einem Schlüssel werden zu verschachtelten Objekten – user[name] landet bei {"user": {"name": ...}}, und a[user][city] verschachtelt zwei Ebenen.
  • Sammeln: Ein mehrfach vorkommender Schlüssel wird zu einem Array seiner Werte in Ankunftsreihenfolge; ein genau einmal vorkommender Schlüssel bleibt ein Skalar.
  • Leer: Ein Paar mit leer oder fehlendem Wert (token=, oder ein bloßes Token ohne =) decodiert als null.

Die Konventionen, Eingabe für Eingabe

Die folgende Tabelle ist der Vertrag des Decoders in Miniatur – jede Zeile ist eine dokumentierte Regel und kein Implementierungsunfall:

Eingabe-PaarDecodiertes JSON
page=2{"page": "2"} – ein String, keine Typvermutung
tag=navy&tag=math{"tag": ["navy", "math"]}
user[name]=Ada{"user": {"name": "Ada"}}
q=a%20b{"q": "a b"} – %20 decodiert
q=a+b{"q": "a b"} – + ist ein Leerzeichen
q=a%2Bb{"q": "a+b"} – escapedes Plus überlebt
token={"token": null}

Wie das Output aussieht

Das folgende Arbeitsbeispiel ist das exakte Paar, das der Button „Beispiel laden“ erzeugt: derselbe String, den die JSON zu Query-String-Seite ausgibt, zurückgelesen. Beachten Sie, dass page bei "2" und admin bei "true" bleibt – Strings, weil die URL nichts über Typen gesagt hat. Verbraucher, die Zahlen wollen, casten bewusst am Rand des Programms, mit dem Schema in der Hand, anstatt einer Vermutung zu vertrauen, die eine führende Null in einer Postleitzahl brechen würde.

Ablehnungen, keine Vermutungen

Fehlerhafte Escapes sind der Punkt, an dem Decodier-Tools Daten leise verfälschen, also lehnt dieser Konverter ab, anstatt zu improvisieren. Ein Prozent-Zeichen muss ein gültiges Escape beginnen – zwei hexadezimale Ziffern, die gültiges UTF-8 bilden – und alles andere erzeugt einen benannten Fehler:

  • %ZZ oder %2 – nicht hexadezimal, also benennt der Fehler den Schlüssel und die Zeichenposition, anstatt ein Prozent-Zeichen oder einen fallengelassenen Byte auszugeben.
  • %FF alleine – hexadezimal gültig, aber nicht gültiges UTF-8, also wird es abgelehnt, anstatt als Mojibake weitergegeben zu werden.
  • Ein nachfolgendes bloßes % am Ende des Strings – ein abgebrochenes Escape, das mit seiner Position abgelehnt wird, damit die Quelle korrigiert und nicht erraten werden kann.

Häufig gestellte Fragen

Wird ein Query-String beim Decodieren irgendwo hochgeladen?

Nein. Der String wird von im-Seite-JavaScript in diesem Browser-Tab aufgeteilt und decodiert. Die Seite definiert keinen API-Endpunkt, an den Daten gesendet werden können, und ihre Content-Security-Policy blockiert ausgehende Anfragen, also gibt es nichts, worauf hochgeladen werden könnte, selbst wenn der Code es versuchen würde. Öffnen Sie DevTools, decodieren Sie einen String, und der Netzwerkbereich bleibt leer – die Behauptung bestätigt sich auf einen Blick.

Warum sind alle Werte Strings?

Weil ein Query-String keine Typinformationen trägt: page=2 sind aus URL-Sicht die beiden Zeichen 2. Der Decoder lehnt es ab, zu raten, also bleibt 2 "2" und true "true" – dieselbe Politik, die der Encoder-Seite folgt. Casten Sie dort, wo das Schema bekannt ist; ein bloßes 02134, das still zur Zahl 2134 wird, ist der klassische Grund, warum Vermutungen wehtun.

Was bedeutet + beim Decodieren?

Ein Leerzeichen. Das ist die application/x-www-form-urlencoded-Konvention, die Browser und Server seit Jahrzehnten sprechen, und Query-Strings in der Wildnis stammen überwiegend aus Formularen. Ein echtes Plus muss als %2B percent-encoded ankommen – der Encoder auf dieser Seite gibt es so aus, und beide Schreibweisen werden hier identisch decodiert. Die umgekehrte Richtung ist konsistent: Leerzeichen gehen als %20, Plus-Zeichen als %2B raus.

Wie werden wiederholte Schlüssel behandelt?

Ein Schlüssel, der mehrmals vorkommt, wird zu einem Array seiner Werte in der Reihenfolge ihres Erscheinens: tag=navy&tag=math ergibt {"tag": ["navy", "math"]}. Ein genau einmal vorkommender Schlüssel bleibt ein Skalar. Das entspricht dem Verhalten von Rack und Node's qs-Parser und ist die exakte Umkehrung des Encoders dieser Seite, der den Schlüssel einmal pro Array-Element wiederholt.

Wie wird die a[b]=c-Notation decodiert?

Klammerteile werden zu verschachtelten Objekten: user[name]=Ada decodiert zu {"user": {"name": "Ada"}}, und a[user][city] verschachtelt zwei Ebenen tief. Numerische Teile bleiben String-Schlüssel – a[0] wird zum Schlüssel "0" – weil das Erstellen von Arrays aus Indizes eine Vermutung ist, die dieser Decoder ablehnt. Sowohl echte Klammern als auch ihre %5B/%5D-escapeden Formen werden akzeptiert, da Encoder an dieser Punkt variieren.

Was passiert mit einem Paar ohne Wert?

Ein leerer Wert – token=, oder ein bloßes Token ohne = überhaupt – decodiert als null und nicht als leerer String. Das ist die bewusste Umkehrung des JSON zu Query-String-Konverters dieser Seite, der null als leeren Wert ausgibt, also überlebt null den Hin- und Rückgang intakt. Wenn Sie einen leeren String von einem fehlenden Wert unterscheiden müssen, kann ein Query-String dies fundamental nicht ausdrücken.

ToolsByUs-Team · Wie wir unsere Tools prüfen