URL-Parser

Der URL Parser zerlegt jede Webadresse in ihre einzelnen Bestandteile — Schema, Host, Port, Pfad, Query-Parameter und Fragment —, sodass Sie sie auf einen Blick prüfen oder debuggen können. Er ist für Entwickler gedacht, die Weiterleitungen debuggen, für Marketer, die Tracking-Parameter prüfen, und für alle, die wissen wollen, was jeder Teil einer langen URL tatsächlich tut.

Anatomie einer URL

Eine URL sieht wie eine einzelne Zeichenkette aus, hat aber eine strenge Struktur, die in RFC 3986 definiert ist. Betrachten Sie:

https://shop.example.com:8080/products/list?page=2&utm_source=newsletter#reviews

Von links nach rechts gelesen sind die Teile:

Teil	Wert	Bedeutung
Schema	https	Das Protokoll, das der Browser spricht
Host	shop.example.com:8080	Servername plus optionaler Port
Port	8080	Explizit; 443 und 80 sind implizit und verborgen
Pfadname	/products/list	Die Ressource auf diesem Server
Suche	?page=2&utm_source=newsletter	Query-Parameter
Hash	#reviews	Anker innerhalb der Seite, nie an den Server gesendet

Zu wissen, welches Stück welches ist, macht Weiterleitungen, Tracking-Fehler und API-Callbacks weit weniger mühsam zu durchschauen.

Die Ergebnis-Karten lesen

Die oberste Kartenreihe zeigt Schema, Host, Port, Pfadname, Suche und Hash genau so, wie der Parser sie speichert. Darunter teilt ein zweites Fenster den Host in Subdomain, Domain und TLD. Für das obige Beispiel lautet die Host-Aufschlüsselung:

• Subdomain: shop
• Domain: example
• TLD: com

Das letzte Fenster ist eine Tabelle der Query-Parameter, eine Zeile pro Schlüssel und Wert, wobei die gesamte Prozentkodierung zur Lesbarkeit dekodiert ist. Jede Karte lässt sich unabhängig kopieren, sodass Sie nur den Pfadnamen in ein Log oder nur den Port in eine Konfigurationsdatei übernehmen können.

Praxisbeispiel: Eine Kampagnen-URL

Marketing-Links sind der Ort, an dem die URL-Struktur unübersichtlich wird. Nehmen Sie:

example.com/lp?utm_source=news&utm_medium=email&utm_campaign=spring%20sale&ref=abc123

Weil das Schema fehlt, fügt das Tool automatisch https:// hinzu. Der Host wird example.com ohne Subdomain, der Pfad ist /lp, und die Parametertabelle liest sich:

• utm_source = news
• utm_medium = email
• utm_campaign = spring sale
• ref = abc123

Beachten Sie, dass spring%20sale in der Tabelle zu spring sale dekodiert wurde, während die rohe Suchkarte weiterhin die kodierte Zeichenkette zeigt. Diese Trennung ist nützlich: Nutzen Sie die Tabelle zum Lesen der Werte und die Suchkarte zum Kopieren der wörtlichen Query, die der Server erhält.

Wie das Tool Domains aufteilt

Die Domain-Aufteilung ist der Teil des URL-Parsings, der keine perfekte eingebaute Antwort hat, weil Suffixe wie co.uk sich wie eine einzelne TLD verhalten, aber eigentlich zwei Labels sind. Der Parser handhabt das mit einer kleinen Allowlist gängiger mehrteiliger Suffixe und einem einfachen Fallback:

1. Ist der Hostname eine IPv4-Adresse oder localhost, wird er als Domain ohne TLD behandelt.
2. Andernfalls wird das letzte Label als TLD genommen.
3. Hat der Host mindestens drei Labels und bilden die letzten beiden ein bekanntes Suffix, wird dieses Zwei-Label-Suffix zur TLD und das Label davor zur Domain.

