Parse jede URL in Protokoll, Host, Port, Pfad, Abfrage und Fragment mit dem WHATWG-URL-Standard. Abfrageparameter werden in eine lesbare Tabelle dekodiert.
Zerlege eine URL in jede Komponente, die der Browser sieht. Füge eine URL ein und jeder Teil wird mit demselben WHATWG-Parser extrahiert, den dein Browser verwendet, sodass das Ergebnis genau mit der tatsächlichen Interpretation der URL übereinstimmt. Abfrageparameter werden in eine Tabelle dekodiert.
Jede absolute URL folgt demselben Gerüst:
scheme://user:password@host:port/path?query#fragmentDie meisten URLs nutzen nur einige dieser Plätze, aber die Grammatik erlaubt sie alle. Eine URL zu lesen ist weitgehend eine Frage, zu wissen, wo eine Komponente endet und die nächste beginnt, was durch die Trennzeichen ://, @, :, /, ? und # entschieden wird.
Protokoll (Scheme) identifiziert, wie die Ressource abgerufen wird – https:, mailto:, ftp:. Beachte, dass der WHATWG-Parser den nachgestellten Doppelpunkt in diesem Wert einschließt, was Menschen überrascht, die ihn mit der Zeichenfolge "https" vergleichen.
Benutzername und Passwort sind der veraltete Userinfo-Abschnitt. Browser parsen sie noch, entfernen sie aber aus Anfragen und warnen oft, weil das Einbetten von Anmeldedaten in eine URL sie in Verlauf, Protokollen und Referrer-Headern preisgibt. Behandle ihr Vorhandensein in einer URL, die du nicht geschrieben hast, als Phishing-Signal.
Hostname ist die Domain oder IP-Adresse allein. Host ist der Hostname plus der Port, wenn ein nicht-standardmäßiger Port vorhanden ist, weshalb die beiden Felder hier oft identisch aussehen.
Port ist leer, wenn die URL den Standardport des Schemas nutzt – 443 für https, 80 für http. Der Parser normalisiert das: example.com:443/ meldet einen leeren Port, weil 443 keine Information hinzufügt.
Pfad ist alles vom ersten / bis zur Abfrage. Er ist die einzige Komponente, die für eine http(s)-URL nie leer ist; ein nackter Origin erhält einen Pfad von /.
Abfragezeichenfolge beginnt bei ? und trägt die Parameter. Fragment beginnt bei # und ist der einzige Teil, der nie an den Server gesendet wird – er wird rein clientseitig behandelt, weshalb Single-Page-Apps ihn früher für Routing nutzten und weshalb ein Zugriffstoken in einem Fragment aus Serverprotokollen herausbleibt.
Origin ist das sicherheitsrelevante Tripel aus Scheme, Host und Port. Zwei URLs teilen ein Origin nur, wenn alle drei übereinstimmen, und genau darauf basieren die Same-Origin-Policy und CORS-Entscheidungen.
Der WHATWG-URL-Parser akzeptiert nur absolute URLs. example.com/page hat kein Schema, also kann es nicht allein geparst werden – der Parser kann nicht wissen, ob du example.com/page oder einen relativen Pfad meintest. Echter Code löst relative Referenzen gegen eine Basis-URL auf; dieses Werkzeug verlangt bewusst die absolute Form, damit eindeutig ist, was du siehst.
Der Parser gibt nicht die Rohzeichenfolge zurück. Er macht Scheme und Host klein, löst .- und ..-Segmente im Pfad auf, lässt Standard-Ports weg und wandelt internationalisierte Domains in ihre Punycode-Form um, sodass münchen.de einen Hostnamen von xn--mnchen-3ya.de meldet. Das ist eine Funktion: Sie zeigt dir die URL so, wie der Netzwerk-Stack sie tatsächlich behandeln wird, nicht so, wie sie getippt wurde.
Eine Abfragezeichenfolge darf eine Taste legitim wiederholen, wie in ?tag=a&tag=b. Es gibt keine Spezifikation, was das bedeutet – manche Frameworks nehmen den ersten Wert, manche den letzten, manche sammeln ein Array. Die Tabelle hier listet jede Vorkommen in Reihenfolge auf, sodass du genau siehst, was gesendet wurde, statt einer zusammengefassten Ansicht.