Query String Parser/Builder

Der Query String Parser/Builder konvertiert zwischen URL-Query-Strings und strukturierten Schlüssel-Wert-Paaren und behandelt URL-Kodierung, verschachtelte Objekte, Array-Notation und doppelte Schlüssel korrekt in beide Richtungen. Fügen Sie einen Query-String wie ?user[name]=alice&colors[]=red&colors[]=blue&q=hello+world ein und erhalten Sie eine übersichtliche Tabelle dekodierter Parameter, oder geben Sie Schlüssel-Wert-Paare ein und erhalten Sie einen korrekt kodierten Query-String, bereit zum Anhängen an jede URL.

URL-Query-Strings verstehen

Query-Strings sind der Teil einer URL, der nach dem ?-Zeichen kommt, und sie sind eine der häufigsten Methoden zur Datenübertragung in Webanwendungen. Jedes Mal, wenn Sie eine Produktliste filtern, ein Suchformular absenden oder einen paginierten Link anklicken, reisen die Parameter als Schlüssel-Wert-Paare im Query-String. Sie sehen an der Oberfläche einfach aus -- nur key=value-Paare verbunden durch & -- aber die Kodierungsregeln, Array-Konventionen und Randfälle machen die manuelle Bearbeitung überraschend knifflig.

Das Kernproblem ist, dass URLs einen eingeschränkten Zeichensatz haben. Leerzeichen, Ampersands, Gleichheitszeichen und die meisten Nicht-ASCII-Zeichen können nicht wörtlich in einem Query-String erscheinen, weil sie eine besondere Bedeutung haben oder in URIs nicht gültig sind. Der application/x-www-form-urlencoded-Kodierungsstandard löst dies, indem unsichere Zeichen durch prozentkodierte Sequenzen ersetzt werden (%20 für ein Leerzeichen) oder die +-Kurzschreibweise für Leerzeichen. Wenn Sie q=hello+world oder q=hello%20world in einer URL sehen, bedeuten beide, dass der Suchbegriff "hello world" ist -- aber welche Kodierung zu erwarten ist, hängt vom Kontext ab.

Zusätzlich zur Grundkodierung haben verschiedene Server-Frameworks konkurrierende Konventionen für die Übertragung strukturierter Daten wie Arrays und verschachtelter Objekte erfunden. PHP und Rails verwenden Klammer-Notation (colors[]=red&colors[]=blue), Java und Go verwenden wiederholte Schlüssel (colors=red&colors=blue), und einige Frameworks unterstützen Punkt-Notation (user.address.city=NYC). Dieses Tool erkennt alle diese Konventionen und zeigt Ihnen genau, welche Struktur der Server empfangen würde, was es unschätzbar wertvoll für das Debugging von API-Aufrufen und Webhook-Payloads macht, bei denen Probleme mit der Parameterkodierung eine häufige Fehlerquelle sind.

So parsen Sie einen Query-String

1. Fügen Sie den Query-String in das Eingabefeld ein (mit oder ohne führendes ?).
2. Klicken Sie auf Parsen, um alle Parameter in eine strukturierte Tabelle zu extrahieren.
3. Überprüfen Sie den dekodierten Wert jedes Parameters neben seiner original kodierten Form.
4. Bearbeiten Sie einzelne Werte oder kopieren Sie die strukturierte Ausgabe zur Verwendung in Ihrem Code.

So erstellen Sie einen Query-String

1. Geben Sie Schlüssel-Wert-Paare als JSON, einzeln pro Zeile (key=value) oder im Formulardatenformat ein.
2. Wählen Sie Kodierungsoptionen (Parameter sortieren, Kodierungsstandard).
3. Klicken Sie auf Erstellen, um einen korrekt kodierten Query-String zu generieren.
4. Kopieren Sie das Ergebnis und hängen Sie es an Ihre Basis-URL an.

Beispiele für Query-String-Parsing

Wann sollte man den Query String Parser/Builder verwenden

• Debugging von OAuth-Flows -- state, code, redirect_uri und Token-Parameter aus Callback-URLs extrahieren und inspizieren.
• Konstruktion von API-Anfragen -- korrekt kodierte Query-Strings für REST-APIs mit Filtern, Paginierung und Sortierparametern erstellen.
• Analyse von Marketing-Links -- UTM-Tracking-Parameter und Kampagnen-Identifikatoren aus geteilten URLs aufschlüsseln.
• Webhook-Debugging -- eingehende Webhook-Callback-URLs parsen, um zu verstehen, welche Parameter der Dienst sendet.
• Formulardaten-Inspektion -- application/x-www-form-urlencoded-POST-Body-Daten dekodieren, die das Query-String-Format verwenden.
• Migrationstests -- überprüfen, dass URL-Rewrites und Weiterleitungsregeln Query-Parameter bei Site-Migrationen korrekt beibehalten.

Wie die URL-Query-String-Kodierung funktioniert

Query-Strings folgen dem application/x-www-form-urlencoded-Kodierungsstandard, der auf der Prozentkodierung aus RFC 3986 aufbaut.

Regeln der Prozentkodierung

Zeichen, die in URLs nicht sicher sind, werden durch % gefolgt von ihrem zweistelligen Hexadezimalcode ersetzt:

Array- und verschachtelte Objekt-Notation

Verschiedene Frameworks verwenden unterschiedliche Konventionen für Arrays und Objekte in Query-Strings:

• Klammer-Notation: colors[]=red&colors[]=blue (PHP, Rails)
• Indizierte Notation: colors[0]=red&colors[1]=blue (explizite Reihenfolge)
• Wiederholte Schlüssel: colors=red&colors=blue (Java, Go)
• Verschachtelte Objekte: user[address][city]=NYC (tiefe Verschachtelung)
• Punkt-Notation: user.address.city=NYC (einige Java-Frameworks)

