Basierend auf den Sonderzeichen in der URL-Escape-Kodierung

Sonderzeichen in URLs

Zeichen - URL-codierter Wert

Platz - %20
" - %zweiundzwanzig
# - %dreiundzwanzig
% - %25
& - %26
(-%28
) - %29
+ - %2B
, - %2C
/ - %2F
: - %3A
; - %3B
<-%3C
= - %3D
> - %3E
? - %3F
@ - %40
\ - %5C
|-%7C

Escapezeichen für URL-Sonderzeichen. Einige Zeichen in der URL haben eine besondere Bedeutung. Die grundlegenden Kodierungsregeln lauten wie folgt:

1. Ersetzen Sie Leerzeichen durch Pluszeichen (+)

2. Schrägstrich (/) trennt Verzeichnisse und Unterverzeichnisse

3. Fragezeichen (?) trennt URL und Abfrage

4. Das Prozentzeichen (%) gibt ein Sonderzeichen an

5. # gibt ein Lesezeichen an

6. & trennt Parameter

Wenn Sie es in einer URL verwenden müssen, müssen Sie diese Sonderzeichen durch die entsprechenden Hexadezimalwerte ersetzen.

+ %2 Mrd.
/ %2F
? %3F
% %25
# %dreiundzwanzig
& %26

Dieser Artikel stellt hauptsächlich die damit verbundenen Probleme der URI-Kodierung und -Dekodierung vor und gibt eine detaillierte Erklärung, welche Zeichen bei der URL-Kodierung kodiert werden müssen und warum sie kodiert werden müssen. Außerdem werden mehrere Funktionspaare verglichen und analysiert, die mit der Kodierung und Dekodierung in Javascript zusammenhängen: escape/unescape, encodeURI/decodeURI und encodeURIComponent/decodeURIComponent.

Voraussetzungen

foo://example.com:8042/drüben/da?name=ferret#nose
\_/ \______________/ \________/\_________/ \__/
| | | | |
Schema Autorität Pfad Abfrage Fragment

URI steht für Uniform Resource Identifier. Normalerweise ist das, was wir URL nennen, nur eine Art URI. Das Format einer typischen URL ist oben dargestellt. Die unten erwähnte URL-Kodierung sollte sich eigentlich auf die URI-Kodierung beziehen.

Warum brauchen wir eine URL-Kodierung?

Wenn etwas verschlüsselt werden muss, ist es normalerweise nicht zur Übertragung geeignet. Dafür gibt es viele Gründe, z. B. ist die Größe zu groß, es sind private Daten enthalten oder für die URL ist eine Kodierung erforderlich, weil einige Zeichen in der URL zu Mehrdeutigkeiten führen können.

Beispielsweise verwendet die URL-Parameterzeichenfolge das Schlüssel=Wert-Paarformat zum Übergeben von Parametern, und die Schlüssel-Wert-Paare werden durch das Symbol „&“ getrennt, z. B. /s?q=abc& ie=utf-8. Wenn Ihre Wertzeichenfolge = oder & enthält, führt dies zwangsläufig zu einem Analysefehler auf dem Server, der die URL empfängt. Daher müssen die mehrdeutigen Symbole & und = maskiert, d. h. codiert werden.

Beispielsweise verwendet das Kodierungsformat der URL ASCII-Code, nicht Unicode. Dies bedeutet, dass Sie keine Nicht-ASCII-Zeichen, wie etwa chinesische, in die URL aufnehmen können. Andernfalls kann es zu Problemen mit Chinesisch kommen, wenn der Client-Browser und der Server-Browser unterschiedliche Zeichensätze unterstützen.

Das Prinzip der URL-Kodierung besteht darin, sichere Zeichen (druckbare Zeichen ohne besonderen Zweck oder besondere Bedeutung) zur Darstellung unsicherer Zeichen zu verwenden.

Welche Zeichen müssen kodiert werden?

