Entwicklertools · URL-Encoder und -Decoder
encodeURI vs encodeURIComponent: welche Zeichen jeder in Ruhe lässt
· Wie es funktioniert
URL-Kodierung Javascript Entwickler-Workflow
Die beiden JavaScript-Funktionen unterscheiden sich um genau elf Zeichen, und wenn Sie die falsche Funktion auswählen, wird entweder eine URL beschädigt oder ein Wert kann nicht maskiert werden. In diesem Beitrag werden die Sätze erläutert und eine Regel aufgeführt, die Sie sich merken können.
Die Suche hat alles zurückgegeben, weil das & in „R&D“ die Abfrage aufgeteilt hat – ein konkreter Fehler der falschen Funktion
Eine Suche nach R&D kann versehentlich Ergebnisse für R zurückgeben, wenn der Code ?q=R&D von Hand erstellt. Das kaufmännische Und ist ein Trennzeichen zwischen Abfrageparametern. Es bleibt nicht als Teil von q erhalten, es sei denn, Sie codieren den Wert. Die Wahl von encodeURI für dieses kleine Stück ist der Fehler, kein Serverfehler. Die sicherste Option im Anwendungscode ist oft URLSearchParams, aber das Verständnis der beiden JavaScript-Grundelemente erleichtert das Debuggen von vorhandenem Code erheblich.
Was beide Funktionen gemeinsam haben – der uneingeschränkte Satz, den sie nie berühren, und die UTF-8-Prozentkodierung, die sie beide anwenden
Bei beiden Methoden bleiben ASCII-Buchstaben, Ziffern und die uneingeschränkte Interpunktion - _ übrig. ! ~ * ' ( ) bleibt gemäß den Kodierungsregeln von JavaScript unberührt. Sie konvertieren Nicht-ASCII-Zeichen in UTF-8 bytes, bevor sie Prozenttripel schreiben: é wird zu %C3%A9, kein einziges lateinisches-1 byte. Sie kodieren ein Leerzeichen auch als %20. Bei der Prozentkodierung geht es darum, die Struktur eines URIs beizubehalten. Es handelt sich nicht um HTML-Escape, Eingabevalidierung oder Schutz vor schädlichen Skripten auf der empfangenden Seite.
Die elf Zeichen, die nur encodeURI behält, bleiben erhalten – ; , / ? : @ & = + $ # und warum jedes in einer URL eine strukturelle Bedeutung hat
encodeURI behält zusätzlich elf Strukturzeichen bei, die encodeURIComponent kodiert: ; , / ? : @ & = + $ #. Bei einer vollständigen Adresse bleibt der Pfad und die Abfragesyntax erhalten, wenn Sie den Schrägstrich und das Fragezeichen allein lassen. Bei einem Abfragewert würde das Durchlassen von & oder = die Parameterliste ändern, während ein # ohne Escapezeichen ein Fragment starten kann. Die Funktionen unterscheiden sich genau deshalb, weil eine für eine ganze Adresse und die andere für eine Komponente innerhalb dieser Adresse gedacht ist.
Eine Regel, die gilt: Werte erhalten encodeURIComponent, vollständige URLs erhalten encodeURI – und warum „vollständige URL“ seltener ist, als es sich anhört
Werte erhalten fast immer encodeURIComponent; Vollständige, bereits strukturierte Adressen sind der seltenere Fall für encodeURI. Verwenden Sie für eine URL, die Sie programmgesteuert erstellen, die URL-API, um Pfad- und Suchparameter zu verarbeiten, anstatt eine Mischung aus codierten und rohen Teilen zu verketten. Codieren Sie nicht eine gesamte URL mit encodeURIComponent und erwarten Sie dann, dass Schrägstriche und Doppelpunkte weiterhin als Trennzeichen fungieren. Umgekehrt sollten Sie den Abfragebegriff eines Benutzers nicht über encodeURI einspeisen und sein kaufmännisches Und-Zeichen aktiv lassen.
Ausgearbeitetes Beispiel: Dieselbe Zeichenfolge durch beide Funktionen – eine Ausgabetabelle für einen Wert mit Leerzeichen, &, / und einem Akzent
Nehmen Sie F&E/Café als einen Abfragewert. encodeURIComponent gibt R%26D%20%2F%20caf%C3%A9 zurück und schützt das kaufmännische Und und den Schrägstrich. encodeURI gibt R&D%20/%20caf%C3%A9 zurück, wobei die strukturelle Interpunktion erhalten bleibt; Ein naives Präfix ?q= würde nun ein unbeabsichtigtes Trennzeichen erzeugen. Beide kodieren den Raum und den Akzent, sodass ein Test, der nur „Hallo Welt“ verwendet, die wichtige Unterscheidung verfehlt. Vergleichen Sie die generierten Zeichenfolgen in ToolAcre, fügen Sie sie dann in einen URL-Parser ein und prüfen Sie, wie viele Abfrageparameter angezeigt werden.
Häufige Fehler: Codieren einer vollständigen URL mit encodeURIComponent und Decodieren mit dem falschen Gegenstück
Das Codieren einer vollständigen URL als eine Komponente erzeugt %3A%2F%2F, wo ein Verbraucher :// erwartet hat. Durch das Dekodieren einer gesamten Adresse vor der Validierung können reservierte Trennzeichen mit neuen Bedeutungen wieder eingeführt werden. Vermeiden Sie außerdem die doppelte Codierung eines Werts, der bereits %26 enthält: Das Prozentzeichen selbst kann zu %25 werden, sodass eine zweite Decodierungsebene möglicherweise erneut die Bedeutung ändert. Koppeln Sie encodeURIComponent mit decodeURIComponent für eine Komponente und behandeln Sie fehlerhafte Prozent-Escapezeichen als Eingabefehler.
Was hiervon nicht abgedeckt wird: Formularkodierung mit + und Erstellen von URLs mit URLSearchParams
Bei der Codierung von HTML-Formularabfragen wird ein Pluszeichen für ein Leerzeichen in application/x-www-form-urlencoded verwendet, das sich von der %20-Ausgabe dieser beiden Funktionen unterscheidet. URLSearchParams übernimmt diese Formularregeln für Sie. In diesem Artikel geht es nicht um die Pfadnormalisierung, die Konvertierung von Unicode-Hostnamen oder die Entscheidung, ob eine dekodierte URL sicher angefordert werden kann. Die URL-Codierung ist ein Darstellungsschritt, keine Autorisierungsrichtlinie.
Fazit: Codieren Sie die Teile, nicht das Ganze – wie der URL-Encoder und -Decoder beide Modi anzeigt, damit Sie den Unterschied an Ihrer eigenen Eingabe erkennen können
Die einprägsame Grenze ist Teile versus Ganzes: Ein Parameterwert ist ein Teil, also verwenden Sie encodeURIComponent oder URLSearchParams. Der URL-Encoder und -Decoder zeigt beide Browserfunktionen für dieselbe Zeichenfolge an und hält das Experiment lokal. Testen Sie die Eingabe mit &, =, #, Schrägstrich und einem Akzent, bevor Sie entscheiden, dass zwei Encoder austauschbar sind.