Häufige Kodierungsfallen

Ein häufiger Fehler in handgeschriebenen Query-Strings ist die Doppelkodierung. Wenn Sie einen Wert kodieren, der bereits kodiert ist, wird %20 zu %2520 (das % selbst wird kodiert), und der Server erhält den Literalstring %20 anstelle eines Leerzeichens. Der Parser erkennt und markiert potenzielle Doppelkodierung, sodass Sie diese Probleme sofort erkennen können.

Praktische Tipps für die Arbeit mit Query-Strings

Einer der häufigsten Fehler, den Entwickler machen, ist das Erstellen von Query-Strings durch Zeichenkettenverkettung anstatt einen geeigneten URL-Builder zu verwenden. Es scheint schnell, url + "?key=" + value zu schreiben, aber sobald value ein Ampersand, ein Leerzeichen oder ein Unicode-Zeichen enthält, ist die resultierende URL fehlerhaft. Jede wichtige Programmiersprache hat einen eingebauten URL- oder Query-String-Builder -- URLSearchParams in JavaScript, urllib.parse.urlencode in Python, http_build_query in PHP -- und Sie sollten diese immer verwenden.

Beim Debugging von API-Aufrufen achten Sie auf den Unterschied zwischen + und %20 für Leerzeichen. Beide sind in Query-Strings unter dem application/x-www-form-urlencoded-Standard gültig, verhalten sich aber in Pfadsegmenten anders. Ein + in einem URL-Pfad ist ein wörtliches Pluszeichen, kein Leerzeichen. Wenn Ihr API-Endpunkt search/hello+world im Pfad statt im Query-String erhält, ist es kein Leerzeichen -- es ist hello+world. Diese Unterscheidung verursacht subtile Fehler, wenn Parameter zwischen Pfad und Query-String verschoben werden.

Wenn Sie mit OAuth-Callback-URLs arbeiten, parsen Sie den Query-String immer ordnungsgemäß, anstatt Regex oder einfache Zeichenkettenteilung zu verwenden. OAuth-Callbacks können Base64-kodierte Token als Parameterwerte enthalten, und diese Token können Zeichen wie = und + enthalten, die naives Parsen durchbrechen. Ein ordnungsgemäßer Query-String-Parser behandelt die Kodierung korrekt und erspart Ihnen Authentifizierungsfehler, die nur bei bestimmten Token-Werten auftreten.

Häufig gestellte Fragen

Was ist der Unterschied zwischen %20 und + für Leerzeichen?

In der application/x-www-form-urlencoded-Kodierung (HTML-Formulare) werden Leerzeichen als + kodiert. In der Standard-Prozentkodierung (RFC 3986) sind Leerzeichen %20. Die meisten Server akzeptieren beides in Query-Strings, aber %20 ist technisch korrekt in Pfadsegmenten, wo + ein wörtliches Pluszeichen ist.

Wie behandle ich doppelte Schlüssel in einem Query-String?

Das Verhalten hängt von Ihrem Server-Framework ab. Die meisten Frameworks (Express.js, Django, Rails) sammeln doppelte Schlüssel in einem Array. Einige behalten nur den ersten oder letzten Wert. Der Parser zeigt alle Vorkommen an, sodass Sie genau sehen können, was gesendet wurde.

Spielt die Parameterreihenfolge in Query-Strings eine Rolle?

Technisch ist die Reihenfolge von Query-Strings gemäß der HTTP-Spezifikation signifikant. In der Praxis ignorieren die meisten Server die Reihenfolge. Wenn Sie konsistente Zeichenketten für Caching oder Vergleich benötigen, verwenden Sie die Sortieroption beim Erstellen.

Wie lang darf ein Query-String maximal sein?

Es gibt kein hartes Limit in der HTTP-Spezifikation, aber Browser und Server setzen praktische Grenzen. Die meisten Browser unterstützen URLs mit einer Gesamtlänge von etwa 2.000 Zeichen. Webserver wie Apache haben ein Standardlimit von 8.190 Bytes für die gesamte Anfragezeile (Methode + URL + HTTP-Version). Wenn Sie sich diesen Grenzen nähern, sollten Sie erwägen, Parameter stattdessen im Anfragekörper mittels POST zu übertragen.

Wie übergebe ich JSON-Daten in einem Query-String?

Sie können eine gesamte JSON-Zeichenkette als einzelnen Parameterwert kodieren: ?data=%7B%22key%22%3A%22value%22%7D. Das ist jedoch fragil und schwer zu debuggen. Für komplexe Daten ist es besser, eine POST-Anfrage mit einem JSON-Body zu verwenden. Wenn Sie GET verwenden müssen, flachen Sie das JSON in einzelne Parameter ab (?key=value&nested.field=data).

Können Query-String-Parameternamen Sonderzeichen enthalten?

Ja, aber sie müssen prozentkodiert werden. Ein Parameter namens user[name] wird in der Roh-URL als user%5Bname%5D=value gesendet. Die meisten Frameworks dekodieren dies automatisch. Der Parser zeigt sowohl die kodierte als auch die dekodierte Form an.

Verwandte Tools

• URL Parser - Vollständige URLs in Schema, Host, Port, Pfad und Query-Komponenten parsen
• URL Normalizer - URLs durch Sortieren von Parametern und Entfernen von Standardwerten normalisieren
• Bulk Add/Remove Query Params - Query-Parameter bei mehreren URLs gleichzeitig hinzufügen oder entfernen
• Cookie Header Parser - Cookie- und Set-Cookie-Header parsen, die häufig Query-basierte Anfragen begleiten
• curl Command Builder - curl-Befehle mit korrekt kodierten Query-Parametern erstellen