URL-Parser
Zerlege jede URL in ihr Schema, ihren Host, Port, Pfad, ihre Abfrageparameter und ihren Hash, lokal in deinem Browser geparst.
URL-Parser wird geladen… Wenn nichts passiert, aktiviere JavaScript.
Eine URL (Uniform Resource Locator) sieht aus wie eine einzige Zeichenkette, ist aber tatsächlich ein strukturierter Datensatz aus mehreren eigenständigen Komponenten, jede mit eigener Bedeutung. Eine vollständige URL wie https://user:pass@example.com:8443/path/page?q=hello&lang=en#section bündelt ein Schema, optionale Anmeldedaten, einen Host, einen optionalen Port, einen Pfad, eine Query String und ein Fragment. Diese Teile mit dem Auge zu lesen ist leicht falsch zu machen, vor allem wenn die Query String lang ist, prozentkodierte Zeichen enthält oder denselben Schlüssel mehr als einmal wiederholt. Ein Parser teilt die URL präzise nach den im WHATWG URL Standard definierten Regeln auf, denselben Regeln, denen jeder moderne Browser folgt.
Häufig gestellte Fragen
Wird die URL, die ich einfüge, an einen Server gesendet?
Welche Teile hat eine URL?
Warum wird der Port bei manchen URLs als Standard angezeigt?
Was ist der Unterschied zwischen host und hostname?
Wie werden wiederholte Abfrageparameter behandelt?
Dekodiert es prozentkodierte Zeichen in Abfragewerten?
Warum bekomme ich einen Fehler über eine ungültige URL?
Kann es Nicht-Web-Schemata wie mailto oder ftp parsen?
Über URL-Parser
Dieses Werkzeug nutzt die nativen, in deinem Browser eingebauten APIs URL und URLSearchParams, sodass die Ergebnisse genau dem entsprechen, wie ein Browser, ein fetch-Aufruf oder ein Server-Framework die Adresse interpretieren würden. Es zeigt das Schema und das vollständige Protokoll, jeden in der Autorität eingebetteten Benutzernamen und jedes Passwort, den Host und den Hostname, den Port (oder einen Hinweis, dass der Standard des Schemas gilt), den Pathname, den berechneten Origin und das Hash-Fragment. Die Query String wird in eine übersichtliche Tabelle aus Schlüssel-Wert-Paaren aufgeschlüsselt, wobei jeder Wert einzeln kopierbar ist, was weitaus schneller ist, als sich durch eine Wand aus Et-Zeichen und Gleichheitszeichen zu wühlen.
Alles läuft lokal in deinem Browser. Die URL, die du einfügst, wird niemals hochgeladen, protokolliert oder an einen Server gesendet, daher ist es sicher, Links zu untersuchen, die Zugriffstoken, Sitzungskennungen, signierte Parameter oder andere sensible Abfragewerte enthalten. Entwickler greifen zu einem URL-Parser, wenn sie Weiterleitungen, OAuth-Rückruf-URLs, den Tracking-Parameter-Wirrwarr aus Marketingkampagnen, API-Endpunkte mit vielen Abfrageoptionen oder Deep Links in mobilen Apps debuggen. Wenn die Eingabe keine gültige absolute URL ist, zeigt das Werkzeug einen klaren Fehler an, statt zu raten.
Der URL-Standard, auf den sich jahrzehntelang niemand einigte
URLs wurden erstmals 1994 von Tim Berners-Lee im RFC 1738 formalisiert, doch jahrelang danach parste jeder Browser, jede Bibliothek und jede Sprache sie geringfügig anders. Grenzfälle wie Backslashes, Leerzeichen am Anfang und Ende, eigenartig platzierte Doppelpunkte und Prozentkodierung im Host verursachten echte Sicherheitslücken, weil ein Parser auf dem Server und ein Parser im Browser darüber uneinig sein konnten, auf welchen Host eine URL tatsächlich verwies. Angreifer nutzten diese Unstimmigkeiten aus, um an URL-Zulassungslisten vorbeizuschlüpfen und serverseitige Anfragefälschung auszulösen.
Um dem Chaos ein Ende zu setzen, veröffentlichte das WHATWG den URL Standard, eine lebende Spezifikation, die das Parsen als präzisen Zustandsautomaten statt als lockere Grammatik definiert. Entscheidend ist, dass die Spezifikation geschrieben wurde, um zu beschreiben, was Browser tatsächlich tun, einschließlich ihrer Eigenheiten, sodass der Algorithmus von Grund auf interoperabel ist. Die JavaScript zugänglich gemachten Klassen URL und URLSearchParams implementieren genau diesen Algorithmus, weshalb die Ausgabe dieses Werkzeugs dem entspricht, was die Adressleiste deines Browsers und fetch-Aufrufe sehen.
Ein feines Detail, das der Standard klar festlegt, ist der Unterschied zwischen den speziellen Schemata (http, https, ws, wss, ftp, file) und allem anderen. Spezielle Schemata erhalten eine zusätzliche Normalisierung, etwa das Kleinschreiben des Hosts und das Auflösen des Standardports, während nicht spezielle Schemata wörtlicher behandelt werden. Diese Unterscheidung erklärt, warum eine https-URL und eine benutzerdefinierte myapp-URL mit demselben Text nach dem Doppelpunkt in recht unterschiedliche Komponentenwerte geparst werden können.