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 waren einige Informationen nicht in einer URL darstellbar. Beispielsweise wird ein
Leerzeichen
in aller Regel vom Browser als Ende der URL interpretiert, nachfolgende Zeichen wurden ignoriert oder fuhrten zu einem Fehler. Mit der URL-Kodierung kann ein Leerzeichen durch die Zeichenfolge
%20
ubergeben 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 fur 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.
URLs konnen aus folgenden Teilen bestehen:
https://maxmuster:geheim@www.example.com:8080/index.html?p1=A&p2=B#ressource
\___/ \_______/ \____/ \_____________/ \__/\_________/ \_______/ \_______/
| | | | | | | |
Schema Benutzer Kennwort Host Port Pfad Query Fragment
Bestimmte Zeichen innerhalb dieses Ausdrucks kennzeichnen und trennen die einzelnen Segmente der URL und ermoglichen eine Zerlegung und Verarbeitung des Ausdrucks. Bei einem
HTTP
-Zugriff beispielsweise:
Weitere Zeichen haben spezifische Bedeutungen im
Dokumentenpfad
. Folgende Zeichen gelten als reserviert:
: / ? # [ ] @ ! $ % & ' ( ) * + , ; =
Folgende Zeichen sind nicht reserviert, besitzen also in einer URL keine vorgegebene Bedeutung:
- Buchstaben:
A?Z, a?z
- Ziffern:
0?9
- . _ ~
Eine URL besteht aus den genannten reservierten und nicht reservierten Zeichen. Sie darf keine anderen Zeichen enthalten. Es besteht jedoch prinzipiell der Bedarf, in URLs beliebige
Byte
-Folgen ? also samtliche Werte zwischen 0 und 255 ? darstellen zu konnen. Zudem muss eine Moglichkeit existieren, reservierte Zeichen in einer URL derart schreiben zu konnen, dass sie ihre speziellen Bedeutungen verlieren (siehe auch
Escape-Sequenz
).
Die Prozentdarstellung von Zeichen tragt beiden Forderungen Rechnung. Ihr zugrunde liegt ein Kodierungsverfahren, das jedem Zeichencode eine dreistellige Zeichenkombination zuordnet, die mit dem Prozentzeichen beginnt, dem die zweiziffrige
hexadezimale
Darstellung des Zeichencodes folgt.
Ein reserviertes Zeichen muss in einer URL in prozentkodierter Form geschrieben werden, wenn es an der Stelle, an der es sich befindet, eine besondere Bedeutung hat, diese aber im vorliegenden Kontext nicht haben soll. Nicht reservierte Zeichen konnen, sollten aber nicht, prozentkodiert werden. Bei anderen Zeichen (unter anderem Binardaten) besteht meist gar keine andere Moglichkeit, als sie in einer URL in prozentkodierter Form darzustellen (Ausnahme: reserviertes Zeichen ?
+
‘ anstelle eines
Leerzeichens
im Query-String).
Beispiel:
Laut ASCII ist dem Zeichen ?
#
‘ der hexadezimale Zeichencode 23 zugeordnet. Somit stellt der Ausdruck ?
%23
‘ die prozent-kodierte Form des Zeichens ?
#
‘ dar.
Die Interpretation von:
http://www.example.net/index.html?session=A54C6FE2#info
ist eindeutig. Es wurde ein URL-Parameter namens
session
definiert, dem der Wert
A54C6FE2
zugewiesen ist, sowie der Dokumentenanker namens
info
angegeben. Das Zeichen ?
#
‘ hat in dem vorliegenden Kontext die besondere Bedeutung, dass ihm der Name eines Dokumentenankers folgt. Soll es diese Bedeutung verlieren, d. h. dem URL-Parameter
session
der Wert
A54C6FE2#info
zugewiesen werden, so muss das Zeichen ?
#
‘ in prozent-kodierter Form in der URL stehen:
http://www.example.net/index.html?session=A54C6FE2%23info
|
In der Praxis wird dieser Mechanismus nicht immer einheitlich angewendet. Es gibt jedoch Falle, in denen die Verwendung notig ist, beispielsweise beim Aufruf eines Ankers uber einen
Dereferrerdienst
.
|
!
|
"
|
#
|
$
|
%
|
&
|
'
|
(
|
)
|
*
|
+
|
,
|
-
|
.
|
/
|
:
|
;
|
<
|
=
|
>
|
?
|
@
|
[
|
\
|
]
|
{
|
|
|
}
|
%20
|
%21
|
%22
|
%23
|
%24
|
%25
|
%26
|
%27
|
%28
|
%29
|
%2A
|
%2B
|
%2C
|
%2D
|
%2E
|
%2F
|
%3A
|
%3B
|
%3C
|
%3D
|
%3E
|
%3F
|
%40
|
%5B
|
%5C
|
%5D
|
%7B
|
%7C
|
%7D
|
Auch fur die Zeichen, die nicht im ASCII-Zeichensatz enthalten sind, werden die Bytes mit vorangestelltem ?
%
‘ kodiert. Welche Bitfolge ein Zeichen jedoch darstellt, hangt von der zu benutzenden
Zeichenkodierung
ab. Es wird zwar vom RFC 3986 empfohlen,
UTF-8
zur Kodierung zu benutzen, da dieses
Unicode
-Format fur alle internationalen Zeichen benutzt werden kann, was UTF-8 zwar zur Quasi-Standardkodierung fur URIs macht, aber einen expliziten Standard gibt es noch nicht. Um die URL kodieren zu konnen, muss man also wissen oder ahnen, welche Zeichenkodierung fur die abzurufende Datei benutzt wurde oder welche Kodierung der Zielrechner benutzt. Aus diesem Grund ist es immer noch sinnvoll, nur auf Zeichen aus dem ASCII-Vorrat zuruckzugreifen.
In der empfohlenen Kodierung UTF-8 ware beispielsweise der Buchstabe ?o“ (mit dem dezimalen Unicode-Zeichenwert 246) als
%C3%B6
dargestellt. Alle Zeichenwerte uber 127 werden von UTF-8 als Kombinationen von zwei oder mehr Bytes reprasentiert und dementsprechend in die Prozent-Kodierung ubernommen. Die Schriftzeichen des (um
Diakritika
erweiterten)
lateinischen Alphabets
erhalten dabei alle eine Darstellung mit zwei Bytes. Mehr Bytes benotigen zum Beispiel
CJK
-Zeichen.
Mitunter wird immer noch
ISO 8859-1
(Latin-1) fur die Darstellung benutzt und dessen identischer dezimaler Zeichenwert 246 direkt mit Hilfe der Prozentkodierung in die URL eingefugt. Der
Umlaut
?o“ wird dann als Wert
%F6
dargestellt.
Beide Darstellungsarten ubermitteln dem Server aber unterschiedliche Bitfolgen. Obwohl beide nach ihrer Art richtig kodiert sind, liefert nur eine davon die gewunschte Datei und die andere meist nur eine Fehlermeldung. Bei einigen Servern ? wie zum Beispiel denen der Wikipedia ? wird jedoch versucht, die Kodierung zu ermitteln, so dass dann auf die richtige Datei weitergeleitet werden kann. Wenn es mit einer Kodierung nicht klappt, sollte man eine der anderen wahrscheinlichen Varianten probieren.
Einzeln kodierte ASCII-Zeichen (zum Beispiel
%23
fur
#
) werden in
ASCII
, in
UTF-8
und in den meisten anderen gangigen 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 fur einen beschrankten Zeichensatz von 256 Zeichen wie beispielsweise ISO 8859-15. Weil in UTF-8 nur bestimmte aufeinanderfolgende Kodes zulassig sind, konnen beschrankte Kodierungen und UTF-8 mit einer gewissen Wahrscheinlichkeit auseinandergehalten werden:
%C3%B6
wird recht sicher nach UTF-8 das Zeichen ?o“ sein (und nicht nach ISO 8859-15 die Zeichenfolge
A¶
).
Mit dem
MIME
-Typ
application/x-www-form-urlencoded
konnen URL-kodierte Daten gekennzeichnet werden. Bei der Ubermittlung von Web-Formularangaben mittels der
POST
-Methode wird dieser MIME-Typ als Inhaltstyp (
Content-Type
) angegeben. Aus historischen Grunden stimmt die Kodierung nicht genau mit der Kodierung in URLs uberein; insbesondere wird ein Leerzeichen nicht mit ?
%20
‘, sondern stattdessen mit einem einzelnen ?
+
‘ kodiert.
[1]
- RFC
3986
?
Uniform Resource Identifier (URI): Generic Syntax
. Januar 2005 (englisch).
- M. Duerst, M. Suignard:
RFC
3987
?
Internationalized Resource Identifiers (IRIs)
. Januar 2005 (bieten eine eindeutig unterscheidbare Alternative zur Darstellung von URIs mit Unicode-Zeichen und verwenden eine erweiterte Variante der URL-Kodierung, englisch).
- URL Encoding Tool
- ↑
HTML 4.01 Specification:
17.13.4 Form content types
24. Dezember 1999.