Was ist Prozentkodierung? (RFC 3986 einfach erklärt)
Prozentkodierung ist ein in RFC 3986 definierter Mechanismus zur Kodierung von Sonderzeichen in URIs, bei dem diese durch ein Prozentzeichen (%) gefolgt von zwei Hexadezimalziffern ersetzt werden. So wird sichergestellt, dass URLs nur gültige ASCII-Zeichen enthalten, die sicher über das Internet übertragen werden können.
Was ist Prozentkodierung?
Prozentkodierung, auch URL-Kodierung genannt, ist die standardisierte Methode, um Zeichen in einem URI (Uniform Resource Identifier) darzustellen, die nicht zulässig sind oder eine besondere Bedeutung haben. Dabei wird jedes Zeichen, das kodiert werden muss, durch ein Prozentzeichen (%) gefolgt von zwei Hexadezimalziffern ersetzt, die den Byte-Wert des Zeichens repräsentieren.
Das Leerzeichen (Byte-Wert 0x20) wird beispielsweise als %20 kodiert. Das At-Zeichen @ (Byte-Wert 0x40) wird als %40 kodiert. Dieser Mechanismus stellt sicher, dass beliebige Daten sicher in einen URI eingebettet werden können, ohne mit der URI-Syntax in Konflikt zu geraten.
Der Begriff „Prozentkodierung" leitet sich von der Verwendung des Prozentzeichens als Escape-Präfix ab. Die formale Spezifikation ist in RFC 3986 definiert, das im Januar 2005 von der Internet Engineering Task Force (IETF) veröffentlicht und von Tim Berners-Lee, Roy Fielding und Larry Masinter verfasst wurde.
Wie funktioniert die Prozentkodierung?
Der Kodierungsvorgang läuft in folgenden Schritten ab: Zunächst wird das Zeichen mithilfe einer Zeichenkodierung (im modernen Web fast immer UTF-8) in seine Byte-Darstellung umgewandelt. Anschließend wird jedes Byte als Prozentzeichen gefolgt von zwei Hexadezimalziffern dargestellt (konventionell mit Großbuchstaben A-F, wobei Decoder jedoch auch Kleinbuchstaben akzeptieren sollten).
// Schrittweise Kodierung eines Leerzeichens
// Zeichen: ' ' (Leerzeichen)
// ASCII/UTF-8-Byte-Wert: 0x20 (dezimal 32)
// Prozentkodiert: %20
// Schrittweise Kodierung eines Mehrbyte-Zeichens: e mit Akut
// Zeichen: e mit Akut (U+00E9)
// UTF-8-Bytes: 0xC3 0xA9
// Prozentkodiert: %C3%A9
// Schrittweise Kodierung eines 3-Byte-Zeichens
// Zeichen: CJK-Ideogramm (U+4E2D)
// UTF-8-Bytes: 0xE4 0xB8 0xAD
// Prozentkodiert: %E4%B8%AD
Die Hexadezimalziffern müssen immer paarweise auftreten. Ein einzelnes Prozentzeichen oder ein Prozentzeichen gefolgt von Nicht-Hexadezimalzeichen ist ungültig und führt beim Dekodieren zu einem Fehler. Dies ist eine häufige Ursache für den Fehler „URI malformed" in JavaScript.
Die Prozentkodierung ist stets umkehrbar. Der Decoder liest das Prozentzeichen ein, interpretiert die beiden nachfolgenden Zeichen als hexadezimalen Byte-Wert und wandelt diesen wieder in das ursprüngliche Zeichen um. Bei Mehrbyte-UTF-8-Zeichen werden aufeinanderfolgende kodierte Bytes zusammengeführt und gemeinsam dekodiert.
Welche Zeichen müssen kodiert werden?
Nicht alle Zeichen benötigen eine Prozentkodierung. RFC 3986 definiert zwei Kategorien: nicht reservierte Zeichen, die niemals kodiert werden müssen, und reservierte Zeichen, die kodiert werden müssen, wenn sie nicht für ihren reservierten Zweck verwendet werden. Alle übrigen Zeichen (einschließlich Leerzeichen, Nicht-ASCII-Zeichen und Steuerzeichen) müssen immer kodiert werden.
Zeichen, die NICHT kodiert werden müssen (nicht reserviert): Großbuchstaben (A-Z), Kleinbuchstaben (a-z), Ziffern (0-9), Bindestrich (-), Punkt (.), Unterstrich (_) und Tilde (~). Diese 66 Zeichen dürfen an beliebiger Stelle in einem URI ohne Kodierung stehen.
Zeichen, die manchmal kodiert werden müssen (reserviert): : / ? # [ ] @ ! $ & ' ( ) * + , ; =. Diese Zeichen haben in URIs eine besondere syntaktische Bedeutung. Sie müssen nur dann kodiert werden, wenn sie als Daten statt als Trennzeichen verwendet werden.
Zeichen, die immer kodiert werden müssen: Leerzeichen, Nicht-ASCII-Zeichen (jedes Zeichen über 127), Steuerzeichen (0-31 und 127) sowie unsichere Zeichen wie < > { } | \ ^ ` ".
Reservierte vs. nicht reservierte Zeichen in RFC 3986
Die Unterscheidung zwischen reservierten und nicht reservierten Zeichen ist grundlegend für die Funktionsweise von URIs. Reservierte Zeichen dienen als Trennzeichen, die die Struktur eines URI festlegen. So trennt beispielsweise :// das Schema von der Authority, / trennt Pfadsegmente, ? leitet die Query-Zeichenkette ein und # leitet das Fragment ein.
| Kategorie | Zeichen | Wann kodieren |
|---|---|---|
| Nicht reserviert | A-Z a-z 0-9 - . _ ~ |
Niemals |
| Allgemeine Trennzeichen | : / ? # [ ] @ |
Wenn sie als Daten und nicht als Trennzeichen verwendet werden |
| Untertrennzeichen | ! $ & ' ( ) * + , ; = |
Wenn sie als Daten in Komponenten verwendet werden, die ihnen eine Bedeutung zuweisen |
| Alle übrigen Zeichen | Leerzeichen, Nicht-ASCII, Steuerzeichen usw. | Immer |
Ein zentraler Grundsatz aus RFC 3986 lautet, dass URIs, die sich nur darin unterscheiden, ob ein reserviertes Zeichen prozentkodiert ist oder wörtlich erscheint, nicht gleichwertig sind. So sind etwa /path/to und /path%2Fto unterschiedliche URIs, obwohl %2F zu / dekodiert wird. Der erste enthält zwei Pfadsegmente; der zweite enthält ein einziges Pfadsegment mit einem wörtlichen Schrägstrich.
Prozentkodierung vs. URL-Kodierung: Ist das dasselbe?
„Prozentkodierung" und „URL-Kodierung" werden häufig synonym verwendet und meinen in den meisten Kontexten dasselbe. Es gibt jedoch einen feinen historischen Unterschied. „URL-Kodierung" kann sich mitunter auf das ältere Format application/x-www-form-urlencoded beziehen, das von HTML-Formularen verwendet wird und Leerzeichen als + statt als %20 kodiert.
Das Format application/x-www-form-urlencoded wurde in der HTML-Spezifikation definiert und ist älter als RFC 3986. Es gelten leicht abweichende Regeln: Leerzeichen werden zu +, und die Menge der Zeichen, die nicht kodiert werden, unterscheidet sich geringfügig. Die moderne Verwendung des Begriffs „URL-Kodierung" bezieht sich fast immer auf die Prozentkodierung nach RFC 3986, bei der Leerzeichen zu %20 werden.
In der Praxis sollten Sie für alle URI-Kontexte (Pfadsegmente, Query-Parameter in REST-APIs, Fragmentbezeichner) die Prozentkodierung nach RFC 3986 verwenden. Das Format application/x-www-form-urlencoded sollten Sie nur bei der Übermittlung von HTML-Formularen einsetzen oder wenn eine bestimmte API es erfordert.
// Prozentkodierung nach RFC 3986 (empfohlen für URIs)
encodeURIComponent('hello world') // "hello%20world"
// application/x-www-form-urlencoded (HTML-Formulare)
new URLSearchParams({q: 'hello world'}).toString() // "q=hello+world"
// Python-Entsprechung
from urllib.parse import quote, quote_plus
quote('hello world', safe='') # "hello%20world"
quote_plus('hello world') # "hello+world"