URL-Kodierung für Leerzeichen: %20 oder Plus?

Ein Leerzeichen in URL-Daten wird normalerweise zu %20, aber die Abfrageserialisierung im Formularstil stellt es als dar +. Beides kann richtig sein. Die richtige Ausgabe hängt vom Ziel ab: Verwenden Sie die prozentuale Codierung für eine einzelne URI-Komponente und verwenden Sie die Plus-Konvention nur, wenn der empfangende Workflow dies erwartet application/x-www-form-urlencoded Daten.

Der URL-Encoder von ClockTools verdeutlicht diesen Kontext mit den Profilen URI-Komponente, Vollständige URL und Formulardaten. Fügen Sie green tea ein, wechseln Sie die Profile und vergleichen Sie die Ausgabe, bevor Sie Anwendungscode ändern.

Beginnen Sie mit dem Ziel

Fragen Sie nicht: „Welches Zeichen steht immer für ein Leerzeichen?“ Entscheidend ist: Welcher Parser erhält den Wert?

Für ein Pfadsegment, einen Fragmentwert oder einen einzelnen Abfragewert ist die prozentuale Codierung die zuverlässige Darstellung. Das UTF-8-Byte des Leerzeichens ist hexadezimal 20, also ist sein prozentcodiertes Triplett %20.

Bei HTML-Formulardaten verwendet die Serialisierungskonvention + für Leerzeichen und kodiert ein tatsächliches Pluszeichen als %2B. Der WHATWG-URL-Standard definiert dieses form-urlencoded-Verhalten getrennt vom allgemeinen URL-Parsing.

Die URI-Syntax nach RFC 3986 definiert ein prozentkodiertes Oktett als % gefolgt von zwei Hexadezimalziffern. Sie unterscheidet außerdem reservierte Trennzeichen von nicht reservierten Datenzeichen. Deshalb ist die Kodierung eines Wertes etwas anderes als die Kodierung einer vollständigen Adresse.

Entscheidungstabelle: %20 oder Pluszeichen

Die letzte Zeile verhindert einen häufigen Fehler. Wenn der beabsichtigte Wert ist C++, senden C++ durch einen Form-Decoder erzeugen kann C . Codieren Sie jedes Literal plus als %2B vor dem Parsen des Formulars.

Vier reproduzierbare ClockTools-Tests

Wir haben vier kleine Eingaben durch die aktuelle Tool-Implementierung durchgeführt. Sein URI-Komponentenprofil verwendet JavaScript encodeURIComponent. Form Data wendet dieselbe Komponentenkodierung an und ersetzt sie dann %20 mit +. Vollständige URL verwendet encodeURI, wodurch die URL-Struktur erhalten bleibt.

Dies sind deterministische Umwandlungsergebnisse, keine Belege für Suchmaschinen-Rankings. Sie lassen sich lokal im Browser reproduzieren. Die Seite aktualisiert die Ausgabe sofort, zeigt Prozent-Escape-Sequenzen und Bytezahlen an und muss die Eingabe zur Umwandlung nicht an einen Server senden.

Nutzen Sie den URL-Decoder für die Gegenprobe. Dekodieren Sie green%20tea mit dem Komponentenprofil und green+tea mit Formulardaten. Der Decoder warnt bei einem Pluszeichen außerhalb des Formularprofils, weil die beabsichtigte Bedeutung unklar ist.

Was schützt die Komponentenkodierung?

Eine URL verwendet Satzzeichen als Grammatik. In einer Abfragezeichenfolge: & kann mit einem weiteren Parameter beginnen und = trennt einen Namen von einem Wert. # beginnt ein Fragment. ? beginnt eine Abfrage. Wenn eines dieser Zeichen zu den Benutzerdaten gehört, kann es zu einer Änderung der Struktur führen, wenn es roh bleibt.

Bedenken Sie den Wert timer & alarm. Komponentenkodierung erzeugt timer%20%26%20alarm. Das kaufmännische Und wird %26, sodass ein Parser einen Wert erhält, anstatt ihn zu interpretieren alarm als neuer Parameter.

