Entwicklertools · URL-Encoder und -Decoder
Was der URL-Konstruktor für Sie kodiert: die Prozentkodierungssätze des Browsers
· Wie es funktioniert
URL-Kodierung Javascript waswg Web-APIs
Die URL-API codiert einige Zeichen stillschweigend prozentual und lässt andere in Ruhe, abhängig davon, in welchem Teil der URL sie landen. In diesem Beitrag werden die WHATWG-Codierungssätze erläutert und wie die Ausgabe vorhergesagt werden kann.
Das Leerzeichen, das zu %20 wurde, und das | das blieb – ein konkreter Fall, in dem new URL() einen Pfad teilweise codierte
Wenn new URL("https://example.com/hello world") ausgeführt wird, wird der Speicherplatz stillschweigend zu %20. Aber new URL("https://example.com/hello|world") lässt die Pipe unberührt. Dieser Unterschied ist nicht zufällig. Der WHATWG-URL-Standard definiert separate Zeichensätze zur Codierung für jede URL-Komponente: Pfad, Abfrage, Fragment und Benutzerinformationen haben jeweils ihre eigenen Regeln. Um diese Sätze zu verstehen, muss man vorhersagen, was der Konstruktor tun wird.
Der Speicherplatz benötigt eine prozentuale Codierung, da er über HTTP unsicher ist und die Lesbarkeit beeinträchtigt. Die Pipe ist anders: Sie ist kein reserviertes Zeichen, das die Struktur aufteilt, sodass der Browser sie in Ruhe lässt. Die Grenze zwischen Sicherheit und Lesbarkeit wird durch WHATWG gezogen, nicht durch Vermutungen. Beim Testen von „Hallo Welt“ wird die Codierung angezeigt. Das Testen von „hello|world“ zeigt die Grenzen für jeden URL-Teil auf.
Eine URL, mehrere Codierungssätze – Pfad, Abfrage, Fragment und Benutzerinformationen – jeder hat seine eigene Liste von Zeichen, die maskiert werden sollen
Eine URL enthält mehrere Regionen mit jeweils eigenen Codierungsregeln. Der Pfad folgt einem Satz, fragt einen anderen ab, fragmentiert einen dritten, userinfo einen vierten. Ein Leerzeichen wird im Pfad und in der Abfrage zu %20. Ein Gleichheitszeichen bleibt in der Abfrage, wo es Schlüssel und Werte trennt, aber encodeURIComponent wandelt es in %3D um. Der URL-Konstruktor kennt seinen Kontext und wendet für jeden Teil die richtigen Regeln an.
Die Codierungssätze sind präzise und klein. Path verfügt über eine eigene Zeichenliste. Die Abfrage hat eine ähnliche, aber unterschiedliche Liste. Dies spiegelt wider, welche Zeichen eine strukturelle Bedeutung haben. Ein Schrägstrich teilt Pfadsegmente, sodass encodeURIComponent sie als %2F codiert. Im Fragment kann ein Schrägstrich vorhanden sein, ohne dass etwas beschädigt wird. Um die WHATWG-Regeln zu verstehen, muss die Ausgabe vorhergesagt werden, ohne dass Code ausgeführt werden muss.
Warum die Prozentkodierung einseitig ist: Was kodiert bleibt, bleibt auch so
Der URL-Konstruktor führt eine unidirektionale Normalisierung durch. Übergeben Sie „%20“ an die neue URL und %20 wird unverändert erzeugt. Der Konstruktor erkennt es als bereits codiert und lässt es in Ruhe. Aus diesem Grund ist die doppelte Kodierung wichtig: einmal kodieren, den Konstruktor durchlaufen und die Kodierung bleibt bestehen. Der Konstruktor dekodiert, interpretiert und kodiert nicht neu; es liest vorwärts.
Diese unidirektionale Eigenschaft wirkt sich auf Anwendungen aus, die URL.href als kanonisch vertrauen. Wenn Sie Benutzereingaben mit Ihrem Pfad verketten, wird die Eingabe normalisiert, aber nicht dekodiert. Ein Wert wie „meine+Datei“ bleibt unverändert oder wird in manchen Kontexten zu „meine%2BDatei“. Späterer Code, der decodeURIComponent verwendet, liest möglicherweise Plus als Leerzeichen, wenn er aus Formulardaten stammt. Der Konstruktor normalisiert einmal; Danach ist Ihr Wert festgelegt.
Bearbeitetes Beispiel: Übergabe derselben chaotischen Zeichenfolge durch new URL() und Lesen von href, pathname und searchParams – drei verschiedene Ansichten
Nehmen Sie „hello world&foo=bar|test#anchor“ und fügen Sie es durch eine neue URL mit verschiedenen Komponenten ein. Der Speicherplatz wird überall zu %20. Das kaufmännische Und-Zeichen im Pfad bleibt erhalten (dort gibt es keine strukturelle Bedeutung), aber in der Abfrage bleibt es auch bestehen (trennt Parameter, sodass bei der Normalisierung die Grenze zwischen „q=" und „foo=bar" verloren gehen würde). Pipe und Hash verhalten sich je nach Standort unterschiedlich.
Das Lesen von href, pathname und searchParams zeigt drei verschiedene Ansichten. Pfadname zeigt den codierten Pfad ohne Schema, Host oder Abfrage. searchParams liefert dekodierte Parameter, sodass „Hallo+Welt“ aus Formulardaten zu einem Leerzeichen wird. Die Sucheigenschaft behält die Literalzeichenfolge bei. href zeigt die vollständige normalisierte URL. Diese existieren auf einem Objekt nebeneinander; Welche Sie verwenden, hängt von Ihrem nächsten Schritt ab.
URLSearchParams und die Formularkodierungsregel – warum sie + für Leerzeichen erzeugt, während Pfadname %20 erzeugt
URLSearchParams wendet Formularkodierung an: Leerzeichen werden zu Pluszeichen, nicht zu %20. new URLSearchParams({q: "hello world"}) erzeugt "q=hello+world", nicht "q=hello%20world". Dies ist die historische Regel application/x-www-form-urlencoded. Wenn Sie diese Zeichenfolge jedoch als Rohabfrage an eine neue URL übergeben, bleibt das Plus plus; nur URLSearchParams dekodiert es als Leerzeichen. Der Konstrukteur bleibt dem treu, was er sieht.
Dieser Pluszeichenunterschied verursacht häufige Fehler. Eine URL aus der Adressleiste verwendet %20 für Leerzeichen. Formulardaten verwenden Plus. Wenn Sie mit decodeURIComponent (das wörtlich „Plus“ liest) anstelle von URLSearchParams.get dekodieren, werden Leerzeichen zu Pluszeichen. Der URL-Encoder und -Decoder zeigt beides: Fügen Sie „hello+world“ ein und vergleichen Sie die Komponenten- und Formularmodi, um zu sehen, wo Platz erscheint.
Vergleich mit encodeURI – wo die beiden übereinstimmen und wo sie voneinander abweichen
Der URL-Konstruktor und encodeURIComponent sind unterschiedliche Tools. encodeURIComponent codiert fast alles außer nicht reservierten Buchstaben, Ziffern und - _ . ! ~ * ' ( ). Es setzt keinen Kontext voraus. Der URL-Konstruktor analysiert eine tatsächliche URL und wendet WHATWG-Regeln pro Komponente an. encodeURIComponent wandelt „hello/world"“ in „hello%2Fworld“ um; neue URL sieht Schrägstriche als Pfadtrennzeichen. Gleiche Eingabe, andere Ausgabe.
Verwenden Sie encodeURIComponent beim Erstellen einer URL durch Verketten von Teilen. Verwenden Sie URLSearchParams oder den URL-Konstruktor für vollständige oder teilweise URLs. Verwenden Sie encodeURIComponent nicht für eine ganze URL. Sie werden den Plan zerstören. Vergleichen Sie das Ergebnis mit der Absicht. Der Browser erzwingt URL-Strukturmeinungen und die neue URL implementiert sie. Der URL-Encoder und -Decoder zeigt beide Ansichten nebeneinander an.
Was dies nicht abdeckt – Host-Parsing, IDNA und spezielle versus nicht spezielle Schemata
Der WHATWG-URL-Standard ist die Quelle der Wahrheit, obwohl das Lesen Geduld erfordert. Die Codierungssätze werden in Algorithmusfragmenten und nicht in einfachen Listen definiert. In der Praxis ist das Verständnis des Prinzips wichtiger als das Auswendiglernen von Sätzen. Der Pfad erlaubt mehr Zeichen (Schrägstriche sind strukturell); Die Abfrage hat ihre eigenen Regeln. Fragment hat die geringsten Einschränkungen (wird clientseitig behandelt, niemals an Server gesendet). Jede Komponente hat ihre eigenen Regeln; Wenn Sie das wissen, wissen Sie, wo Sie suchen müssen.
Normalisierung und Validierung sind unterschiedliche Grenzen. Der Konstruktor normalisiert: Bereinigt die Prozentkodierung, wendet Komponentenregeln an und gibt eine kanonische Form an. Es wird keine Validierung durchgeführt: Es werden ungültige Zeichen ausgegeben, aber leere Hosts werden akzeptiert. Der Konstruktor ist hinsichtlich des Formats streng, bei der Interpretation jedoch nachsichtig. Informationen zur genauen Einhaltung der Spezifikationen finden Sie im Abschnitt „Prozentcodierte Bytes“ von WHATWG. Verwenden Sie für die alltägliche Erstellung URLSearchParams, die URL-API und reale Beispiele.
Takeaway: Der Parser hat Meinungen – wie der URL-Encoder und -Decoder Ihnen die einfache prozentuale Codierung eines Werts oder einer Adresse anzeigt, damit Sie sie mit dem vergleichen können, was der Browser erzeugt hat
Zu den hier nicht unterstützten WHATWG-Funktionen gehören Host-Parsing mit IDNA-Konvertierung (internationale Domänennamen in ASCII) und die Behandlung spezieller und nicht spezieller Schemata. Datei: URLs verwenden die Berechtigung für doppelte Schrägstriche. Daten: URLs nicht. Der Konstruktor erzwingt diese Regeln. Das Konvertieren von Hostnamen und das Bestimmen des Sonderstatus gehört zum Lesen von Spezifikationen und nicht zum Kodieren von Prozenten. Dies ist wichtig, wenn URLs über verschiedene Schemata hinweg erstellt werden.
Testen Sie Ihre URL-Konstruktion, indem Sie die Browserinterpretation mit den Erwartungen vergleichen. Erstellen Sie mit einer neuen URL und lesen Sie die wichtigen Eigenschaften: href für vollständiges Formular, Pfadname für Pfad, Suche nach Rohabfrage, searchParams für dekodiert. Wenn Sie von der Ausgabe überrascht sind, fügen Sie sie in den URL-Encoder und -Decoder ein und folgen Sie der Transformation Schritt für Schritt. Das Tool zeigt neben der Rohcodierung auch eine normalisierte Ausgabe an und verdeutlicht so den Unterschied. Um die WHATWG-Sets zu verstehen, müssen Sie die Browserauswahl verstehen und wissen, wie man mit ihnen arbeitet.