Query-String-Parser

Query-Strings einer URL transportieren Filter, Kampagnen-Tags, Paginierung und Formularfelder hinter dem Fragezeichen einer Adresse. Sie von Hand zu lesen ist fehleranfällig: Leerzeichen erscheinen als Pluszeichen oder als percent-twenty, Ampersands trennen Felder, das Gleichheitszeichen trennt Namen von Werten, und ein defekter Prozent-Escape kann eine ganze Protokollzeile vergiften. Dieser Query-String-Parser wandelt in beiden Richtungen mit einem einzigen Vertrag um. Der Parse-Modus akzeptiert eine rohe Query (mit oder ohne führendes Fragezeichen), dekodiert jeden Schlüssel und Wert und liefert eine geordnete Paarliste sowie eine einfache Objektmappe für eindeutige Schlüssel. Der Serialize-Modus akzeptiert dieselben Paare oder eine flache Objektmappe und erzeugt einen korrekt prozentkodierten Query-String, bereit zum Anhängen an einen Pfad.

Wie Query-Strings Schlüssel-Wert-Paare kodieren

Ein typisches Query-Fragment sieht aus wie name equals Ada ampersand city equals New percent-twenty York. Das Ampersand ist der Feldtrenner; das erste Gleichheitszeichen in jedem Feld trennt den Parameternamen von seinem Wert. Werte (und manchmal Namen) werden prozentkodiert, damit Leerzeichen, Ampersands, Nicht-ASCII-Buchstaben und reservierte Zeichen den Transit durch Browser, Proxys und Analyse-Tools überstehen.

Viele Server behandeln ein nacktes Plus unter den application/x-www-form-urlencoded-Regeln von HTML-Formularen ebenfalls als Leerzeichen; diese Fähigkeit tut das standardmäßig beim Parsen, und Sie können es deaktivieren, wenn Sie ein literales Plus brauchen. Leere Felder durch abschließende oder doppelte Ampersands werden übersprungen, damit keine leeren Phantomschlüssel entstehen. Ein Parameter ohne Gleichheitszeichen gilt als Schlüssel mit leerem String-Wert, wie bei gängigen Serverbibliotheken.

Erscheint derselbe Schlüssel mehrfach, bleibt jedes Vorkommen in der geordneten Paarliste erhalten, damit Mehrfachfilter und wiederholte Tags nicht verloren gehen; die begleitende Objektmappe nutzt last-wins, damit einfache Clients weiterhin ein flaches Wörterbuch erhalten. Die Kodierung nutzt encodeURIComponent für jeden Schlüssel und Wert, damit reservierte Trenner nie in die zusammengebaute Zeichenkette lecken.

Wo ein Query-String-Parser seinen Nutzen zeigt

Backend-Dienste, die eingehende Anfragen protokollieren, brauchen eine zuverlässige Möglichkeit, den Suchteil einer URL in strukturierte Felder für Metriken und Support-Tools zu verwandeln, ohne einen Einmal-Splitter zu schreiben, der Pluszeichen oder Unicode falsch behandelt. Frontend-Apps, die Filter-Chips aus dem aktuellen location search neu aufbauen, brauchen geordnete Paare, damit Mehrwert-Facetten einen Encode-Decode-Roundtrip überstehen. QA- und CI-Pipelines vergleichen goldene Query-Vektoren über Node und Browser, damit ein Leerzeichen beim Encode stets percent-twenty ist und ein Plus in form-artigem Input beim Parse weiterhin ein Leerzeichen wird.

Support-Teams fügen halbkodierte Links aus Tickets ein und brauchen einen Decoder, der bei abgeschnittenen Escapes klar scheitert statt Zeichen zu erfinden. Curriculum-Autoren, die Web-Grundlagen lehren, wollen eine eigene Landing zum Lesen und Schreiben von Query-Parametern, statt das Thema unter einem generischen Prozent-Encoder oder UTM-Builder zu vergraben, weil die Suchintention anders ist: Wer einen Query-String-Parser sucht, will Struktur, nicht nur Zeichen-Escape. Fehlgeschlagene Validierung wird nicht berechnet.

Halten Sie Anfragen unter den dokumentierten Längenlimits, fixieren Sie die geordneten Paare in Tests, und Sie erhalten reproduzierbare Parameter-Maps für Dashboards, LMS-Plugins und Edge-Worker, ohne ein vollständiges URL-Toolkit selbst aufzubauen.