Kodierung ist eine Darstellungsform, keine Validierung oder Verschlüsselung. Eine prozentkodierte Weiterleitung kann nach dem Dekodieren weiterhin auf einen nicht erlaubten Host zeigen. Ein kodiertes Skript bleibt eine nicht vertrauenswürdige Eingabe. Validieren Sie nach dem Parsing zulässige Schemata, Hosts, Parameternamen und Geschäftsregeln. Vermeiden Sie Passwörter, Tokens und andere Geheimnisse in URLs, da Adressen im Verlauf, in Protokollen, Analysedaten, Screenshots und Referrer-Daten erscheinen können.

Wenn Sie eine Abfragezeichenfolge vor und nach der Umwandlung vergleichen möchten, zeigt der Text-Diff-Checker jede geänderte Escape-Sequenz. Das ist zuverlässiger, als eine lange Callback-URL nach einem fehlenden %25 zu durchsuchen.

Warum erzeugt die Doppelkodierung %2520?

Eine doppelte Kodierung liegt vor, wenn bereits kodierter Text als Rohdaten behandelt und erneut kodiert wird.

Beginnen Sie mit einem Leerzeichen:

space -> %20

Kodieren %20 als neue Komponente. Das Prozentzeichen wird %25, während die Ziffern wörtlich bleiben:

%20 -> %2520

Eine Dekodierung ändert sich %2520 zurück zu %20. Eine zweite Dekodierung ändert sich %20 zu einem Raum. Wenn Ihre Anwendung einen Decodierungsdurchlauf erwartet, aber einen doppelt codierten Wert empfängt, wird dies dem Benutzer möglicherweise angezeigt %20 anstelle eines Leerzeichens.

Die Lösung besteht nicht darin, so oft zu dekodieren, bis der Text richtig aussieht. Wiederholtes Dekodieren kann bewusst kodierte Trennzeichen verändern und Sicherheitsprobleme verursachen. Klären Sie die Zuständigkeit: Genau eine Ebene sollte die Komponente kodieren und genau eine entsprechende Ebene sie dekodieren.

Fehlersuche bei unterschiedlich behandelten Leerzeichen

Verwenden Sie diesen Pfad, wenn ein System sendet %20 und ein weiteres Display +, %2520oder ein wörtliches Leerzeichen.

1. Erfassen Sie den Rohwert, bevor ihn ein Framework-Parser ändert.
2. Identifizieren Sie, ob es sich bei dem Feld um ein Pfadsegment, eine Abfragekomponente, eine vollständige URL oder einen Formulartext handelt.
3. Notieren Sie den erwarteten dekodierten Wert, einschließlich literaler Pluszeichen.
4. Reproduzieren Sie dieselbe Eingabe im passenden ClockTools-Profil.
5. Dekodieren Sie einmal mit dem Profil der empfangenden Seite.
6. Vergleichen Sie das Ergebnis mit dem erwarteten Wert.
7. Durchsuchen Sie den Anwendungsfluss nach einem zweiten Encoder oder Decoder, wenn %25 erscheint unerwartet.

Dieser Ablauf zur Fehlersuche ist bewusst eng gefasst. Er trennt den Datenkontext von Vermutungen; jeder Schritt hat eine sichtbare Eingabe und Ausgabe.

Wann sollten Sie eine vollständige URL kodieren?

Verwenden Sie das vollständige URL-Profil nur, wenn die Adresse eine Adresse bleiben soll. Strukturelle Interpunktion wie Doppelpunkt, Schrägstriche, Fragezeichen, Gleichheitszeichen, kaufmännisches Und und Fragmentmarkierung bleiben erhalten, während Zeichen wie Leerzeichen kodiert werden.

Verwenden Sie URI-Komponente, wenn eine vollständige URL selbst als Wert in einem anderen Parameter steckt. Eine Callback-Adresse in redirect= gilt aus Sicht der äußeren URL beispielsweise als Daten. Wird die verschachtelte Adresse als eine Komponente kodiert, können ihr ? und ihr & nicht Teil der äußeren Abfrage werden.

Führen Sie eine Adresse nicht wiederholt durch verschiedene Profile, in der Hoffnung auf eine allgemein sichere Zeichenfolge. Schreiben Sie die Grenze explizit:

outer URL structure + encodeURIComponent(inner callback URL)

Die empfangende Anwendung sollte die äußere URL parsen, die Callback-Komponente extrahieren, einmal dekodieren, die entstandene innere URL parsen und das Ziel validieren. Kodierung bewahrt die Syntax; Validierung entscheidet, ob das Ziel erlaubt ist.