URL Parser

Den URL-Parser verwenden

1. Eine URL einfügen in das Eingabefeld. Der Parser ist tolerant: Schemata sind optional (er setzt https:// davor), Query-Strings können prozent-kodiert sein, und Benutzerinformationen (user:password@host) werden erkannt.
2. Die strukturellen Felder inspizieren. Die Feldertabelle zerlegt die URL in Protokoll, Origin, Hostname, Port, Pfadname, Search, Hash und vollständige URL. Jedes Feld hat einen eigenen Kopierbutton, damit du eines herausgreifen kannst, ohne um die anderen herum zu markieren.
3. Die Query-Parameter lesen. Der Parser dekodiert den Query-String und gibt ihn als Schlüssel/Wert-Tabelle aus. Doppelte Schlüssel werden beibehalten und als separate Zeilen angezeigt, genau wie der URL-Standard es vorschreibt.
4. Pfadsegmente durchsuchen. Hierarchische Pfadnamen werden an "/" aufgetrennt und als nummerierte Liste angezeigt, was nützlich ist, wenn man über REST-Route-Matcher nachdenkt.
5. Das gesamte Ergebnis als JSON kopieren, wenn du eine geparste URL in einen Issue-Tracker, einen Code-Review-Kommentar oder ein Test-Fixture einfügen möchtest. Die JSON-Ausgabe fasst doppelte Query-Parameter zu einem einzigen Schlüssel zusammen, um mit Standard-JSON-Verbrauchern kompatibel zu sein.

Was der Parser tatsächlich tut

Die Implementierung ist ein dünner Wrapper um den WHATWG-URL-Konstruktor. Der eingebaute new URL(input) des Browsers implementiert den WHATWG-URL-Standard - denselben Parser, den alle großen Browser für die Auflösung von <a href>, die fetch()-API und das Service-Worker-Route-Matching verwenden. Ihn von der Seite aus aufzurufen liefert dir genau dasselbe Parse-Ergebnis, das dein Anwendungscode sehen würde, was wichtig ist, wenn du "Warum trifft meine Route nicht zu"-Probleme debuggst. Der Parser liest dann die strukturellen Eigenschaften (protocol, host, hostname, port, pathname, search, hash, origin, username, password) und gibt sie in einer Tabelle aus. Der Query-String wird mit URLSearchParams iteriert, um dir eine Zeile pro Schlüssel-Wert-Paar zu geben, wobei doppelte Schlüssel und die ursprüngliche Reihenfolge beibehalten werden. Es sind keine regulären Ausdrücke beteiligt und es gibt kein benutzerdefiniertes Parsen - wir verlassen uns auf die eingebaute Implementierung des Browsers, weil sie die maßgebliche Spezifikation ist und weil regex-basierte URL-Parser ein bekanntes Anti-Pattern sind.

Warum ein Browser-basierter URL-Parser nützlich ist

Der häufigste Grund, warum Menschen einen URL-Parser suchen, ist das Debuggen von Routing. Eine Anfrage verhält sich anders als erwartet, die URL sieht an der Oberfläche gut aus, und du musst sehen, was der Server tatsächlich empfangen wird. Wenn du die URL in den Parser eingibst, siehst du den normalisierten Pfadnamen (mit dem impliziten abschließenden "/", das der Browser hinzufügen würde), die tatsächlich dekodierten Query-Parameter und den Hash, der den Server überhaupt nicht erreicht. Ein weiterer häufiger Anwendungsfall ist das Prüfen von Analytics-URLs - Marketingteams erzeugen oft URLs mit Ketten von UTM-Parametern, manchmal mit überlappenden utm_content-Werten aus verschiedenen Quellen, und die Pro-Parameter-Tabelle macht die Überlappung sichtbar. Ein dritter Fall ist das Debuggen von OAuth- und SSO-Weiterleitungen, bei denen die Parameter state, code und nonce sicherheitsrelevante Informationen tragen und vor dem Einfügen in einen Fehlerbericht inspiziert werden müssen.

Datenschutz und Sicherheit

Der Parser läuft vollständig in deinem Browser. Es gibt keinen fetch-Aufruf, keine Telemetrie auf dem Parse-Pfad, und nach dem Verlassen der Seite wird keine Kopie der URL aufbewahrt. Das ist wichtig, weil URLs häufig sensibles Material enthalten: Einmalige Anmeldetoken in ?code=...-Parametern, signierte Weiterleitungs-URLs mit HMAC-Signaturen, vorsignierte Cloudflare R2- oder S3-URLs, die das Geheimnis als Teil des Query-Strings preisgeben, und OAuth-Callback-URLs mit Refresh-Tokens. Das Einfügen von solchen URLs in einen gehosteten "Online-URL-Parser" ist ein echtes Risiko, weil die meisten solcher Dienste Abfragen für Analytics protokollieren. Durch lokales Ausführen umgehen wir dieses Risiko: Selbst wenn die gesamte ZeroUtil-Website morgen offline gehen würde, würde der Parser auf bereits geladenen Seiten weiterarbeiten, weil der URL-Standard Teil des Browsers ist und kein serverseitiger Dienst. Das Passwortfeld wird in der Ansicht auch geschwärzt, um das Teilen des geparsten Ergebnisses per Bildschirmübertragung sicherer zu machen.

Häufige Fallstricke beim Umgang mit URLs

• Vergessen, dass der Hash den Server nicht erreicht. Alles nach dem "#" bleibt im Browser. Wenn du dort ein Token zur "Tarnung" platzierst, befindet sich das Token noch in der Adressleiste, aber es gelangt nie in deine Server-Protokolle. Das ist manchmal nützlich (impliziter OAuth-Fluss) und manchmal ein Fallstrick (du kannst es beim serverseitigen Rendering nicht lesen).
• Die Reihenfolge von Query-Parametern als semantisch behandeln. Viele APIs behandeln ?a=1&b=2 und ?b=2&a=1 als äquivalent. CDN-Caching-Schlüssel können jedoch reihenfolgeabhängig sein - inspiziere mit dem Parser, um die Reihenfolge zu sehen, die deine URL tatsächlich trägt.
• Einen einzelnen Wert pro Query-Schlüssel annehmen. ?tag=a&tag=b sind zwei Werte. URLSearchParams.get() gibt den ersten zurück; URLSearchParams.getAll() gibt beide zurück. Wenn dein Framework nur get() verwendet, wird der zweite Wert still verworfen. Der Parser zeigt beide Zeilen, damit du das Problem erkennst.
• URLs mit regulären Ausdrücken parsen. Real-World-URLs enthalten prozent-kodierte Bytes, IPv6-Hosts mit eckigen Klammern, Benutzerinformationen, ungewöhnliche Schemata und abschließende Punkte in Hostnamen. Regex-basierte URL-Extraktion scheitert an jedem dieser Fälle. Verwende einen echten Parser.
• Dem angezeigten Hostnamen für Sicherheitsentscheidungen vertrauen. Browser normalisieren IDN-Homographienangriffe (xn--... Punycode), aber wenn du die gerenderte Version aus dem Kontext kopierst, kannst du getäuscht werden. Der Parser zeigt den kanonischen normalisierten Hostnamen für die Sicherheitsprüfung.

Begleitwerkzeuge

Sobald die URL geparst ist, umfasst der nächste Schritt normalerweise eines von einigen nahe gelegenen Werkzeugen. Der URL Encoder / Decoder behandelt die Prozent-Kodierung in beide Richtungen - nützlich wenn du einen Wert in einen Query-String schreiben oder einen rohen kodierten Blob auslesen möchtest. Der Bulk URL Encoder / Decoder macht dasselbe für viele URLs auf einmal, was für SEO-Audits praktisch ist. Der Regex-Tester ist der richtige Ort, um ein robustes URL-Extraktionsmuster für Log-Scraping zu entwerfen. Zum Inspizieren einer URL, die in JSON landet, zeigt der JSON-Formatierer die umgebende Nutzlast mit der URL im Kontext. Zusammen bilden sie ein kleines Cluster von Werkzeugen, die den Lebenszyklus "eine URL sehen, verstehen, umwandeln, mit Metadaten umgeben" abdecken.

URL-Standards und Spezifikationsreferenzen

Der WHATWG-URL-Living-Standard ist die aktuelle Autorität für URL-Parsen. Er ersetzt RFC 3986 (immer noch nützlich als Übersicht auf hohem Niveau) und stimmt damit überein, wie Browser tatsächlich funktionieren - was in der Praxis wichtig ist. Der Standard definiert Normalisierungsregeln (Schema und Host kleinschreiben, nicht reservierte Zeichen prozent-dekodieren, Dot-Segmente im Pfad zusammenfassen), Fehlerbehandlungsverhalten (tolerant gegenüber Leerzeichen, streng gegenüber Steuerzeichen) und die strukturellen Felder, die das URL-Objekt bereitstellt. Die Spezifikation zu lesen ist schwere Kost, aber es lohnt sich zu wissen, dass sie existiert; für den täglichen Gebrauch beim Debuggen ist dieser Parser zusammen mit Kenntnissen der Feldnamen ausreichend.