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.

Die ClockTools URL-Encoder Macht diesen Kontext mit URI-Komponenten-, Voll-URL- und Formulardatenprofilen explizit. Einfügen grüner Tee, wechseln Sie Profile und vergleichen Sie die Ausgabe, bevor Sie den Anwendungscode ändern.

Beginnen Sie mit dem Ziel

Fragen Sie nicht: „Welches Symbol bedeutet immer Leerzeichen?“ Fragen Sie, welcher Parser den Wert erhält.

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.

Für HTML-Formulardaten gilt die Serialisierungskonvention + für Leerzeichen und Prozentcodierungen ein wörtliches Plus as %2B. Die WHATWG-URL-Standard definiert dieses formular-urlencodierte Verhalten getrennt von der allgemeinen URL-Analyse.

Die RFC 3986 URI-Syntax definiert ein prozentcodiertes Oktett als % gefolgt von zwei hexadezimalen Ziffern. Es unterscheidet außerdem reservierte Trennzeichen von nicht reservierten Datenzeichen. Dieser Unterschied ist der Grund dafür, dass sich die Kodierung eines Werts von der Kodierung einer gesamten Adresse unterscheidet.

Die %20 versus Plus-Entscheidungstabelle

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.

Dabei handelt es sich um deterministische Transformationsergebnisse, nicht um Suchranking-Beweise. Sie können sie lokal im Browser reproduzieren. Die Seite aktualisiert die Ausgabe sofort, meldet prozentuale Escapezeichen und Bytezahlen und muss die Eingabe nicht zur Konvertierung an einen Server senden.

Benutzen Sie die URL-Decoder um die inverse Prüfung durchzuführen. Dekodieren Grüner Tee unter dem Komponentenprofil und grüner+Tee unter Formulardaten. Der Decoder warnt, wenn ein Pluszeichen unter einem Nicht-Formularprofil erscheint, weil die beabsichtigte Bedeutung nicht eindeutig 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 und 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.

Bei der Kodierung handelt es sich um eine Darstellung, nicht um eine Validierung oder Verschlüsselung. Eine prozentkodierte Weiterleitung kann nach der Dekodierung immer noch auf einen nicht genehmigten Host verweisen. Ein codiertes Skript ist immer noch eine nicht vertrauenswürdige Eingabe. Validieren Sie zulässige Schemata, Hosts, Parameternamen und Geschäftsregeln nach dem Parsen. Vermeiden Sie es, Passwörter, Token oder andere Geheimnisse in URLs einzufügen, da Adressen im Verlauf, in Protokollen, Analysen, Screenshots und Referrer-Daten erscheinen können.

Wenn Sie eine Vorher-Nachher-Abfragezeichenfolge vergleichen müssen, wird die Text-Diff-Checker macht jede veränderte Flucht sichtbar. Das ist zuverlässiger, als eine lange Rückruf-URL nach einer fehlenden zu durchsuchen %25.

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:

„Text

Leerzeichen -> %20

```

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

„Text

%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 darin, nicht wiederholt zu dekodieren, bis der Text richtig aussieht. Wiederholtes Dekodieren kann bewusst kodierte Trennzeichen verändern und zu Sicherheitsproblemen führen. Identifizieren Sie die Eigentumsgrenze: Genau eine Ebene sollte die Komponente kodieren und genau eine entsprechende Ebene sollte sie dekodieren.

Ein Debugpfad für Speicherplatzkonflikte

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. Einmal mit dem Empfangsprofil dekodieren.

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 Debugging-Pfad ist absichtlich schmal gehalten. Es trennt Datenkontext von Vermutungen und 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 die URI-Komponente, wenn eine vollständige URL selbst in einem anderen Parameter verschachtelt ist. Zum Beispiel eine Rückrufadresse, die in platziert wird weiterleiten= sind Daten aus der Perspektive der äußeren URL. Das Kodieren der verschachtelten Adresse als eine Komponente verhindert dies ? und & vom Beitritt zur äußeren Abfrage.

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

„Text

äußere URL-Struktur + encodeURIComponent (innere Rückruf-URL)

```

Die empfangende Anwendung sollte die äußere URL analysieren, die Rückrufkomponente extrahieren, sie einmal dekodieren, die resultierende innere URL analysieren und das Ziel validieren. Durch die Kodierung bleibt die Syntax intakt; Die Validierung entscheidet, ob das Ziel zulässig ist.