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 mit URLs: Sie sind dicht, sie sind leicht falsch zu lesen, und die Details, die Dinge zerstören - ein codierter Schrägstrich, ein Streubackbord, ein wiederholter Abfrageschlüssel, ein Fragment, bei dem man einen Pfad erwartet hat - sind genau diejenigen, die sich in einer Zeichenwand verstecken Ich baue [Toolz.dev] (/, und ich verbringe genug Zeit damit, auf Abfrageschilder zu starren, während ich debugge, dass ich eine 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 aushttps://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, anhand eines bewusst ausgelasteten Beispiels:
https://john:[email protected]:8443/catalog/shoes?color=red&size=42#reviews
└─┬─┘ └──┬──┘└─┬──┘└──────┬────────┘└─┬─┘└──────┬──────┘└──────┬──────┘ └──┬──┘
scheme user pass hostname port path query fragment
Das aufschlüsseln:
| Komponente | Beispielwert | Was es ist |
|---|---|---|
| Plan | https |
das Protokoll. Entscheidet den Standardport und wie die Anfrage erstellt wird. |
| Benutzername | john |
Optionaler Ausweis vor dem @drohen |
| Passwort | s3cret |
Optionaler Ausweis nach dem : in der Userinfo. |
| Hostname | shop.example.co.uk |
Die Domain oder IP-Adresse ohne Port. |
| Hafen | 8443 |
optional Fällt beim Auslassen auf den Standard des Schemas zurück. |
| Wirtsmann | shop.example.co.uk:8443 |
Hostname plus Port, wenn ein Port vorhanden ist. |
| Ursprung | https://shop.example.co.uk:8443 |
Schema plus Host - die von Browsern der Einheit zur Sicherheit verwendeten. |
| Bahn | /catalog/shoes |
Der Ressourcenstandort auf dem Host. |
| Frage | ?color=red&size=42 |
Schlüsselwertparameter nach dem ?drohen |
| zersplitter | #reviews |
Clientseitiger Anker nach dem #, nie an den Server gesendet. |
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 bringen die Leute ständig zum Stolpern, und die Verwirrung verursacht echte Fehler - CORS-Fehler, Fehler beim Cookie-Scoping, Fehlpaarungen bei der Weiterleitung Sie sind keine Synonyme Die WhatWG-URL-Standard Ist die Definition Browser tatsächlich implementiert, und es ist der Ort, um einen Streit darüber zu schlichten, was als Ursprung zählt.
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:8443. Dies ist diejenige, die Browsern am meisten am Herzen liegt, denn die Richtlinie mit demselben Ursprung - die Grundlage der Websicherheit - vergleicht Ursprünge und nicht Hostnamen. Zwei URLs teilen sich einen Ursprung nur, 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 noch unberührt angezeigt, sodass Sie die codierten und decodierten Formen vergleichen können - von unschätzbarem Wert, wenn Sie Doppelcodierung vermuten, wie meine %2520 Oauth-Fehler.
Zweitens, Wiederholte Tastendrohen Eine URL kann denselben Schlüssel mehr als einmal legitim tragen: ?tag=react&tag=typescript&tag=node. Viele naive Parser brechen diese zusammen, behalten nur den ersten oder letzten Wert und verlieren stillschweigend Daten Das ist falsch - wiederholte Schlüssel sind, wie HTML-Formulare Multi-Select-Felder übermitteln und wie viele APIs Arrays ausdrücken Der Parser behält jedes Vorkommen als eigene Zeile, in der Reihenfolge, so dass Sie alle drei Tags sehen Wenn Sie die Abfrage als JSON kopieren, werden wiederholte Schlüssel zu einem Array, was die Form ist, die der meiste Code erwartet.
Um dies zu verwenden, benötigen Sie nicht einmal eine vollständige URL. Fügen Sie nur eine Abfragezeichenfolge ein - color=red&size=42 - und das Tool analysiert es von selbst Es ist der schnellste Weg, den ich kenne, um einen Sinn für eine Webhook-Nutzlast oder einen Tracking-Link zu bekommen, den jemand weitergeleitet hat.
Wie verwende ich den URL-Parser?
Das Tool ist so konzipiert, dass es Ihnen aus dem Weg geht Fügen Sie eine URL in die einzelne Eingabe ein und sie analysiert live, während Sie tippen - keine Taste zum Drücken Ein Beispiellink wird vorinstalliert, sodass Sie sofort die vollständige Aufschlüsselung sehen können, und eine Schaltfläche Löschen 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 sagt Ihnen, es tat dies mit einer kleinen Notiz, so dass Sie nie verwirrt sind, woher das Schema kam Fügen Sie ein explizites Schema - http://, ftp://, ssh:// - und es respektiert stattdessen das.
Der Ausgang hat vier Zonen. Oben ist die Normalisierte URL - die kanonische Form der Browser' s-Engine produziert, mit einer Kopiertaste, die praktisch ist, um subtile Normalisierungsunterschiede zu erfassen 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 die große - OAuth-Flows, Payment Return URLs, SSO-Handshakes, die alle bei winzigen Fehlpaarungen scheitern, die erst sichtbar werden, wenn Sie beide URLs dekomponieren. 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 Reverse Engineering, 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 verhält sich Parsen zur Kodierung und zum slugs?
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 Macht die entgegengesetzte Richtung auf Zeichenebene - Leerzeichen und Sonderzeichen in ihre prozentual codierten Formen umwandeln, damit sie innerhalb einer URL überleben, und wieder zurück Wenn Sie einen Wert sicher in eine Abfragezeichenfolge einbetten müssen, oder eines dekodieren, das verstümmelt ist, ist das 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.
Slug Generation ist ein dritter, verwandter Job - einen menschlichen Titel wie & quot;10 Tipps für schnellere Builds" und es in einen sauberen Zustand verwandeln 10-tips-for-faster-builds Pfadsegment. Das ist was die Slug Generator Griffe, und es ist das, was das ordentliche produziert path Komponente liest der Parser später zurückDenken Sie es sich als Pipeline: slugify um gute Pfade zu bauen, codieren um Werte URL-sicher zu machen, analysieren um den fertigen Link zu prüfen Jedes Tool macht einen Teil des URL-Lebenszyklus und macht ihn 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 markiert es als IP und nicht als Domäne - nützlich, wenn Sie einen Link prüfen und sofort wissen möchten, ob er auf eine benannte Website oder eine blanke Adresse abzielt, was bei verdächtigen Links ein häufiges Signal ist. IPv6-Literale werden in eckige Klammern in eine URL gewickelt, wie in 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 Domainnamen sind der andere Randfall. Ein in Nicht-ASCII-Zeichen geschriebener Host - beispielsweise eine Domain mit akzentuierten oder nicht-lateinischen Buchstaben - wird von der URL-Engine von browser's 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 uk. Das ist eine bewusst einfache Regel - sie versucht nicht, mehrteilige Suffixe wie .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 nach # 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 aussieht wie %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 sind oft aussagekräftige Arrays, und wenn man sie fallen lässt, gehen Daten verloren.
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.
