„URL-Encoding“ – Versionsunterschied

URL-Encoding (URL-Kodierung, auch Prozentkodierung genannt) ist ein Mechanismus, um 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 bzw. führen 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.

Reservierte und nicht-reservierte Zeichen

URLs können maximal folgende Felder enthalten:

http://joe:passwd@www.example.net:8080/index.html?action=something&session=A54C6FE2#info

Bestimmte Zeichen innerhalb dieses Ausdrucks kennzeichnen und trennen die einzelnen Segmente der URL und ermöglichen eine Zerlegung und Verarbeitung des Ausdrucks. Bei einem HTTP-Zugriff beispielsweise:

• leitet das Fragezeichen (?) den Datenteil (Query-String) der URL ein,
• steht das Gleichheitszeichen (=) zwischen dem Namen eines Parameters und seinem Wert,
• steht das Kaufmannsund (&) als Trennzeichen zwischen „Parameter=Wert“-Elementen im Datenteil,
• folgt dem Doppelkreuz (#) der Name eines Dokumentenankers (siehe auch URI-Referenz).

Weitere Zeichen haben spezifische Bedeutungen im Dokumentenpfad. Insgesamt gelten folgende Zeichen als reserviert:

! # $ % & ' ( ) * + , / : ; = ? @ [ ]

Folgende Zeichen(gruppen) sind nicht reserviert, besitzen also in einer URL keine vorgegebene Bedeutung:

Buchstaben [A-Z, a-z], Ziffern [0-9] und

- _ . ~

%-Darstellung

Eine URL besteht aus den genannten reservierten und nicht-reservierten Zeichen; andere Zeichen dürfen in ihr nicht vorkommen. Es besteht jedoch prinzipiell der Bedarf, in URLs beliebige Byte-Folgen – also sämtliche Werte zwischen 0 und 255 – darstellen zu können. Zudem muss eine Möglichkeit existieren, reservierte Zeichen in einer URL derart schreiben zu können, dass sie ihre speziellen Bedeutungen verlieren (siehe auch: Escape-Sequenz).

Die %-Darstellung von Zeichen trägt beiden Forderungen Rechnung. Ihr zugrunde liegt ein Kodierungsverfahren, welches jedem Zeichencode eine 3-stellige Zeichenkombination zuordnet, die mit dem Prozentzeichen eingeleitet wird, dem die zweiziffrige hexadezimale Darstellung des Zeichencodes folgt.

Ein reserviertes Zeichen ist in einer URL in %-kodierter Form zu schreiben, 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 können %-kodiert werden, sollten es aber nicht. Bei anderen Zeichen (u. a. Binärdaten) besteht meist gar keine andere Möglichkeit, als sie in einer URL in %-kodierter Form darzustellen (Ausnahme: reserviertes Zeichen „+“ anstelle eines Leerzeichens im sogenannten „Query-String“).

Beispiel: Laut ASCII ist dem Zeichen „#“ der hexadezimale Zeichencode 23 zugeordnet. Insofern stellt der Ausdruck „%23“ die %-kodierte Form des Zeichens „#“ dar. Die Interpretation von http://www.example.net/index.html?session=A54C6FE2#info ist eindeutig: Hier wurden 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. soll dem URL-Parameter session der Wert A54C6FE2#info zugewiesen werden, so muss das Zeichen „#“ in %-kodierter Form in der URL stehen: http://www.example.net/index.html?session=A54C6FE2%23info

In der Praxis wird der Mechanismus nicht immer einheitlich angewendet. Es gibt jedoch Fälle, in denen die Verwendung nötig ist, beispielsweise beim Aufruf eines Ankers über einen Dereferrerdienst.

Nicht-ASCII-Zeichen

Für alle Nicht-ASCII-Zeichen gilt, dass sie mithilfe der %-Kodierung abgebildet werden müssen.

Bei URLs (genauso wie bei IRIs) ist es wichtig zu beachten, dass sie als Folge von Zeichen (Characters) definiert sind und nicht als Folge von Bytes. D.h. es muss unterschieden werden zwischen der Kodierung in der die URL selbst digital abgespeichert ist, und der Kodierung der Zeichen (%-Kodierung), die Teil der URL sind.

Erstere ist abhängig vom verwendeten Protokoll bzw. von der verwendeten Anwendung. Beispielsweise wird in einer EBCDIC kodierten Datei auch eine URL EBCDIC kodiert hintelegt. Die Zeichen in der URL müssen jedoch mit dem ASCII-Zeichensatfz abbildbar sein, bzw. mithilfe der %-Kodierung.

RFC 3986 definiert, dass für die %-Kodierung UTF-8 in der folgenden Form verwendet werden sollte:

In der empfohlenen Kodierung UTF-8 wäre der Buchstabe ö (mit dem Unicode-Zeichenwert 246) als %C3%B6 dargestellt. Alle Zeichenwerte über 127 werden in zwei, drei oder vier Byte-Werten repräsentiert und dem entsprechend in die %-Kodierung übernommen; wobei alle üblichen Schriftzeichen mit zwei Bytes repräsentiert werden, mehr Bytes benötigen lediglich ungebräuchliche Zeichen sowie Markierungen der Richtungsumkehr.

Da UTF-8 ein Superset von ASCII darstellt, ist es kein Problem ASCII Zeichen mithilfe der %-Kodierung darzustellen. Dies stellt die Abwärtskompatibilität sicher.

Viele Serverapplikation (unter anderem Tomcat) verwenden inzwischen ISO 8859-1 (Latin-1) als URL Standardzeichensatz anstelle von ASCII. Dadurch können z.B. Umlaute in URLs verwendet werden. (ISO 8859-1 (Latin-1) ist ein Superset von ASCII und ein Subset von UTF-8, weshalb auch hier Abwärts- und Aufwärtskompatibilität gegeben ist.) Dies ist jedoch nicht Teil des Standards und muss daher auch nicht von allen Diensten unterstützt werden. Außerdem gibt es auch schon die Unterstützung für UTF-8 kodierte URLs bei Serverapplikationen. Auch dies ist nicht Teil des URL Standards zeigt aber den Schrittweisen Übergang von URIs zu IRIs.

Leider setzen manche Serverapplikation bei der Verwendung von UTF-8 Zeichen in URLs, die %-Kodierten Zeichen nicht mehr korrekt um in die entsprechenden UTF-8 Zeichen und sind daher nicht mehr in der Lage die entsprechenden Ressourcen zu finden. Beispielsweise könnte der Server den Umlaut ö als %F6 in %-Kodierung übermittelt bekommen und versuchen die Datei '%F6sterreich.html' zu öffnen, anstatt (was eine korrekte Interpretation der URL wäre) die Ressource 'österreich.html'.

Eindeutigkeit

Eine Unterscheidung zwischen zwei einzelnen kodierten ASCII-Zeichen (z. B. %23%23 für ##) und einem 2-Byte-UTF-8-Zeichen (z. B. %C3%B6) ergibt sich aus der Art, wie UTF-8 kodiert ist. Die einzelnen Bytes ergeben für sich allein keine gültigen ASCII-Zeichen, da C3 der dezimalen 195 entspricht und B6 der 182. Da ASCII-Zeichen maximal den Wert 127 (126) annehmen, können es auch keine zwei einzelnen Zeichen sein und die Zeichen werden zusammen als UTF-8-kodiert angenommen. Eine Verwechslung ist somit nicht möglich. Auf einer ähnlichen Basis können einige Server auch ermitteln, welche Kodierung in der URL verwendet wird. Eine weitere Eigenheit bei der %-Kodierung von UTF-8-Zeichen ist, dass der erste Codewert immer ein Zeichencode der oberen Reihe der ISO 8859-1 ist (192–239), der folgende Codewert (bzw. die folgenden, wenn mehr als zwei Byte) liegt immer zwischen 128 und 191.

MIME-Typ

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 ; gelegentlich auch mit expliziter Kodierung: "application/x-www-form-urlencoded; charset: UTF-8".

Weblinks

• RFC 3986 – Uniform Resource Identifier (URI): Generic Syntax
• RFC 3987 – Internationalized Resource Identifiers (IRIs) bieten eine eindeutig unterscheidbare Alternative zur Darstellung von URIs mit Unicode-Zeichen und verwenden eine erweiterte Variante der URL-Kodierung
• Online URL De-/Encoder
• Online URL/Base64/Hex De-/Encoder