Entwicklertools · URL-Encoder und -Decoder
Plus versus %20: der Anwendungsverlauf/x-www-form-urlencoded
· Hintergrund
URL-Kodierung HTML-Formulare http-Standards
Formulare kodieren ein Leerzeichen als +, während der URI-Standard %20 sagt und der Grund historisch ist. Dieser Beitrag zeichnet die Konvention von frühen HTML-Formularen bis zur heutigen WHATWG-Definition nach und erklärt, warum sie nie verschwunden ist.
Plus im Vergleich zu %20 – warum Formulare und URIs Leerzeichen unterschiedlich kodieren
Als GET übermittelte HTML-Formulare kodieren Leerzeichen als Pluszeichen in der Abfragezeichenfolge. Das gleiche Leerzeichen wird zu %20 in URLs, die auf RFC 3986 folgen. Beide sind richtig, weil sie unterschiedlichen Standards folgen. Formularfelder, die Leerzeichen enthalten, werden in der Formularcodierung zu name=value+with+spaces, in RFC jedoch zu %20 3986. Die Plus-Prozent-Zwanzig-Unterscheidung gibt an, welcher Standard für Ihre Daten gilt.
Die Formularkodierung verwendet Pluszeichen für Leerzeichen als historische Konvention aus RFC 1866 (1995), der ursprünglichen Formularübermittlungsdefinition von HTML 2.0. GET fordert codierte Leerzeichen als Pluszeichen an und reserviert Plus für Literal + codiert als %2B. Diese Regel gilt nur für application/x-www-form-urlencoded,, nicht für die allgemeine URI-Syntax. Milliarden von Server-Frameworks wurden von dieser Konvention abhängig. Der Test beider zeigt deutliche Unterschiede: Der Formularmodus erzeugt ein Plus; Der URI-Modus erzeugt %20. Der URL-Encoder und -Decoder bietet beide Modi zum direkten Vergleich.
Frühe HTML-Formulare und GET-Übermittlung – wie die Formularkodierung definiert wurde und warum + gewählt wurde
RFC 1866 (1995) definierte Formularübermittlung, bei der Leerzeichen zu Pluszeichen und wörtliches Pluszeichen zu %2B werden. Dies galt nur für die Anwendung/x-www-form-urlencoded. RFC 3986 spezifizierte %20 für die allgemeine URI-Syntax. Zwei Standards existierten bewusst nebeneinander.
RFC 2396 hat die Zeichensätze strenger geklärt als frühere Standards. Es formalisierte reservierte Zeichen, die der URI-Struktur dienen, im Vergleich zu nicht reservierten Zeichen als Literaldaten. Standardisierungsgremien kodifizieren das Browser- und Proxy-Verhalten im Laufe seiner Entwicklung. RFC 3986 kam später, ohne das Codierungsverhalten zu ändern, sondern lediglich die Notation zu klären. Alle aktuellen Browser standardisieren die UTF-8-Kodierung. HTML-Formulare über Senden-Schaltflächen senden das application/x-www-form-urlencoded-Format mit Pluszeichen für Leerzeichen. Bei der manuellen URI-Konstruktion wird %20 verwendet. Das Verständnis beider Standards verhindert Integrationsüberraschungen.
RFC 1866 und spätere HTML-Spezifikationen – wo die Regel niedergeschrieben wurde und wie sie von der URI-Syntax abweicht
WHATWG URL Standard gibt an, dass URLSearchParams.toString() eine application/x-www-form-urlencoded-Ausgabe mit Pluszeichen für Leerzeichen erzeugt. Prozentcodierungen des URL-Konstruktors gemäß RFC 3986. Browser navigiert zu URL mit Leerzeichen kodiert %20; Das als GET übermittelte Formular kodiert Plus. Diese grundsätzlich unterschiedlichen Werkzeuge dienen unterschiedlichen Zwecken. Manuelle encodeURIComponent gibt %20 für Leerzeichen an – RFC-3986-Stil. Formulare, die an dieselbe URL gesendet werden, senden Plus. Server, die Formularübermittlungen analysieren, erwarten ein Plus; Der Empfang von %20 führt zu stillen Parameterfehlern.
Das Testen beider zeigt serverseitige Annahmen an, auf die Sie angewiesen sind. JavaScript URLSearchParams bietet sicheres Ausblenden der Codierung im Formularstil sowie Komplexität. Erstellen Sie URLSearchParams, hängen Sie Einträge an und rufen Sie toString() auf, um application/x-www-form-urlencoded mit dem richtigen Pluszeichen zu erhalten. Alternativ können Sie Abfragezeichenfolgen mit encodeURIComponent erstellen; Sie erhalten RFC 3986 %20. Mischen Sie niemals Ansätze. Abfragezeichenfolgen mit manuellem Plus und encodeURIComponent erzeugen Mehrdeutigkeit. Empfänger können nicht unterscheiden, ob Plus ein Leerzeichen oder ein wörtliches Plus bedeutet. Standardansätze funktionieren konsistent.
Der heutige URL-Standard – application/x-www-form-urlencoded als separater Serialisierer mit eigenen Regeln
JSON APIs lehnen Plus normalerweise als Leerzeichen ab und erwarten %20 gemäß RFC 3986. Clients, die Plus senden, schlagen stillschweigend fehl: Parameter verschwinden. Das Testen von APIs mit beiden Kodierungen zeigt, welchen Standard sie akzeptieren. URLSearchParams in JavaScript übernimmt die Formularkodierung. URL-Encoder und -Decoder erzeugen RFC 3986 %20.
Die HTML-Formularübermittlung übernimmt automatisch die Kodierung. Ihr Server-Framework entscheidet, welche Regeln gelten. Rails, Django und PHP behandeln Plus automatisch als Leerzeichen in empfangenen Formulardaten. Aber das manuelle Erstellen von Abfragezeichenfolgen für dieselben Endpunkte ist von enormer Bedeutung. Ein hochgeladenes Plus schafft Unklarheiten. Spezifikationskonformität und reales Serververhalten weichen geringfügig voneinander ab. Dokumentieren Sie, welchen Standard Ihre Endpunkte erwarten. Testen Sie beide Codierungsstile. Defensiver Code handhabt beides elegant.
Funktioniertes Beispiel: Das gleiche Formularfeld wird als Abfragezeichenfolge und als Anforderungstext gesehen – mit + an einer Stelle und %20 an einer anderen
JavaScript 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 eine historische application/x-www-form-urlencoded-Regel, die speziell in JavaScript integriert ist. Wenn Sie diese Zeichenfolge jedoch als Rohabfrage an eine neue URL übergeben, bleibt das Plus als Plus erhalten. nur URLSearchParams dekodiert es als Leerzeichen. Der Konstruktor bleibt dem treu, was er sieht. Pluszeichenunterschiede verursachen häufige Fehler, wenn Funktionen falsch gemischt werden.
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 die 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, wenn Sie URLs durch Verketten von Teilen erstellen. Verwenden Sie URLSearchParams oder den URL-Konstruktor für vollständige oder teilweise URLs.
Warum es nicht behoben werden kann – Jahrzehntelange Server und Clients, die vom aktuellen Verhalten abhängen
Prozentkodierungsregeln haben sich von RFC 1738 (1994) über RFC 2396 (1998) zu RFC 3986 (2005) entwickelt. Jede Generation klärte Unklarheiten. RFC 1738 war konservativ und behandelte Zeichen unsicher, da das frühe Web nur begrenzte Zeichenunterstützung bot. Bereitstellungen wurden auf UTF-8 standardisiert, Implementierungen wurden konsistent. Spätere Standards lockerten die Beschränkungen für Zeichen, die sich systemübergreifend als sicher erwiesen. Moderner Konsens: UTF-8 überall. Normungsgremien legen großen Wert auf Abwärtskompatibilität. Eine Lösung würde eine weltweite Koordination erfordern – nach drei Jahrzehnten unmöglich. Zwei Standards koexistieren bewusst.
Tests mit Plus und %20 offenbaren Serverannahmen. Serverprotokolle zeigen, was Clients senden. Formulare verwenden plus; Manuelle URLs verwenden %20. Wählen Sie nach Kontext und befolgen Sie die API-Dokumentation.
Was hiervon nicht abgedeckt ist – mehrteilige /form-data- und JSON-Körper
Das Testen beider Kodierungen zeigt das Serververhalten. Senden Sie a+b in beide Richtungen. Viele Produktionsserver erwarten eine Formularkodierung; Neuere APIs erwarten %20. Ihre Wahl hängt von den Erwartungen des Empfängers ab. URLSearchParams übernimmt die Formularkodierung; encodeURIComponent übernimmt die RFC-Codierung.
Kombinieren Sie niemals Kodierungsmethoden. Der mit encodeURIComponent %2B codierte und dann an URLSearchParams übergebene Wert wird als %252B doppelt codiert. Eine einmalige Dekodierung ergibt %2B statt plus. Das Zeichen wird zu einer literalen Prozent-zwei-sechs-Zeichenfolge und nicht zu einem Pluszeichen. Überprüfen Sie Zwischenschritte in Ihrem Build-Prozess. Die Kodierung erfolgt nur genau einmal pro Wert. Dokumentieren Sie, welchen Codierungsstandard Ihre Pipeline verwendet. Testen Sie mit Sonderzeichen wie Pluszeichen, Leerzeichen und kaufmännischem Und.
Fazit: Zwei Standards, beide in ihrem Kontext korrekt – wie der URL-Encoder und -Decoder Ihnen das RFC-Formular 3986 mit %20 für Leerzeichen liefert, damit Sie wissen, welches Sie suchen
Die Plus-gegen-Zwanzig-Aufteilung ist kein zu behebender Fehler. Es handelt sich um ein historisches Artefakt von Standards, die unterschiedliche Probleme unterschiedlich lösen. Eine Lösung würde eine weltweite Koordination erfordern – nach dreißig Jahren unmöglich. Normungsgremien unterbrechen das Netz nicht rückwirkend. RFC 3986, Formularregeln und Browser-URL-Konstruktion haben jeweils Standards und Gründe. Die RFC-1866-Formularkodierung und die RFC-3986-URI-Kodierung bedienen unterschiedliche Ebenen. Codieren Sie bewusst, indem Sie Ihren Standard kennen. Testen Sie mit realistischen Nutzlasten.
Wählen Sie die Kodierung nach Kontext. Formulare verwenden Plus gemäß HTML-Standards. Manuelle URIs verwenden %20 gemäß RFC 3986. APIs geben an, was zu erwarten ist; Befolgen Sie die Dokumentation oder testen Sie beide. URL-Encoder und -Decoder zeigt RFC 3986. Benötigen Sie eine Formularkodierung? URLSearchParams macht das. Das Tool mischt keine Kodierungen; Das Verständnis von Standards verhindert Überraschungen. Inkonsistenzen bei der Codierung zwischen den Ebenen führen zu subtilem Parameterverlust, Kürzungen und Datenbeschädigungen. Beide Standards sind in ihrem Bereich korrekt. Bewerben Sie sich bewusst und dokumentieren Sie.