URL-Parser: Teilen Sie jeden Link in seine Teile und lesen Sie die Abfragezeichenfolge

Ich habe einen Nachmittag einmal an eine URL verloren, die gut aussah. Ein OAuth-Rückruf scheiterte, der Umleitungs-URI "übereinstimmend" der beim Anbieter registrierte, und ich konnte nicht sehen, warum der Handschlag kaputt ging. Die Antwort, als ich das Ding schließlich in einen Parser einklebte, war ein nachlaufender Schrägstrich auf dem Weg an einem Ort und keiner an der anderen Stelle, plus a state Parameter, der so doppelt codiert wurde %20 war geworden %2520drohen Für das menschliche Auge waren die beiden URLs identisch. Auf den OAuth-Server waren es verschiedene Zeichenfolgen, und es war richtig, die Nichtübereinstimmung abzulehnen.

Das ist das Problem bei URLs: Sie sind dicht, sie sind leicht falsch zu lesen und die Details, die Dinge brechen - ein codierter Schrägstrich, ein Streutport, ein wiederholter Abfrageschlüssel, ein Fragment, an dem Sie einen Pfad erwartet haben - sind genau die, die sich in einer Wand aus Zeichen verbergen. Ich baue toolz.devund ich verbringe genug Zeit damit, auf Abfragezeichenfolgen zu starren, während ich beim Debuggen a erstellt habe URL-Parser das Starren für mich zu tun. Fügen Sie einen Link ein, lassen Sie jede Komponente beschriften und jeder Abfrageparameter in einer Tabelle dekodiert werden. In diesem Leitfaden wird erläutert, was diese Komponenten sind, warum die Unterscheidungen wichtig sind und wie sie verwendet werden.

