Entwicklertools · URL-Encoder und -Decoder
WHATWG URL-Standard vs. RFC 3986: Warum Browser und Bibliotheken unterschiedlicher Meinung sind
· Hintergrund
URL-Kodierung Standards Entwicklertools
Es gibt zwei lebende Definitionen einer URL, und sie stimmen absichtlich nicht überein. In diesem Beitrag wird erklärt, warum die WHATWG ihren eigenen Standard geschrieben hat, sich die beiden in der Kodierung und Analyse unterscheiden und welchem Ihr Code folgt.
Die URL, die eine strikte Bibliothek ablehnt und die der Browser problemlos lädt – eine Zeichenfolge, zwei Urteile
Eine Zeichenfolge mit einem Backslash in JavaScript wird von Ihrem Browser möglicherweise problemlos als Teil des URL-Pfads interpretiert. Dieselbe Zeichenfolge erreicht ein Python-Bibliotheks-Backend und weigert sich, sie zu analysieren, da Backslashes nicht zulässig sind. Eine URL, zwei unterschiedliche Ergebnisse. Beides ist nicht falsch – sie folgen unterschiedlichen Standards. Der WHATWG-Standard beschreibt, was Browser tatsächlich mit realen URLs tun, einschließlich der Art und Weise, wie sie mit fehlerhaften Eingaben umgehen. RFC 3986 definiert eine formale Grammatik, der URLs idealerweise entsprechen sollten. Viele auf RFC 3986 basierende Backend-Bibliotheken erzwingen diese Grammatik strikt und lehnen alles Außerhalb davon ab.
Diese Divergenz ist wichtig, wenn Sie Daten zwischen Umgebungen verschieben. Eine von Browsern akzeptierte URL schlägt möglicherweise bei der Validierung in einem Backend-Tool fehl. Wenn Sie wissen, welchen Standard Ihr Code implementiert, können Sie das Debuggen von Phantomproblemen verhindern – URLs, die an einer Stelle einwandfrei funktionieren, an anderer Stelle jedoch ohne ersichtlichen Grund auf mysteriöse Weise fehlschlagen.
Warum die WHATWG von vorne begann – sie beschreibt, was Browser wirklich mit fehlerhaften Eingaben machen und nicht, was gültig ist
Die WHATWG-Arbeitsgruppe wurde 2004 gegründet, um zu standardisieren, wie Browser in der Praxis tatsächlich mit URLs umgehen, anstatt strengere formale Regeln zu definieren, die Browser nicht befolgen würden. RFC 2396 beschrieb eine formale Grammatikspezifikation, die jedoch von Browsern in der Praxis nie genau befolgt wurde. Reale Browser entwickelten praktische Regeln für die Toleranz von Leerzeichen, den Umgang mit maskierten Zeichen und die Wiederherstellung nach fehlerhaften Eingaben, die der RFC nicht vorhergesehen oder erwartet hatte.
RFC 3986 ist in 2005 mit formaler Grammatik für wohlgeformte URLs und strengen Anforderungen angekommen. Browser implementieren WHATWG; Backend-Bibliotheken implementieren häufig RFC 3986.
Codierungssätze im Vergleich zu reservierten Zeichen – wie sich die komponentenspezifischen Listen des URL-Standards auf die Kategorien von RFC 3986 beziehen
RFC 3986 unterteilt Zeichen in drei Kategorien: reserviert, nicht reserviert und alles andere, was codiert werden muss. Reservierte Zeichen wie Doppelpunkt, Schrägstrich, Fragezeichen und Hash haben in URLs eine strukturelle Bedeutung. Nicht reservierte Zeichen sind Buchstaben, Ziffern, Bindestrich, Unterstrich, Punkt und Tilde; diese sind immer sicher. Alles andere wird prozentual als Bytes kodiert. Der Standard sieht eine klare Regel vor: Wissen Sie, zu welcher Kategorie Ihr Charakter gehört.
Der WHATWG-URL-Standard verfolgt einen komponentenbasierten Ansatz. Es legt unterschiedliche Codierungsregeln für Schema, Autorität, Pfad, Abfrage und Fragment separat fest, anstatt globale Kategorien zu verwenden. Ein kaufmännisches Und-Zeichen kann in einem Pfad codiert sein, in einer Abfragezeichenfolge jedoch allein gelassen werden. Ein Leerzeichen ist immer kodiert, die genaue Darstellung variiert jedoch je nach Kontext. Dieses komponentenweise Design passt sich dem Browserverhalten viel besser an, erfordert jedoch die Kenntnis, welchen Teil der URL Sie codieren.
Fehlertoleranz: Leerzeichen, Backslashes und Tabulatoren – gibt einen Standard-Ausschuss und den anderen Reparaturen ein
Leerzeichen müssen unter beiden Standards zu %20 werden, Browser konvertieren jedoch stillschweigend literale Leerzeichen. Backslashes sind in beiden Standards verboten, einige Browser behandeln sie jedoch als Pfadtrennzeichen. Tabulatoren, Zeilenumbrüche und Steuerzeichen sind verboten. WHATWG gibt ein nachsichtiges Parser-Verhalten an: Konvertieren oder ignorieren.
Nicht-ASCII-Zeichen wie é oder 中 müssen mithilfe der UTF-8-Codierung prozentual codiert werden. RFC 3986 gibt den Zeichenkodierungsschritt selbst nicht wirklich an; Es geht davon aus, dass Bytes vorhanden sind, sagt aber nicht, wie man sie aus dem Text erhält. Der WHATWG-Standard erfordert ausdrücklich UTF-8: Wandeln Sie die Zeichenfolge zuerst in UTF-8 Bytes um und kodieren Sie sie dann in Prozent. Beide Standards erzielen das gleiche Codierungsergebnis, gehen jedoch von unterschiedlichen Grundannahmen aus und gehen nicht explizit auf die gleichen Dinge ein.
Arbeitsbeispiel: Parsen einer URL mit einem Backslash und einem Leerzeichen in beiden Modellen – die Ergebnisse verglichen
Nehmen Sie die Beispielzeichenfolge „https://example.com/café\ search“. Ein Browser stößt auf den Backslash und betrachtet ihn als Pfadzeichen. Er sieht das Leerzeichen und kodiert es in %20, wodurch etwa https://example.com/café%5C%20search. entsteht. Ein RFC-3986-Parser lehnt die gesamte URL sofort ab, da Backslashes und Leerzeichen verboten sind. Der Browser setzt die Analyse fort; Der strikte Parser stoppt vollständig. Versuchen Sie ein anderes Beispiel: „https://user@example.com:80/path?q=a&b=c". Beide Standards identifizieren Benutzerinformationen, Host, Port, Pfad und Abfrage eindeutig. Sie sind sich in dieser strukturierten URL völlig einig. Die Unstimmigkeit tritt nur bei ungewöhnlichen oder fehlerhaften Eingaben auf.
Öffnen Sie den URL-Encoder und -Decoder und vergleichen Sie den RFC-3986-Modus mit dem Browserverhalten. Fügen Sie eine Zeichenfolge mit Leerzeichen, Backslashes oder anderen Randfällen ein. Das Tool zeigt Ihnen genau, wie jeder Standard dieselbe Eingabe unterschiedlich umwandelt. Sie sehen sofort, welches strenger ist und was jedes einzelne tut.
Welches von Ihrer Umgebung verwendet wird – Browser und Knoten folgen dem URL-Standard; Viele Serverbibliotheken folgen dem allgemein beschriebenen RFC
In Browsern verwendet JavaScript standardmäßig den WHATWG-URL-Standard. Die URL-API setzt es genau um. Node.js verwendet auch WHATWG. Python-Bibliotheken implementieren in der Regel RFC 3986; urllib verfolgt es genau. Java-Bibliotheken variieren; java.net.URL tendiert zu RFC 3986. Rusts URL-Kiste folgt WHATWG. Das Netz/url von Go wird von WHATWG beeinflusst. Dies ist ein allgemeines Muster, keine absolute Regel.
Wenn Sie URLs programmgesteuert erstellen und diese zwischen Browser und Backend wechseln, wählen Sie einen Standard aus und bleiben Sie dabei. Verwenden Sie die URL-API des Browsers für WHATWG. Wenn Ihre Backend-Bibliothek strenger ist, ist das kein Widerspruch, sondern eine Designentscheidung.
Was hiervon nicht abgedeckt wird: Parsen von Hostnamen, IPv6-Literale und IDNA-Verarbeitung
Das Parsen von Hostnamen umfasst IDNA-, Punycode- und Registrarregeln, die über das eigentliche URL-Parsen hinausgehen. IPv6-Adressen, spezielle Schemata wie mailto: oder data: und leere Komponenten sind separate Themen, die sich vollständig von der prozentualen Kodierung unterscheiden. Die Beschränkungen der Domainlänge und der Gültigkeit des Hostnamens variieren je nach Registrar und sind für diese Diskussion nicht relevant. Ebenfalls ausgeschlossen: relative Referenzen und schemaspezifische Parsing-Regeln. Dieser Beitrag konzentriert sich nur auf Codierungs- und Parsing-Unterschiede.
Diese Diskussion konzentriert sich auf die Codierungs- und Parsing-Unterschiede, die diese Standards auszeichnen. Der Ausschluss von Hostnamenregeln, DNS-Regeln und schemaspezifischem Verhalten verhindert Verwirrung über Prozentkodierungsregeln.
Fazit: Dieselbe URL ist in einer Welt gültig und in einer anderen ein Fehler – wie der URL-Encoder und -Decoder Ihnen die einfache RFC-Codierung 3986 liefert, damit Sie sehen können, was der Browser wegnormalisiert hat
Dieselbe URL-Zeichenfolge kann unter einem Standard gültig und unter dem anderen ungültig sein. Beide liegen im Rahmen ihrer eigenen Designziele richtig. Wenn Sie URL-Komponenten programmgesteuert kodieren, verwenden Sie das richtige Tool für Ihre Umgebung. WHATWG beschreibt, was Browser tatsächlich tun; RFC 3986 definiert formale Grammatik. Der URL-Encoder und -Decoder zeigt RFC-3986-Regeln neben dem Browserverhalten an, sodass Sie genaue Unterschiede erkennen und auswählen können, was zu Ihrer Situation passt.
Probleme treten am häufigsten auf, wenn URLs die Grenzen zwischen Browser und Backend überschreiten. Um diesen Unterschied zu verstehen, muss man diesen Übergang absichtlich und nicht versehentlich oder versehentlich angehen.