URL-Encoding
URL-Encoding (URL-Kodierung, auch Prozentkodierung genannt) ist ein Mechanismus, der dazu dient, Informationen in einer URL unter bestimmten Gegebenheiten zu kodieren. Zur Kodierung werden nur bestimmte Zeichen des ASCII-Zeichensatzes verwendet. ⓘ
Ohne diese Kodierung wären einige Informationen nicht in einer URL darstellbar. Beispielsweise wird ein Leerzeichen in aller Regel vom Browser als Ende der URL interpretiert, nachfolgende Zeichen würden ignoriert oder führten zu einem Fehler. Mit der URL-Kodierung kann ein Leerzeichen durch die Zeichenfolge %20 übergeben werden. RFC 3986 definiert einen Standard, wie eine URI (und damit auch eine URL) syntaktisch aufgebaut sein sollte und unter welchen Bedingungen die URL-Kodierung Anwendung findet. ⓘ
Auch für nicht im ASCII-Zeichensatz enthaltene Zeichen wird die URL-Kodierung mit dem Prozentzeichen eingesetzt. Hier gibt es jedoch bisher nur eine Empfehlung im RFC 3986, ein verbindlicher Standard fehlt noch. ⓘ
Prozent-Kodierung in einem URI
Arten von URI-Zeichen
Die in einer URI zulässigen Zeichen sind entweder reserviert oder nicht reserviert (oder ein Prozentzeichen als Teil einer Prozentkodierung). Reservierte Zeichen sind die Zeichen, die manchmal eine besondere Bedeutung haben. So werden beispielsweise Schrägstriche verwendet, um verschiedene Teile einer URL (oder allgemeiner eines URI) zu trennen. Nicht reservierte Zeichen haben keine solche Bedeutung. Bei der Prozentkodierung werden die reservierten Zeichen durch spezielle Zeichenfolgen dargestellt. Die Menge der reservierten und nicht reservierten Zeichen und die Umstände, unter denen bestimmte reservierte Zeichen eine besondere Bedeutung haben, haben sich mit jeder Revision der Spezifikationen, die URIs und URI-Schemata regeln, leicht geändert. ⓘ
! |
# |
$ |
& |
' |
( |
) |
* |
+ |
, |
/ |
: |
; |
= |
? |
@ |
[ |
]
|
A |
B |
C |
D |
E |
F |
G |
H |
I |
J |
K |
L |
M |
N |
O |
P |
Q |
R |
S |
T |
U |
V |
W |
X |
Y |
Z
| |
a |
b |
c |
d |
e |
f |
g |
h |
i |
j |
k |
l |
m |
n |
o |
p |
q |
r |
s |
t |
u |
v |
w |
x |
y |
z
| |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9
|
- |
_ |
. |
~ |
|||||||||||||
Andere Zeichen in einem URI müssen in Prozent kodiert sein. ⓘ
Reservierte Zeichen
Wenn ein Zeichen aus dem reservierten Satz (ein "reserviertes Zeichen") eine besondere Bedeutung (einen "reservierten Zweck") in einem bestimmten Kontext hat und ein URI-Schema besagt, dass es notwendig ist, dieses Zeichen für einen anderen Zweck zu verwenden, dann muss das Zeichen prozentual kodiert werden. Die Prozentkodierung eines reservierten Zeichens beinhaltet die Umwandlung des Zeichens in den entsprechenden Byte-Wert in ASCII und die anschließende Darstellung dieses Wertes als Paar von Hexadezimalziffern (bei einer einzelnen Hexadezimalziffer wird eine führende Null hinzugefügt). Die Ziffern, denen ein Prozentzeichen (%) vorangestellt ist, das als Escape-Zeichen verwendet wird, werden dann im URI anstelle des reservierten Zeichens verwendet.
(Ein Nicht-ASCII-Zeichen wird in der Regel in seine Bytefolge in UTF-8 umgewandelt, und dann wird jeder Byte-Wert wie oben dargestellt). ⓘ
Das reservierte Zeichen / hat zum Beispiel, wenn es in der "Pfad"-Komponente eines URI verwendet wird, die besondere Bedeutung eines Trennzeichens zwischen Pfadsegmenten. Wenn nach einem bestimmten URI-Schema / in einem Pfadsegment enthalten sein muss, dann müssen die drei Zeichen %2F oder %2f in dem Segment anstelle eines rohen / verwendet werden. ⓘ
␣ |
! |
# |
$ |
% |
& |
' |
( |
) |
* |
+ |
, |
/ |
: |
; |
= |
? |
@ |
[ |
]
|
%20 |
%21 |
%23 |
%24 |
%25 |
%26 |
%27 |
%28 |
%29 |
%2A |
%2B |
%2C |
%2F |
%3A |
%3B |
%3D |
%3F |
%40 |
%5B |
%5D
|
Reservierte Zeichen, die in einem bestimmten Kontext keinen reservierten Zweck haben, können ebenfalls prozentual kodiert werden, unterscheiden sich aber semantisch nicht von den Zeichen, die nicht reserviert sind. ⓘ
In der "Abfrage"-Komponente eines URI (der Teil nach einem ? Zeichen) wird beispielsweise / immer noch als reserviertes Zeichen betrachtet, hat aber normalerweise keinen reservierten Zweck, es sei denn, ein bestimmtes URI-Schema sagt etwas anderes. Das Zeichen muss nicht prozentual kodiert werden, wenn es keinen reservierten Zweck hat. ⓘ
URIs, die sich nur darin unterscheiden, ob ein reserviertes Zeichen prozentual kodiert ist oder wörtlich erscheint, werden normalerweise als nicht äquivalent betrachtet (sie bezeichnen dieselbe Ressource), es sei denn, es kann festgestellt werden, dass die betreffenden reservierten Zeichen keinen reservierten Zweck haben. Diese Feststellung hängt von den Regeln ab, die von den einzelnen URI-Schemata für reservierte Zeichen festgelegt wurden. ⓘ
Nicht reservierte Zeichen
Zeichen aus dem nicht reservierten Satz müssen nie prozentual kodiert werden. ⓘ
URIs, die sich nur darin unterscheiden, ob ein nicht reserviertes Zeichen prozentual kodiert ist oder wörtlich erscheint, sind per Definition äquivalent, aber URI-Verarbeiter erkennen diese Äquivalenz in der Praxis möglicherweise nicht immer. Beispielsweise sollten URI-Konsumenten %41 nicht anders als A oder %7E nicht anders als ~ behandeln, doch einige tun dies. Um ein Höchstmaß an Interoperabilität zu erreichen, wird URI-Herstellern davon abgeraten, nicht reservierte Zeichen prozentual zu kodieren. ⓘ
Prozentzeichen
Da das Prozentzeichen ( % ) als Indikator für prozentual kodierte Oktette dient, muss es als %25 kodiert werden, damit dieses Oktett als Daten in einem URI verwendet werden kann. ⓘ
Beliebige Daten
Die meisten URI-Schemata beinhalten die Darstellung beliebiger Daten, wie z. B. eine IP-Adresse oder einen Dateisystempfad, als Komponenten eines URI. URI-Schema-Spezifikationen sollten eine explizite Zuordnung zwischen URI-Zeichen und allen möglichen Datenwerten, die durch diese Zeichen dargestellt werden, vorsehen, tun dies aber häufig nicht. ⓘ
Binäre Daten
Seit der Veröffentlichung von RFC 1738 im Jahr 1994 ist festgelegt, dass Schemata, die die Darstellung von Binärdaten in einem URI vorsehen, die Daten in 8-Bit-Bytes unterteilen und jedes Byte auf dieselbe Weise wie oben beschrieben prozentual codieren müssen. Der Byte-Wert 0x0F sollte zum Beispiel durch %0F dargestellt werden, aber der Byte-Wert 0x41 kann durch A oder %41 dargestellt werden. Die Verwendung von nicht kodierten Zeichen für alphanumerische und andere nicht reservierte Zeichen wird in der Regel bevorzugt, da dies zu kürzeren URLs führt. ⓘ
Zeichendaten
Das Verfahren für die prozentuale Kodierung von Binärdaten wurde oft - manchmal in unangemessener Weise oder ohne vollständige Spezifizierung - auf zeichenbasierte Daten extrapoliert. In den Anfangsjahren des World Wide Web, als man mit Datenzeichen aus dem ASCII-Repertoire arbeitete und die entsprechenden Bytes in ASCII als Grundlage für die Bestimmung prozentual kodierter Sequenzen verwendete, war diese Praxis relativ harmlos; man ging einfach davon aus, dass Zeichen und Bytes eins-zu-eins abgebildet werden und austauschbar sind. Die Notwendigkeit, Zeichen außerhalb des ASCII-Bereichs darzustellen, wuchs jedoch schnell, und URI-Schemata und -Protokolle boten oft keine Standardregeln für die Aufbereitung von Zeichendaten zur Aufnahme in einen URI. Webanwendungen begannen daher, verschiedene Multi-Byte-, zustandsbehaftete und andere nicht-ASCII-kompatible Kodierungen als Grundlage für die Prozentkodierung zu verwenden, was zu Mehrdeutigkeiten und Schwierigkeiten bei der zuverlässigen Interpretation von URIs führte. ⓘ
Viele URI-Schemata und Protokolle, die auf den RFCs 1738 und 2396 basieren, gehen beispielsweise davon aus, dass die Datenzeichen gemäß einer nicht spezifizierten Zeichenkodierung in Bytes umgewandelt werden, bevor sie in einem URI durch nicht reservierte Zeichen oder prozentual kodierte Bytes dargestellt werden. Wenn das Schema es nicht zulässt, dass der URI einen Hinweis auf die verwendete Kodierung gibt, oder wenn die Kodierung mit der Verwendung von ASCII zur prozentualen Kodierung von reservierten und nicht reservierten Zeichen in Konflikt steht, kann der URI nicht zuverlässig interpretiert werden. Einige Schemata berücksichtigen die Kodierung überhaupt nicht und schlagen stattdessen nur vor, dass Datenzeichen direkt auf URI-Zeichen abgebildet werden, was es den Implementierungen überlässt, zu entscheiden, ob und wie Datenzeichen, die weder in den reservierten noch in den nicht reservierten Mengen enthalten sind, prozentual kodiert werden sollen. ⓘ
Zeilenumbruch |
Leerzeichen |
" |
% |
- |
. |
< |
> |
\ |
^ |
_ |
` |
{ |
[[Senkrechter Strich|<nowiki>| |
} |
~ |
£ |
円
|
%0A oder %0D oder %0D%0A |
%20 |
%22 |
%25 |
%2D |
%2E |
%3C |
%3E |
%5C |
%5E |
%5F |
%60 |
%7B |
%7C |
%7D |
%7E |
%C2%A3 |
%E5%86%86
|
Beliebige Zeichendaten werden manchmal prozentual kodiert und in Nicht-URI-Situationen verwendet, z. B. für Programme zur Verschleierung von Passwörtern oder andere systemspezifische Übersetzungsprotokolle. ⓘ
Derzeitiger Standard
Die generische URI-Syntax empfiehlt, dass neue URI-Schemata, die die Darstellung von Zeichendaten in einem URI vorsehen, tatsächlich Zeichen aus dem nicht reservierten Satz ohne Übersetzung darstellen und alle anderen Zeichen gemäß UTF-8 in Bytes konvertieren und diese Werte dann perzentual kodieren sollten. Dieser Vorschlag wurde im Januar 2005 mit der Veröffentlichung von RFC 3986 eingeführt. URI-Schemata, die vor diesem Datum eingeführt wurden, sind davon nicht betroffen. ⓘ
Die aktuelle Spezifikation geht nicht auf die Frage ein, was mit kodierten Zeichendaten geschehen soll. In Computern beispielsweise liegen Zeichendaten auf einer bestimmten Ebene in kodierter Form vor, so dass sie bei der Zuordnung zu URI-Zeichen entweder als Binär- oder als Zeichendaten behandelt werden können. Vermutlich liegt es an den Spezifikationen des URI-Schemas, diese Möglichkeit zu berücksichtigen und das eine oder das andere zu verlangen, aber in der Praxis tun das nur wenige, wenn überhaupt. ⓘ
Nicht-Standard-Implementierungen
Es gibt eine Nicht-Standard-Kodierung für Unicode-Zeichen: %uxxxx, wobei xxxx eine UTF-16-Codeeinheit ist, die als vier hexadezimale Ziffern dargestellt wird. Dieses Verhalten ist in keinem RFC festgelegt und wurde vom W3C abgelehnt. Die achte Ausgabe von ECMA-262 enthält noch eine Escape-Funktion, die diese Syntax verwendet, zusammen mit den Funktionen encodeURI und encodeURIComponent, die UTF-8-Kodierung auf eine Zeichenkette anwenden und dann die resultierenden Bytes perzentual entschlüsseln. ⓘ
Der Typ application/x-www-form-urlencoded
Wenn Daten, die in HTML-Formulare eingegeben wurden, übermittelt werden, werden die Namen und Werte der Formularfelder kodiert und in einer HTTP-Anforderungsnachricht mit der Methode GET oder POST an den Server gesendet, oder, wie früher, per E-Mail. Die standardmäßig verwendete Kodierung basiert auf einer frühen Version der allgemeinen URI-Prozentkodierungsregeln, mit einer Reihe von Änderungen wie der Normalisierung von Zeilenumbrüchen und dem Ersetzen von Leerzeichen durch + anstelle von %20. Der Medientyp der auf diese Weise kodierten Daten ist application/x-www-form-urlencoded und ist derzeit in den HTML- und XForms-Spezifikationen definiert. Darüber hinaus enthält die CGI-Spezifikation Regeln dafür, wie Webserver Daten dieses Typs dekodieren und sie Anwendungen zur Verfügung stellen. ⓘ
Wenn HTML-Formulardaten in einer HTTP-GET-Anfrage gesendet werden, werden sie in die Abfragekomponente der Anfrage-URI unter Verwendung der oben beschriebenen Syntax aufgenommen. Wenn sie in einer HTTP-POST-Anforderung oder per E-Mail gesendet werden, werden die Daten in den Textkörper der Nachricht eingefügt, und application/x-www-form-urlencoded wird in den Content-Type-Header der Nachricht aufgenommen. ⓘ
Mit dem MIME-Typ application/x-www-form-urlencoded können URL-kodierte Daten gekennzeichnet werden. Bei der Übermittlung von Web-Formularangaben mittels der POST-Methode wird dieser MIME-Typ als Inhaltstyp (Content-Type) angegeben. Aus historischen Gründen stimmt die Kodierung nicht genau mit der Kodierung in URLs überein; insbesondere wird ein Leerzeichen nicht mit ‚%20‘, sondern stattdessen mit einem einzelnen ‚+‘ kodiert. ⓘ
Prozentdarstellung
Nicht-ASCII-Zeichen
Eindeutigkeit der Zeichendekodierung
Einzeln kodierte ASCII-Zeichen (zum Beispiel %23 für #) werden in ASCII, in UTF-8 und in den meisten anderen gängigen Kodierungen wie ISO 8859-15 identisch kodiert. ⓘ
Bei Zahlen von 128 bis 255 ist die Kodierung unsicher: Entweder handelt es sich um eine UTF-8-Kodefolge (bzw. deren Beginn) oder um eine Kodierung für einen beschränkten Zeichensatz von 256 Zeichen wie beispielsweise ISO 8859-15. Weil in UTF-8 nur bestimmte aufeinanderfolgende Kodes zulässig sind, können beschränkte Kodierungen und UTF-8 mit einer gewissen Wahrscheinlichkeit auseinandergehalten werden: %C3%B6 wird recht sicher nach UTF-8 das Zeichen „ö“ sein (und nicht nach ISO 8859-15 die Zeichenfolge ö). ⓘ