Das Dokument RFC3986 legt fest, dass eine URL nur englische Buchstaben (a-zA-Z), Zahlen (0-9), -_.~4 Sonderzeichen und alle reservierten Zeichen enthalten darf.

Das Dokument RFC3986 gibt ausführliche Empfehlungen zur URL-Kodierung und -Dekodierung und gibt an, welche Zeichen kodiert werden müssen, um keine Änderung der Semantik der URL zu verursachen, und liefert entsprechende Erklärungen, warum diese Zeichen kodiert werden müssen.

Es gibt kein entsprechendes druckbares Zeichen im US-ASCII-Zeichensatz

In URLs sind nur druckbare Zeichen zulässig. Die Bytes 10-7F im US-ASCII-Code stellen alle Steuerzeichen dar und diese Zeichen können nicht direkt in einer URL erscheinen. Gleichzeitig können 80-FF-Bytes (ISO-8859-1) nicht in eine URL eingefügt werden, da sie außerhalb des durch US-ACII definierten Bytebereichs liegen.

Reservierte Zeichen

Eine URL kann in mehrere Komponenten unterteilt werden, wie etwa Protokoll, Host, Pfad usw. Einige Zeichen (:/?#[]@) werden verwendet, um verschiedene Komponenten zu trennen. Beispiel: Ein Doppelpunkt wird verwendet, um das Protokoll vom Host zu trennen, / wird verwendet, um den Host vom Pfad zu trennen, ? wird verwendet, um den Pfad von den Abfrageparametern zu trennen usw. Es gibt auch einige Zeichen (!$&'()*+,;=), die zum Trennen der einzelnen Komponenten verwendet werden. Beispielsweise wird = zum Darstellen der Schlüssel-Wert-Paare in den Abfrageparametern verwendet und das Symbol & wird zum Trennen mehrerer Schlüssel-Wert-Paare in der Abfrage verwendet. Wenn normale Daten in einer Komponente diese Sonderzeichen enthalten, müssen sie codiert werden.

RFC3986 spezifiziert die folgenden Zeichen als reservierte Zeichen:

Unsichere Zeichen

Es gibt auch einige Zeichen, die, wenn sie direkt in eine URL eingefügt werden, zu Mehrdeutigkeiten im Parser führen können. Diese Zeichen gelten aus mehreren Gründen als unsicher.

Es ist zu beachten, dass bei zulässigen Zeichen in einer URL die Kodierung und Nichtkodierung gleichwertig sind. Bei den oben genannten Zeichen kann es jedoch zu Unterschieden in der Semantik der URL kommen, wenn sie nicht kodiert sind. Daher dürfen in nicht codierten URLs nur allgemeine englische Zeichen und Zahlen, Sonderzeichen $-_.+!*'() und reservierte Zeichen vorkommen. Andere Zeichen müssen codiert werden, bevor sie in der URL erscheinen können.

Aus historischen Gründen gibt es jedoch immer noch einige nicht standardmäßige Kodierungsimplementierungen. Obwohl das Dokument RFC3986 beispielsweise für das Symbol ~ vorschreibt, dass das Tilde-Symbol ~ nicht URL-kodiert werden muss, gibt es immer noch viele alte Gateways oder Übertragungsagenten, die

So kodieren Sie ungültige Zeichen in einer URL

Die URL-Kodierung wird häufig auch als Prozentkodierung bezeichnet (URL-Kodierung, auch als Prozentkodierung bekannt), da ihre Kodierungsmethode sehr einfach ist und das Prozentzeichen plus zwei Zeichen – 0123456789ABCDEF – verwendet, um ein Byte in hexadezimaler Form darzustellen. Der für die URL-Kodierung verwendete Standardzeichensatz ist US-ASCII. Beispielsweise ist das Byte, das einem im US-ASCII-Code entspricht, 0x61, sodass das Ergebnis nach der URL-Kodierung %61 ist. Wenn wir http://g.cn/search?q=%61%62%63 in die Adressleiste eingeben, entspricht dies tatsächlich der Suche nach abc bei Google. Beispielsweise ist das Byte, das dem @-Symbol im ASCII-Zeichensatz entspricht, 0x40 und wird nach der URL-Kodierung zu %40.

Liste der gängigen Zeichen in der URL-Kodierung:

Für Nicht-ASCII-Zeichen müssen Sie eine Obermenge des ASCII-Zeichensatzes verwenden, um die entsprechenden Bytes zu kodieren, und dann für jedes Byte eine Prozentkodierung durchführen. Für Unicode-Zeichen empfiehlt das RFC-Dokument die Verwendung von UTF-8 zum Kodieren, um die entsprechenden Bytes zu erhalten, und anschließend für jedes Byte eine Prozentkodierung durchzuführen. Beispielsweise lauten die Bytes von „Chinesisch“ im UTF-8-Zeichensatz 0xE4 0xB8 0xAD 0xE6 0x96 0x87, und nach der URL-Kodierung erhalten wir „%E4%B8%AD%E6%96%87“.

Wenn ein Byte einem nicht reservierten Zeichen im ASCII-Zeichensatz entspricht, muss das Byte nicht durch ein Prozentzeichen dargestellt werden. Beispielsweise wird „Url-Kodierung“ mit UTF-8 kodiert und die Bytes sind 0x55 0x72 0x6C 0xE7 0xBC 0x96 0xE7 0xA0 0x81. Da die ersten drei Bytes dem nicht reservierten Zeichen „Url“ in ASCII entsprechen, können diese drei Bytes durch das nicht reservierte Zeichen „Url“ dargestellt werden. Die endgültige URL-Kodierung kann auf „Url%E7%BC%96%E7%A0%81“ vereinfacht werden. Wenn Sie „%55%72%6C%E7%BC%96%E7%A0%81“ verwenden, ist dies natürlich auch akzeptabel.

Aus historischen Gründen folgen einige Implementierungen der URL-Kodierung diesem Prinzip nicht vollständig. Dies wird weiter unten erläutert.

Unterschiede zwischen Escape, EncodeURI und EncodeURIComponent in Javascript

Javascript bietet drei Funktionspaare zum Kodieren der URL, um eine gültige URL zu erhalten, nämlich escape/unescape, encodeURI/decodeURI und encodeURIComponent/decodeURIComponent. Da die Dekodierungs- und Kodierungsvorgänge umkehrbar sind, wird hier nur der Kodierungsvorgang erläutert.

Diese drei Kodierungsfunktionen – escape, encodeURI, encodeURIComponent – ​​werden alle verwendet, um unsichere und ungültige URL-Zeichen in zulässige URL-Zeichendarstellungen umzuwandeln. Sie weisen die folgenden Unterschiede auf.

Sicherheitszeichen sind unterschiedlich

In der folgenden Tabelle sind die sicheren Zeichen für diese drei Funktionen aufgeführt (d. h. die Funktionen kodieren diese Zeichen nicht).

Unterschiedliche Kompatibilität

Die Escape-Funktion existiert seit Javascript 1.0, während die anderen beiden Funktionen in Javascript 1.5 eingeführt wurden. Da Javascript 1.5 jedoch bereits sehr beliebt ist, gibt es bei der Verwendung von encodeURI und encodeURIComponent eigentlich kein Kompatibilitätsproblem.

Verschiedene Kodierungsmethoden für Unicode-Zeichen

Diese drei Funktionen verwenden dieselbe Kodierungsmethode für ASCII-Zeichen, die durch ein Prozentzeichen + zwei Hexadezimalzeichen dargestellt wird. Für Unicode-Zeichen lautet die Escape-Kodierung jedoch %uxxxx, wobei xxxx ein vierstelliges Hexadezimalzeichen ist, das zur Darstellung des Unicode-Zeichens verwendet wird. Diese Methode wird vom W3C nicht mehr unterstützt. Die Escape-Kodierungssyntax bleibt jedoch im ECMA-262-Standard erhalten. encodeURI und encodeURIComponent verwenden UTF-8, um Nicht-ASCII-Zeichen zu kodieren und sie dann prozentual zu kodieren. Dies wird vom RFC empfohlen. Daher wird empfohlen, diese beiden Funktionen nach Möglichkeit anstelle von Escape zur Kodierung zu verwenden.

Für verschiedene Anlässe geeignet

encodeURI wird zum Kodieren einer vollständigen URI verwendet, während encodeURIComponent zum Kodieren einer Komponente einer URI verwendet wird.

Aus der oben erwähnten Tabelle mit sicheren Zeichenbereichen können wir erkennen, dass der von encodeURIComponent codierte Zeichenbereich größer ist als der von encodeURI. Wie oben erwähnt, werden reservierte Zeichen im Allgemeinen verwendet, um URI-Komponenten (eine URI kann in mehrere Komponenten aufgeteilt werden, siehe Abschnitt mit den erforderlichen Kenntnissen) oder Unterkomponenten (wie das Trennzeichen von Abfrageparametern in der URI) zu trennen. Beispielsweise wird das Zeichen : verwendet, um das Schema und den Host zu trennen, und das Zeichen ? wird verwendet, um den Host und den Pfad zu trennen. Da das von encodeURI bearbeitete Objekt eine vollständige URI ist, haben diese Zeichen in URI eine spezielle Verwendung. Daher werden diese reservierten Zeichen nicht von encodeURI codiert, da sich sonst die Bedeutung ändern würde.

Die Komponenten haben ihr eigenes Datendarstellungsformat, diese Daten dürfen jedoch keine reservierten Zeichen enthalten, die Komponenten trennen, da sonst die Trennung der Komponenten in der gesamten URI durcheinander gerät. Daher müssen bei Verwendung von encodeURIComponent für eine einzelne Komponente mehr Zeichen codiert werden.

Formularübermittlung

Wenn ein HTML-Formular übermittelt wird, wird jedes Formularfeld vor dem Senden URL-codiert. Aus historischen Gründen entspricht die vom Formular verwendete URL-Kodierungsimplementierung nicht den neuesten Standards. Beispielsweise ist die für Leerzeichen verwendete Kodierung nicht %20, sondern ein +-Zeichen. Wenn das Formular mit der Post-Methode übermittelt wird, können wir im HTTP-Header einen Content-Type-Header mit dem Wert application/x-www-form-urlencoded sehen. Die meisten Anwendungen können mit dieser nicht standardmäßigen Implementierung der URL-Kodierung umgehen, im clientseitigen Javascript gibt es jedoch keine Funktion, die das +-Zeichen in ein Leerzeichen dekodieren kann. Sie können daher nur Ihre eigene Konvertierungsfunktion schreiben. Außerdem hängt der verwendete codierte Zeichensatz bei Nicht-ASCII-Zeichen vom Zeichensatz ab, der im aktuellen Dokument verwendet wird. Zum Beispiel fügen wir im Html-Header hinzu

<meta http-equiv="Inhaltstyp" content="text/html; charset=gb2312" />

Auf diese Weise verwendet der Browser gb2312 zum Rendern des Dokuments (beachten Sie, dass der Browser den Zeichensatz automatisch basierend auf den Einstellungen des aktuellen Benutzers auswählt, wenn dieses Meta-Tag im HTML-Dokument nicht festgelegt ist. Der Benutzer kann die aktuelle Website auch zwingen, einen angegebenen Zeichensatz zu verwenden). Beim Absenden des Formulars wird für die URL-Kodierung der Zeichensatz gb2312 verwendet.

Hat der Dokumentzeichensatz Auswirkungen auf encodeURI?

Bei der Verwendung von Aptana bin ich zuvor auf ein sehr verwirrendes Problem gestoßen (der Grund, warum ich Aptana ausdrücklich erwähnt habe, wird weiter unten erläutert). Als ich encodeURI verwendete, stellte ich fest, dass das codierte Ergebnis ganz anders war als erwartet. Hier ist mein Beispielcode:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml">     
<Kopf>         
<meta http-equiv="Inhaltstyp" content="text/html; charset=gb2312" />     
</Kopf>     
<Text>         
<Skripttyp="text/javascript">             
document.write(encodeURI("URI-Code"));         
</Skript>     
</body> 
</html> 

Die Ausgabe des laufenden Ergebnisses lautet %E6%B6%93%EE%85%9F%E6%9E%83. Dies ist offensichtlich nicht das Ergebnis der Verwendung des UTF-8-Zeichensatzes für die URL-Kodierung (suchen Sie bei Google nach „Chinesisch“, und die URL zeigt %E4%B8%AD%E6%96%87).

Daher war ich damals sehr skeptisch, ob encodeURI auch mit der Seitenkodierung zusammenhängt, habe jedoch festgestellt, dass dieses Ergebnis unter normalen Umständen nicht auftritt, wenn Sie gb2312 zur URL-Kodierung verwenden. Später fand ich schließlich heraus, dass das Problem durch die Inkonsistenz zwischen dem für die Auslagerungsdateispeicherung verwendeten Zeichensatz und dem im Meta-Tag angegebenen Zeichensatz verursacht wurde. Der Editor von Aptana verwendet standardmäßig den UTF-8-Zeichensatz. Das heißt, beim tatsächlichen Speichern dieser Datei wird der Zeichensatz UTF-8 verwendet. Da jedoch gb2312 im Meta-Tag angegeben ist, analysiert der Browser das Dokument gemäß gb2312. Natürlich tritt in der Zeichenfolge „中文“ ein Fehler auf, da die nach der Codierung der Zeichenfolge „中文“ mit UTF-8 erhaltenen Bytes 0xE4 0xB8 0xAD 0xE6 0x96 0x87 sind und diese 6 Bytes vom Browser mit gb2312 decodiert werden. Anschließend werden weitere drei chinesische Zeichen „涓枃“ erhalten (ein chinesisches Zeichen belegt zwei Bytes in GBK). Das Ergebnis dieser drei chinesischen Zeichen ist nach der Übergabe an die Funktion encodeURI %E6%B6%93%EE%85%9F%E6%9E%83. Daher verwendet encodeURI weiterhin UTF-8 und wird vom Seitenzeichensatz nicht beeinflusst.

Andere Probleme im Zusammenhang mit der URL-Kodierung

Verschiedene Browser reagieren unterschiedlich auf die Verarbeitung von URLs mit chinesischen Schriftzeichen. Wenn Sie beispielsweise im Internet Explorer die erweiterte Einstellung „URL immer in UTF-8 senden“ aktivieren, werden die chinesischen Zeichen im Pfadteil der URL in UTF-8 codiert und an den Server gesendet, während die chinesischen Teile in den Abfrageparametern im Standardzeichensatz des Systems codiert werden. Um maximale Interoperabilität zu gewährleisten, wird empfohlen, dass alle in der URL platzierten Komponenten explizit einen Zeichensatz für die URL-Kodierung angeben, anstatt sich auf die Standardimplementierung des Browsers zu verlassen.

Darüber hinaus dekodieren viele HTTP-Überwachungstools oder Browseradressleisten die URL automatisch (mit dem UTF-8-Zeichensatz), wenn sie angezeigt wird. Wenn Sie Google in Firefox aufrufen, um nach Chinesisch zu suchen, enthält die in der Adressleiste angezeigte URL daher Chinesisch. Tatsächlich ist die ursprüngliche, an den Server gesendete URL jedoch immer noch verschlüsselt. Sie können dies sehen, indem Sie location.href in der Adressleiste mithilfe von Javascript aufrufen. Lassen Sie sich beim Studium der URL-Kodierung und -Dekodierung nicht von diesen Illusionen täuschen.

Das Obige ist meine persönliche Erfahrung. Ich hoffe, es kann Ihnen als Referenz dienen. Ich hoffe auch, dass Sie 123WORDPRESS.COM unterstützen werden.