So ergibt www.example.co.uk die Subdomain www, die Domain example und die TLD co.uk. Aber www.example.co.za steht nicht auf der Liste, also ergibt es die Subdomain www.example, die Domain co und die TLD za — technisch falsch, und eine gute Erinnerung daran, dass Public-Suffix-Logik einen viel größeren Datensatz als eine feste Liste braucht.

Debugging-Tipps und warum Struktur zählt

Eine URL ist ein Schnittstellenvertrag. Das Schema entscheidet das Protokoll, Host und Port wählen den Server, der Pfad wählt die Ressource, die Query trägt Anwendungszustand, und das Fragment bleibt auf dem Client. Wenn eines dieser Teile abdriftet, zeigt sich der Fehler meist weit entfernt — ein Analysebericht mit fehlenden Kampagnendaten, ein OAuth-Callback, der auf der falschen Route landet, oder ein CDN, das zwei URLs zwischenspeichert, die es für verschieden hält. Die Adresse in benannte Felder zu zerlegen macht aus einer unscharfen Debugging-Sitzung eine Checkliste: Stimmt der Host, ist der Port der erwartete, sind die Query-Schlüssel genauso geschrieben wie im Code, und zeigt das Fragment auf ein Element, das noch existiert?

Für Tracking-Audits fügen Sie die Live-URL ein und bestätigen, dass die erwarteten Parameter vorhanden, korrekt geschrieben und nicht doppelt sind — doppelte utm-Schlüssel sind eine häufige Ursache verzerrter Analysen. Für Weiterleitungsketten parsen Sie jeden Sprung und vergleichen Pfadnamen und Host; ein verirrter abschließender Schrägstrich oder ein verschwundener Port erklärt meist ein unerwartetes 301. Für API-Arbeit kopieren Sie die dekodierte Query-Tabelle, um zu prüfen, dass die Werte zu Ihrer Dokumentation passen, bevor Sie die Signaturzeichenkette bauen, da Unterschiede in der Prozentdekodierung eine häufige Quelle für Signaturabweichungen sind.

Randfälle und häufige Fehler

• Standardports verschwinden. https://example.com:443/ zeigt einen leeren Port und nach der Normalisierung https://example.com/.
• Internationale Domains werden zu Punycode. Geben Sie https://münchen.de ein, und die Hostname-Karte zeigt die ASCII-Form xn--mnchen-3ya.de, weil der Browser sie so für DNS speichert.
• Abschließende Schrägstriche zählen. /products und /products/ sind unterschiedliche Pfadnamen, auch wenn ein Server sie gleich behandelt.
• Leere Queries liefern keine Zeilen. Ein abschließendes ? oder gar keine Query erzeugt eine leere Parametertabelle statt einer leeren Zeile.
• Ungültige Eingabe schlägt sauber fehl. Eine Zeichenkette, die der Browser nicht parsen kann, zeigt eine Meldung „Ungültige URL“ statt einer irreführenden Teilaufschlüsselung.
• Den kodierten Wert für den echten halten. Die Parametertabelle zeigt dekodierten Text, sodass eine Suche nach a%26b als a&b erscheint. Nutzen Sie die rohe Suchkarte, wenn Sie die exakten Bytes brauchen, die der Server erhält.
• Die Host-Karte als Domain lesen. Der Host enthält den Port und jede Subdomain; die Domain-Karte ist nur das registrierbare Label.
• Der TLD-Aufteilung für jedes Land vertrauen. example.co.za und example.com.br sind zweistufige Suffixe, die die feste Allowlist verfehlt, sodass die Domain-Karte fälschlich co oder com zeigt.
• Vergessen, dass Pfade groß-/kleinschreibungssensitiv sind. /Products und /products können auf demselben Server verschiedene Routen sein.
• Ein bloßes Wort als gültigen Host behandeln. not a url bekommt https:// vorangestellt und parst möglicherweise seltsam; prüfen Sie die Host-Karte, bevor Sie dem Ergebnis vertrauen.

Verwandte Tools

• URL-Encoder
• IP-Adress-Lookup
• JWT-Decoder