Entwicklertools · URL-Encoder und -Decoder
Warum + zu einem Leerzeichen wird, wenn Sie eine Abfragezeichenfolge dekodieren, und wann nicht
· Wie es funktioniert
URL-Kodierung Javascript Entwickler-Workflow
Ob + Leerzeichen bedeutet, hängt davon ab, welchen Decoder Sie aufrufen. In diesem Beitrag wird erklärt, wie decodeURIComponent, URLSearchParams und Server-Frameworks jeweils + behandeln und wie man vermeidet, ein echtes Plus in ein Leerzeichen umzuwandeln.
Warum + zu einem Leerzeichen wird, wenn Sie eine Abfragezeichenfolge dekodieren, und wann nicht
HTML-Formularübermittlungen verwenden das Anwendungsformat/x-www-form-urlencoded, wobei Leerzeichen zum Pluszeichen werden. Ein Server, der name=Alice+Smith empfängt, ersetzt jedes Pluszeichen durch ein Leerzeichen, bevor er den Wert extrahiert. Wenn ein echtes Plus in Daten gehört, wie in einer Berechnung 5+3, kommt es nach dem Formdekodierungsschritt als 5 3 auf dem Server an. Diese unsichtbare Bekehrung ist die Wurzel der Verwirrung.
Die JavaScript-Dekodierung führt zu unterschiedlichen Ergebnissen, je nachdem, welche Funktion Sie verwenden. URLSearchParams behandelt Plus als Leerzeichen, passend zum Serververhalten. Aber decodeURIComponent lässt Plus unberührt und behandelt es wörtlich. Diese Asymmetrie zwischen Funktionen ist der Grund, warum dieselbe Eingabe unterschiedlich dekodiert wird. Ein Entwickler, der erwartet, dass beide Decoder das gleiche Ergebnis liefern, stellt fest, dass dies nicht der Fall ist.
Zwei Codierungen, die gleich aussehen – RFC 3986 Prozent-Codierung im Vergleich zu Anwendung/x-www-form-urlencoded
Zwei Kodierungsstandards sehen ähnlich aus, funktionieren aber unterschiedlich. RFC 3986 definiert Prozentkodierung: Jedes Zeichen wird zu %HH. Leerzeichen wird zu %20. Der application/x-www-form-urlencoded-Standard fügt eine Abkürzung hinzu: Leerzeichen können plus sein. Beides funktioniert im Formularkontext, Plus ist jedoch optional und spezifisch für diesen Standard. Es handelt sich um unterschiedliche Domänen mit ähnlichem Erscheinungsbild.
Der Aufruf von decodeURIComponent wendet nur die RFC-3986-Dekodierung an. Es liest %20 als Leerzeichen und Plus als wörtliches Plus. URLSearchParams wendet Formendekodierungsregeln an: Prozent-Escapezeichen werden zu ihren Zeichen und Pluszeichen werden zu Leerzeichen. Die beiden Funktionen lösen dasselbe Problem in unterschiedlichen Domänen. Wenn man sie vermischt, verschwindet entweder ein echtes Plus oder ein Leerzeichen wird zu einem Plus und kann nicht umgewandelt werden.
decodeURIComponent lässt + allein; URLSearchParams verwandelt es in ein Leerzeichen – die beiden JavaScript-Verhaltensweisen im Vergleich
Das Serververhalten variiert, was das Problem verschärft. Rails oder Django wenden automatisch die Formregel an: Plus wird zu Leerzeichen. Aber das Extrahieren und manuelle Dekodieren der rohen Abfragezeichenfolge mit einem URL-Decoder lässt Plus intakt. Derselbe Wert, der von verschiedenen Frameworks verarbeitet wird, führt zu unterschiedlichen Ergebnissen. Servercode behandelt dies häufig implizit und verbirgt das Problem, bis Sie einen benutzerdefinierten Decoder schreiben.
Beispiel: Ein Telefonnummernfeld speichert +1-555-0100 mit Plus als Ländervorwahl. Ein HTML-Formular kodiert es als %2B1-555-0100, da JavaScript das Plus als %2B kodierte. Der Server empfängt dies. Wenn die Formdekodierung angewendet wird, wird %2B zu einem Plus und der Wert ist korrekt. Wenn ein Proxy die Codierung entfernt, erzeugt der Aufruf von decodeURIComponent für das Ergebnis +1-555-0100. Jede Schicht dekodiert einmal.
Was Server tun – allgemeines Framework-Verhalten in der Abfragezeichenfolge und im Anforderungstext, allgemein beschrieben
JavaScript kann Werte mithilfe von encodeURIComponent codieren. Bei gegebenem a+b ergibt sich a%2Bb. Wenn diese codierte Zeichenfolge einen Server oder einen formbewussten Decoder erreicht, decodiert %2B als Pluszeichen und das Ergebnis ist korrekt. Wenn Sie stattdessen mit der Formularregel codieren, wird ein Leerzeichen zu einem Plus und ein echtes Plus zu %2B. In jedem Fall erzeugt die Codierung ein %2Bb. Die Interpretation hängt davon ab, welche Dekodierungsregel gilt.
Testen Sie den Rundlauf: Beginnen Sie mit a+b. Codieren Sie mit encodeURIComponent, um eine %2Bb zu erhalten. Dekodieren Sie a%2Bb mit decodeURIComponent und stellen Sie a+b wieder her. Übergeben Sie a+b an URLSearchParams: Plus wird als Leerzeichen behandelt und ein b erzeugt. Übergeben Sie a%2Bb an URLSearchParams, um a+b zurückzubekommen. Die gleiche Eingabe, die auf zwei Arten dekodiert wird, erzeugt unterschiedliche Ausgaben, je nachdem, welchen Decoder Sie verwenden.
Beispiel: „a+b“ und „a%2Bb“ durch beide Decoder – vier Ergebnisse in einer Tabelle
Häufige Fehler folgen direkt. Ein Entwickler dekodiert mit decodeURIComponent und fragt sich, warum eingehende Formulardaten mit einem echten Plus kaputt gehen. Sie hätten URLSearchParams verwenden sollen. Umgekehrt verwendet jemand URLSearchParams, obwohl er decodeURIComponent verwenden sollte, und jedes wörtliche Plus verschwindet. Zweimaliges Codieren erzeugt %252B und erfordert übereinstimmende Encoder-Decoder-Paare, um korrekt zu dekodieren.
Ein weiterer Fehler besteht darin, eine Abfragezeichenfolge manuell als ?q=value ohne Codierung zu erstellen. Jedes kaufmännische Und oder Gleichheitszeichen im Wert erstellt stillschweigend einen neuen Parameter. Der Browser zweifelt nicht an der Verkettung; es behandelt das Ergebnis als ordnungsgemäß geformt. Nur die absichtliche Kodierung mit encodeURIComponent verhindert dies. Der URL-Encoder und -Decoder zeigt alle drei Funktionen und zeigt, was jede einzelne erzeugt.
Häufige Fehler – doppeltes Dekodieren oder Kodieren eines Leerzeichens als + in einem Pfadsegment
Die Formularkodierungsregel heißt application/x-www-form-urlencoded, da sie den Content-Type-Header des HTTP-Anforderungstexts beschreibt. HTML-Formulare ohne Datei-Uploads senden den Text in diesem Format. Auch Abfragezeichenfolgen in URLs verwenden diese Konvention, obwohl sie technisch gesehen keinen offiziellen Kodierungsstandard haben. URL-Spezifikationen behandeln die Abfrage als undurchsichtig; Plus-Bedeutung ist nicht vorgeschrieben. Aber in Webanwendungen bedeutet Plus normalerweise Platz.
Um korrektes Verhalten zu gewährleisten, bewusst kodieren und mit der passenden Funktion dekodieren. Wenn Sie mit encodeURIComponent codiert haben, decodieren Sie mit decodeURIComponent. Wenn Sie HTML-Formulardaten oder Anforderungstexte im Formularformat lesen, verwenden Sie URLSearchParams. Raten Sie niemals aufgrund des Aussehens. Eine Zeichenfolge wie a+b ist mehrdeutig. Decoder sind nicht austauschbar.
Was dies nicht abdeckt – mehrteilige Formulardaten und JSON Anforderungstexte
Mehrteilige Formulardaten, JSON Anforderungstexte und andere Standards haben separate Codierungsregeln. JSON verwendet kein Pluszeichen für Leerzeichen oder Prozentkodierung; es verwendet Unicode-Escapezeichen. Multipart verwendet unterschiedliche Grenzen. In diesem Artikel werden nur Abfragezeichenfolgen und formularcodierte Körper behandelt, da dort die Plus-Mehrdeutigkeit auftritt. Überprüfen Sie immer den Content-Type-Header und den RFC, der ihn definiert.
Kodieren Sie ein literales Plus immer als %2B, wenn es in einen Abfragewert gehört. URL-Encoder und -Decoder zeigen, wie Plus im Komponentenmodus als %2B geschützt ist, getrennt von Leerzeichen, die zu %20 werden. Führen Sie a+b und a%2Bb durch jeden Modus und prüfen Sie dann die Ergebnisse. Dieser Vergleich zeigt, warum dieselbe Eingabe unterschiedlich dekodiert wird. Der Unterschied besteht im korrekten Verhalten zweier unterschiedlicher Standards.
Takeaway: Kodieren Sie ein Literal-Plus immer als %2B – wie der URL-Encoder und -Decoder zeigt, wie ein Wert als prozentkodierter Abfragewert aussieht
Fazit: Plus in einer Abfragezeichenfolge ist die Kurzform der Codierung für Leerzeichen, kein wörtliches Plus, es sei denn, es stammt aus einer Codierung, die es als %2B schützt. Der falsche Decoder verliert diesen Schutz. URLSearchParams ist in modernem JavaScript am sichersten; Es übernimmt die Formularkodierung und ermöglicht den Zugriff auf benannte Parameter. Bei Rohzeichenfolgen schützt encodeURIComponent alles; decodeURIComponent interpretiert %20 und Prozente, behandelt Plus jedoch wörtlich.
Testen Sie dies: Erstellen Sie ?x=a+b von Hand und fügen Sie es in den URL-Encoder und -Decoder ein. Untersuchen Sie es und beobachten Sie, wie URLSearchParams es in Parameter x mit dem Wert a b aufteilt. Fügen Sie ?x=a%2Bb ein und sehen Sie den Wert a+b. Verwenden Sie encodeURIComponent, um die URL zu erstellen und zu vergleichen. Diese visuelle Bestätigung verdeutlicht die Regel: Formularregeln verwenden Plus, Prozentkodierung verwendet %20, die Mischung dieser beiden ist der Grund, warum Plus im Raum verschwindet.