tl; dr: Eine URL wird aus einem Schema (https), optionale Anmeldeinformationen (user:pass@), ein Host (example.com) mit optionalem Port, einem Pfad (/blog/post), eine Abfragezeichenfolge (?id=42) und ein Fragment (#section).). der URL-Parser Teilt jede Verknüpfung in diese Teile mit der eigenen WhatWG-URL-Engine des Browsers, dekodiert die Abfrage in eine geordnete Schlüsselwerttabelle (wiederholte Schlüssel getrennt gehalten), zeigt den effektiven Port für das Schema an und geht davon aus https:// Wenn Sie eine nackte Domain einfügen. Es läuft vollständig in Ihrem Browser, sodass Links mit Tokens privat bleiben.

Was sind die Teile einer URL?

Jede URL folgt der gleichen Grammatik, definiert durch den WhatWG-URL-Standard — die Spezifikationsbrowser implementieren tatsächlich. Sobald Sie die Teile benennen können, werden die meisten URL-Fehler offensichtlich. Hier ist die vollständige Anatomie, an einem bewusst geschäftigen Beispiel:

https://john:[email protected]:8443/catalog/shoes?color=red&size=42#reviews
└─┬─┘   └──┬──┘└─┬──┘└──────┬────────┘└─┬─┘└──────┬──────┘└──────┬──────┘ └──┬──┘
scheme   user  pass       hostname     port      path          query      fragment

Das aufschlüsseln:

Der Parser legt jedes dieser als eine eigene Zeile mit einem Kopierknopf aus, sodass Sie nie wieder einen Hostnamen von einer Monster-URL extrahieren müssen. Es werden auch einige Dinge markiert, die die RAW-Zeichenfolge ausblendet: Ob der angezeigte Port explizit oder der Standard des Schemas ist und ob es sich bei dem Host um eine benannte Domäne oder eine RAW-IP handelt.

Was ist der Unterschied zwischen Hostname, Host und Herkunft?

Diese drei Menschen stolpern ständig über die Verwirrung und die Verwirrung verursachen echte Fehler - Cors-Fehler, Fehler beim Scoping von Keksen, Umleitung von Fehlpaarungen. Sie sind keine Synonyme.

Hostname ist nur die Domain oder IP: shop.example.co.ukdrohen Kein Hafen, kein Schema. Es ist das, was Sie in eine DNS-Suche einfügen würden.

Wirtsmann ist der Hostname plus der Port, Aber nur, wenn in der URL ein Port vorhanden istdrohen auf shop.example.co.uk:8443 Der Gastgeber ist shop.example.co.uk:8443drohen Für eine Ebene https://shop.example.co.uk/ Der Host und der Hostname sind identisch, da der Standardport 443 impliziert und nicht geschrieben ist. Diese "Nur wenn "Vorhanden" -Regel ist subtil und der Grund, warum die gleiche Site zwei verschiedene Hosts zu haben scheint.

Ursprung ist Schema plus Host: https://shop.example.co.uk:8443drohen Dies ist derjenige, den Browser am meisten interessiert, da die Richtlinie zur gleichen Herkunft - die Grundlage der Websicherheit - die Herkunft und nicht die Hostnamen vergleicht. Zwei URLs teilen sich nur einen Ursprung, wenn ihr Schema, Hostname, und Port alle übereinstimmen. http://example.com und https://example.com sind unterschiedliche Ursprünge, da das Schema unterschiedlich ist. https://example.com und https://example.com:8443 sind unterschiedliche Ursprünge, da der Port unterschiedlich ist, obwohl der Hostname derselbe ist. Wenn ein Abruf mit einem CORS-Fehler fehlschlägt, ist der Vergleich der beiden Ursprünge im Parser normalerweise der schnellste Weg, um die Fehlanpassung zu erkennen.

Wie analysieren Sie eine Abfragezeichenfolge?

In der Abfragezeichenfolge lebt der größte Teil des täglichen Schmerzes, da es sich um einen flachen, nicht entweichenden Blob handelt, der tatsächlich strukturiert und prozentual codiert ist. Der Parser teilt es für Sie auf: alles nach dem ?, gebrochen auf &, mit jedem key=value Paar dekodiert und in einer Tabelle in der ursprünglichen Reihenfolge aufgeführt.

Hier sind zwei Verhaltensweisen von Bedeutung. zuerst, Dekodierungdrohen ein Parameter geschrieben als q=trail%20runner auf dem Draht ist als gezeigt trail runner in der Spalte Wert, weil %20 ist ein prozentualer Codierungsbereich. Das Rohe search String wird in der Komponentenliste weiterhin unberührt angezeigt, sodass Sie die codierten und dekodierten Formulare vergleichen können - von unschätzbarem Wert, wenn Sie eine Doppelkodierung vermuten, wie z. %2520 Oauth-Fehler.

Zweitens, Wiederholte Tastendrohen Eine URL kann denselben Schlüssel mehr als einmal legitim tragen: ?tag=react&tag=typescript&tag=nodedrohen Viele naive Parser klappen diese zusammen, behalten nur den ersten oder letzten Wert und verlieren stillschweigend Daten. Das ist falsch - wiederholte Schlüssel sind, wie HTML-Formulare mehrere ausgewählte Felder senden und viele APIs Arrays exprimieren. Der Parser behält jedes Vorkommen als eigene Zeile, damit Sie alle drei Tags sehen. Wenn Sie die Abfrage als JSON kopieren, werden wiederholte Schlüssel zu einem Array, das die Form ist, die der meiste Code erwartet.

Sie benötigen nicht einmal eine vollständige URL, um diese zu verwenden. Fügen Sie nur eine Abfragezeichenfolge ein — color=red&size=42 - und das Werkzeug analysiert es von selbst. Es ist der schnellste Weg, eine Webhook-Nutzlast oder einen Tracking-Link zu verstehen, der Ihnen jemand weitergeleitet hat.

Wie verwende ich den URL-Parser?

Das Werkzeug ist so konzipiert, dass es Ihnen aus dem Weg geht. Fügen Sie eine URL in die einzelne Eingabe ein und sie analysiert Live-Dateien während Sie eingeben - keine Schaltfläche zum Drücken. Ein Beispiellink ist vorinstalliert, sodass Sie die vollständige Aufschlüsselung sofort sehen können, und ein klarer Knopf leert das Feld.

Sie müssen das Schema nicht eingeben. Fügen Sie einen nackten Gastgeber wie example.com/pricing Und der Parser stellt https:// Automatisch, dann wird Ihnen dies mit einer kleinen Notiz angezeigt, sodass Sie nie verwirrt sind, woher das Schema stammt. Ein explizites Schema einfügen — http://, ftp://, ssh:// - und das respektiert es stattdessen.

Der Ausgang hat vier Zonen. Oben ist die Normalisierte URL — Die kanonische Form des Browsers produzierte mit einem Kopierknopf, der sich praktisch für subtile Normalisierungsunterschiede eignet. Darunter die Bestandteile Tabelle, eine beschriftete Zeile pro Teil, jede unabhängig kopierbar. dann Pfadsegmente, in indexierte Chips aufgebrochen, also ein tiefer Weg wie /api/v2/users/42/orders ist auf einen Blick lesbar. Endlich die Abfrageparameter Tabelle, dekodiert und geordnet, mit einer Aktion "als JSON" kopieren, die die gesamte Abfrage in ein sauberes Objekt verwandelt.

Alles läuft in Ihrem Browser über die native URL-Engine. Dies ist eine bewusste Wahl: URLs enthalten routinemäßig Zugriffstoken, Sitzungs-IDs, signierte Parameter und interne Hostnamen, und nichts davon sollte nur zum Lesen an einen Server gesendet werden. Nichts, was Sie einfügen, verlässt Ihr Gerät und das Tool funktioniert weiterhin offline. Es ist der gleiche Datenschutz-First-Ansatz hinter dem gesamten Toolkit, auf den ich im Leitfaden für Webentwickler-Toolkitdrohen

Wann greife ich nach einem URL-Parser?

In meiner eigenen Arbeit treten immer wieder ein paar Situationen auf. Debugging- und Rückrufe ist der große - OAuth Flows, Zahlungsrückgabe-URLs, SSO-Handshakes, die alle bei winzigen Fehlanpassungen fehlschlagen, die erst sichtbar werden, wenn Sie beide URLs zerlegen. Auditing-Tracking-Links ist ein weiterer: Marketing-URLs sind oft eine Basisseite plus ein Dutzend UTM- und Ad-Plattform-Parameter, und das Lesen als Tabelle schlägt, wenn sie eine 300-Zeichen-Zeichenfolge schielen. Wenn Sie diese Links erstellen, anstatt sie zu lesen, UTM-Builder ist die andere Hälfte des gleichen Workflows.

Dann gibt es API-Arbeit — Überprüfen der Abfrageparameter, die ein Client tatsächlich gesendet hat, oder rückentwickeln, wie ein Endpunkt seine Filter erwartet. und Sicherheitsüberprüfung: Ein unbekannter Link in einer E-Mail oder einem Protokoll ist viel sicherer zu verstehen, indem er seine Teile analysiert (welcher Host tut dies? wirklich Punkt auf? Ist dieser Hostname eine IP?) als durch Klicken darauf. Der Parser stellt den wahren Hostnamen bereit und markiert IP-Literal-Hosts. Dies sind genau die Informationen, die Sie möchten, bevor Sie einem Link vertrauen. Ich habe mehr über die Montage dieser Art von Inspektionsset in der API-Debugging-Toolsdrohen

Wie hängt das Parsen mit Codierung und Slugs zusammen?

Ein URL-Parser ist eine Ecke einer kleinen Familie von Link-Tools, und das Wissen, welches Sie benötigen, spart Zeit. Parsing Lesung eine vorhandene URL und zieht sie auseinander. Verschlüsselung Tut die entgegengesetzte Richtung auf der Ebene der Zeichen - Verwandeln Sie Leerzeichen und Sonderzeichen in ihre prozentual codierten Formen, damit sie in einer URL und wieder zurück überleben. Wenn Sie einen Wert sicher in eine Abfragezeichenfolge einbetten oder eine verstümmelte Dekodierung benötigen, ist dies die URL-Encoder/Decoderund es wird natürlich mit dem Parser kombiniert: Parse, um die Struktur zu sehen, codieren Sie, um einen gebrochenen Wert zu korrigieren.

Schneckengeneration ist ein dritter, verwandter Job - einen menschlichen Titel wie "10 Tipps für schnellere Builds" anzunehmen und ihn in eine saubere Verwandlung zu verwandeln 10-tips-for-faster-builds Pfadsegment. Das ist was die Schneckengenerator Griffe, und es ist das, was das ordentliche produziert path Komponente Der Parser liest später zurück. Stellen Sie sich das als Pipeline vor: Sluglify, um gute Pfade zu erstellen, codieren, um Werte url-sicher zu machen, analysieren Sie, um den fertigen Link zu überprüfen. Jedes Tool erledigt einen Teil des URL-Lebenszyklus und dies im Browser.

Was ist mit IP-Adressen und internationalisierten Domains?

Nicht jeder Gastgeber ist ordentlich example.comdrohen Einige URLs zeigen auf rohe IP-Adressen, und der Parser erkennt beide Formulare. ein IPv4-Wörterbuch http://192.168.1.10:3000/ hat einen Hostnamen von 192.168.1.10, und das Tool kennzeichnet es als IP und nicht als Domain – nützlich, wenn Sie einen Link prüfen und sofort wissen möchten, ob er auf eine benannte Website oder eine bloße Adresse abzielt, was ein häufiges Signal in verdächtigen Links ist. IPv6-Literale werden in eckige Klammern in einer URL wie in URL eingewickelt http://[2001:db8::1]:8080/, und die Klammern sind Teil der Host-Syntax, nicht Dekoration; die Parser-Handgriffe, die sich richtig bilden, anstatt die Doppelpunkte zu ersticken, was sonst wie Port-Trennzeichen aussehen würde.

Internationalisierte Domain-Namen sind der andere Randfall. Ein Host, der in Nicht-ASCII-Zeichen geschrieben ist - beispielsweise eine Domain mit akzentuierten oder nicht lateinischen Buchstaben - wird von der URL-Engine des Browsers in seinen Punycode konvertiert xn-- Formular für die eigentliche Anfrage, da DNS nur ASCII spricht. Das Normalisierte sehen href Im Parser zeigt Ihnen genau, was der Browser auflöst, was gelegentlich überrascht, dass Leute, die erwartet haben, dass ihre hübsche Unicode-Domain unverändert reisen soll. Für die Top-Level-Domain extrahiert der Parser die endgültige Bezeichnung eines benannten Hosts, also shop.example.co.uk meldet eine TLD von ukdrohen Das ist eine absichtlich einfache Regel - es versucht nicht, mehrteilige Suffixe wie zu trennen .co.uk in eine registrierbare Domain, da dies ordnungsgemäß die öffentliche Suffixliste erfordert, die ein großer Datensatz ist. Für eine schnelle Inspektion ist das letzte Etikett das nützliche Signal, und für alles, was rigoroser ist, würden Sie nach einer dedizierten Bibliothek greifen.

Ein funktionierendes Beispiel verbindet es miteinander. Angenommen, ein Zahlungsanbieter lehnt Ihre Rückgabe-URL ab. du hast dich angemeldet https://app.example.com/checkout/return Aber die fehlgeschlagene Anfrage zeigt https://app.example.com:443/checkout/return/drohen Beides analysieren. Der Parser zeigt den ersten has host app.example.com (Standardport, kein nachlaufender Schrägstrich auf dem Pfad) und der zweite hat Host app.example.com auch - aber sein Weg ist /checkout/return/ mit einem nachlaufenden Schrägstrich und dessen Port wurde explizit als geschrieben :443drohen Zwei Unterschiede, über die das Auge gleitet, beide tödlich bis zu einer genauen Übereinstimmung. Sobald Sie sie als separate beschriftete Komponenten sehen können, ist die Lösung offensichtlich: Normalisieren Sie den nachstehenden Schrägstrich und lassen Sie den redundanten expliziten Port fallen.

Häufige Fehler beim Lesen von URLs

Die wiederkehrenden Fehler sind wert, genannt zu werden. Verwechseln des Fragments mit dem Pfad oder der Abfrage - Alles danach # ist das Fragment, es wird vollständig vom Browser behandelt und wird niemals an den Server gesendet. Ein Parameter, den Sie nach dem # wird Ihr Backend nicht erreichen. Angenommen, ein fehlender Port bedeutet keinen Port — Ein weggelassener Port bedeutet das Schema nicht vertragen (443 für HTTPS, 80 für HTTP), was der Parser explizit macht, damit Sie wissen, welchen Port eine Anfrage wirklich treffen wird.

Doppelkodierung ignorieren - Wenn ein Wert wie aussieht %2520 anstelle %20, wurde es zweimal codiert, parsen und wenn der dekodierte Wert noch eine prozentuale Sequenz enthält, dekodieren Sie erneut. Vertraue dem sichtbaren Text eines Links - Der Text, den Sie sehen und der tatsächliche href kann sich komplett unterscheiden, was der gesamte Mechanismus hinter Phishing ist, das Parsen zeigt den realen Zielhost. und Behandeln Sie wiederholte Abfrageschlüssel als Duplikate, die Sie verwerfen — Es handelt sich oft um aussagekräftige Arrays, und das Ablegen der Daten verliert Daten.

Häufig gestellte Fragen

Was sind die Teile einer URL?

Eine URL hat ein Schema (https), optionale Anmeldeinformationen (user:pass@), einen Host (example.com) mit einem optionalen Port, einen Pfad (/blog/post), eine optionale Abfragezeichenfolge (?id=42) und ein optionales Fragment (#section). Dieser Parser trennt und beschriftet jeden.

Wie analysieren Sie eine Abfragezeichenfolge?

Fügen Sie die vollständige URL ein und lesen Sie die Abfragetabelle oder fügen Sie nur die Abfragezeichenfolge selbst ein. Der Parser teilt es auf ampersands, dekodiert die prozentuale Kodierung und listet jedes Schlüssel-Wert-Paar in der richtigen Reihenfolge auf. Wiederholte Tasten wie tag=a&tag=b werden als separate Zeilen gehalten.

Was ist der Unterschied zwischen Hostname, Host und Herkunft?

Hostname ist nur die Domain oder IP (example.com). Host fügt den Port hinzu, wenn einer vorhanden ist (example.com:8443). Herkunft ist das Schema plus Host (https://example.com:8443) und ist das, was Browser für die gleiche Ursprungsprüfung verwenden.

Welcher Port wird verwendet, wenn eine URL keine Portnummer hat?

Das Schema entscheidet. HTTPS ist standardmäßig 443, HTTP auf 80, SSH auf 22 und FTP auf 21. Dieser Parser zeigt den effektiven Port an und markiert ihn als Standard, sodass Sie wissen, welchen Port eine Anfrage tatsächlich verwenden würde.

Dekodiert der Parser prozentuale Codierungen?

Ja, für Abfragewerte. Ein Parameter wie Name = John%20DOE wird in der Tabelle als "John Doe" dekodiert gezeigt. Die rohe Suchzeichenfolge wird ebenfalls unberührt angezeigt, sodass Sie die codierten und dekodierten Formulare vergleichen können.

Kann ich eine URL analysieren, ohne den HTTPS-Teil einzugeben?

Ja. Wenn Sie einen nackten Host oder Pfad wie example.com/pricing einfügen, stellt der Parser https:// automatisch voran und stellt fest, dass er das Schema angenommen hat. Fügen Sie ein Schema wie http:// oder ftp:// explizit ein, um diese Annahme zu überschreiben.

Warum kann meine URL nicht analysiert werden?

Normalerweise fehlt der Host oder ist das Schema falsch geschrieben, oder die Zeichenfolge enthält Zeichen, die in einer URL illegal sind und nicht prozentual codiert sind. Überprüfen Sie nach dem Schema Leerzeichen, nicht entweichte Klammern oder einen fehlenden Schrägstrich.

Ist es sicher, URLs mit Token oder Sitzungs-IDs einzufügen?

Ja. Das Parsen wird vollständig in Ihrem Browser über die native URL-Engine ausgeführt. Der Link wird niemals an einen Server gesendet, niemals protokolliert und niemals gespeichert. Daher bleiben URLs mit Zugriffstoken, API-Schlüssel oder internen Hostnamen auf Ihrem Gerät.