URL-Encoder und -Decoder

So funktioniert der URL-Encoder und -Decoder

Der URL-Encoder wandelt Text in die Prozentkodierung, die Webadressen verlangen, und zurück: Beim Kodieren als ganze URL bleiben Doppelpunkt, Schrägstrich, Fragezeichen, Und-Zeichen und Gleichheitszeichen stehen, nur Leerzeichen, Umlaute und andere Sonderzeichen werden zu %XX; beim Kodieren als Parameterwert wird alles außer Buchstaben, Ziffern und den vier Zeichen - _ . ~ kodiert, so dass auch ein & oder ? im Wert nicht die Adresse zerlegt; beim Dekodieren werden %XX-Folgen zurück in Zeichen übersetzt, Pluszeichen als Leerzeichen gelesen. Das Ergebnis zeigt, wie viele Zeichen kodiert werden mussten, und lässt sich kopieren.

Merksatz: Eine URL darf nur ASCII-Zeichen ohne Leerzeichen enthalten, alles andere wird byteweise als Prozent plus zwei Hexziffern geschrieben, ein ä als UTF-8 wird %C3%A4. Die Eselsbrücke: Ganze URL schont die Struktur, Parameterwert kodiert alles, und zum Lesen dekodiert man.

Drei Beispiele:

• "Stra%C3%9Fe%20%26%20Hausnummer%3F" dekodiert: "Straße & Hausnummer?", 20 Zeichen; das ß war %C3%9F, das Leerzeichen %20, das & %26, das ? %3F.
• "brutto netto & mehr?" als Parameterwert: "brutto%20netto%20%26%20mehr%3F", 30 Zeichen, 5 kodiert.
• "https://rechner24.net/suche?q=brutto netto&land=Deutschland" als ganze URL: nur das Leerzeichen wird %20, der Rest bleibt, 61 Zeichen.

Regeln statt Formeln: Kodiert = % + zwei Hexziffern je Byte (UTF-8), ganze URL lässt : / ? & = # stehen, Parameterwert kodiert alles außer A-Z, a-z, 0-9, - _ . ~, Formulare senden Leerzeichen als +. Wer Daten nicht für Adressen, sondern für Textfelder verpacken will, nimmt das Base64-Tool, und wer aus einem Titel einen Adressteil mit Bindestrichen machen will, die Groß- und Kleinschreibung mit kebab-case.

Wissenswertes zum Thema

Warum Adressen kodiert werden müssen

Eine URL ist nach RFC 3986 eine Zeichenkette aus einem eingeschränkten Vorrat: Buchstaben, Ziffern und die Zeichen - . _ ~ dürfen überall stehen, "unreserved", die Zeichen : / ? # [ ] @ ! $ & ' ( ) * + , ; = haben Bedeutung in der Struktur, "reserved", der Doppelpunkt trennt das Schema, der Schrägstrich die Pfadteile, das Fragezeichen leitet die Parameter ein, das Und-Zeichen trennt sie, das Gleichheitszeichen trennt Name und Wert, die Raute markiert den Anker; alles andere, Leerzeichen, Umlaute, Anführungszeichen, Prozentzeichen selbst, muss kodiert werden, und reservierte Zeichen müssen kodiert werden, wenn sie als Daten gemeint sind, nicht als Struktur. Die Kodierung schreibt jedes Byte als Prozentzeichen plus zwei Hexziffern, das Leerzeichen als %20, das & als %26, und Zeichen außerhalb von ASCII vorher als UTF-8, so dass das ä zu %C3%A4 wird, das ß zu %C3%9F, das Euro-Zeichen zu %E2%82%AC. Das Tool nutzt dafür die beiden Browserfunktionen encodeURI für die ganze URL, die reservierte Zeichen stehen lässt, und encodeURIComponent für den Parameterwert, die alles außer den vier unreserved Sonderzeichen kodiert, und decodeURIComponent zum Lesen; die drei stecken in jedem Browser und jeder Programmiersprache unter ähnlichem Namen, urllib.parse.quote in Python, rawurlencode in PHP. Das Pluszeichen ist der Sonderfall: HTML-Formulare mit der Kodierung application/x-www-form-urlencoded senden Leerzeichen als +, und beim Dekodieren liest das Tool deshalb + als Leerzeichen, während ein echtes Plus im Wert als %2B kodiert sein muss. Für die Prüfung, ob ein kodierter String nach dem Dekodieren gültiges JSON ergibt, hilft der JSON-Formatter.

Wo man den Encoder braucht

Der häufigste Fall ist der Link mit Parametern: Eine Suche nach "brutto netto" wird zu ?q=brutto%20netto, ein Link auf eine Seite mit Umlaut im Namen zu /stra%C3%9Fe, und wer in E-Mails, Chats oder Dokumenten Links mit Leerzeichen verschickt, erlebt, dass der Link an der Lücke abbricht. Der zweite sind Tracking-Parameter und Deeplinks, bei denen ein Wert eine ganze URL enthält, utm_content=https://… oder redirect=/konto?tab=2, und die innere URL als Parameterwert kodiert werden muss, damit ihr ? und & nicht die äußere Adresse zerlegen, das klassische Beispiel für encodeURIComponent. Der dritte sind mailto-Links mit Betreff und Text, mailto:info@firma.de?subject=Anfrage%20Angebot&body=Guten%20Tag%2C, bei denen Zeilenumbrüche %0A sind. Der vierte sind API-Aufrufe, in denen Suchbegriffe, Adressen und Namen als Parameter mitgehen, und der fünfte das Lesen von Logs und Adressen, in denen Browser alles kodiert haben, Stra%C3%9Fe%20%26%20Hausnummer%3F, und man wissen will, was der Nutzer eingegeben hat. Dateinamen mit Umlauten auf Webservern sind der sechste, der Browser kodiert sie beim Aufruf und der Server dekodiert sie, was bei Latin-1-Servern schiefgeht. Der siebte sind OAuth- und Zahlungs-Redirects, deren Rücksprungadressen doppelt kodiert sein müssen, einmal als Parameterwert und dann noch einmal, wenn sie selbst in einem Parameter stehen. Und der achte sind QR-Codes, in die URLs mit Umlauten nur kodiert passen. Was ein QR-Code aus einer kodierten Adresse macht, zeigt der QR-Code-Generator direkt.

Typische Fehler beim Kodieren und Dekodieren

Der erste Fehler ist die ganze URL mit dem Parameter-Modus, dann werden : / ? & = zu %3A %2F %3F %26 %3D und die Adresse funktioniert nicht mehr; umgekehrt der Parameterwert mit dem URL-Modus, dann bleibt ein & im Wert stehen und schneidet ihn ab. Der zweite ist das doppelte Kodieren, %20 wird zu %2520, und die Seite zeigt "%20" statt eines Leerzeichens, erkennbar an %25 im Ergebnis. Der dritte ist das Vergessen des Zeichensatzes, Latin-1-kodierte Adressen haben %E4 für ä, UTF-8 %C3%A4, und moderne Browser und das Tool nutzen UTF-8. Der vierte ist das Plus, ein + im Wert, das als Leerzeichen gelesen wird, etwa in Telefonnummern mit +49 oder in E-Mail-Adressen mit Plus-Alias. Der fünfte ist das unvollständige Prozentzeichen beim Dekodieren, "100%" am Ende ergibt einen Fehler, weil % zwei Hexziffern erwartet, und ein echtes Prozentzeichen muss %25 sein. Der sechste sind Raute und Anker, ein # im Wert beendet die URL für den Server, alles danach bleibt im Browser. Der siebte sind Leerzeichen am Ende von Links in Mails, die Mailprogramme mitkodieren. Der achte ist die Annahme, Kodierung sei Schutz, sie ist nur Transport, und Parameter, die in Datenbankabfragen fließen, brauchen Escaping im Programm, nicht in der URL. Und der neunte ist die Länge, Browser verkraften 2.000 Zeichen URL sicher, kodierte Texte wachsen auf das Dreifache. Was die Zeichenzahl der kodierten Adresse im Vergleich zum Klartext ausmacht, zählt der Zeichenzähler.

Ein Stück Geschichte: Von RFC 1738 zum Unicode in der Adresse

Tim Berners-Lee schrieb 1990 die erste Webadresse und 1994 mit RFC 1738 den Standard für Uniform Resource Locators, in dem die Prozentkodierung steht, übernommen aus den Konventionen des Internets der 1980er, wo das Prozentzeichen schon in anderen Protokollen als Fluchtzeichen diente; der Zeichenvorrat war ASCII, weil die Netze der Zeit nicht mehr sicher übertrugen, und Umlaute kamen in Adressen schlicht nicht vor. RFC 2396 von 1998 ordnete die Zeichen in reserved und unreserved, RFC 3986 von 2005 legte die bis heute gültige Fassung fest und schrieb UTF-8 als Kodierung für Nicht-ASCII-Zeichen vor, nachdem Browser jahrelang Latin-1 und UTF-8 gemischt hatten. Die JavaScript-Funktionen escape und unescape von 1995 kodierten noch nach Latin-1 und sind seit 1999 durch encodeURI und encodeURIComponent ersetzt, die UTF-8 nutzen und bis heute im Tool arbeiten. Die internationalisierten Adressen, IRI nach RFC 3987 von 2005, erlauben Umlaute und andere Schriften in der Anzeige, der Browser zeigt "rechner24.net/straße" und sendet "/stra%C3%9Fe", und seit 2004 sind Umlautdomains wie "müller.de" über Punycode möglich, xn--mller-kva.de, eine andere Kodierung für den Domainteil. Das WHATWG-URL-Standard von 2012 beschreibt, wie Browser Adressen tatsächlich verarbeiten, mit allen Abweichungen vom RFC, und ist die Referenz für das, was das Tool tut. Der Encoder kodiert, was Berners-Lee 1994 für ASCII-Netze festlegte, mit dem UTF-8 von 2005.

Praktische Tipps

Kodieren Sie Parameterwerte mit dem Parameter-Modus und ganze Adressen mit dem URL-Modus, nie umgekehrt. Prüfen Sie auf %25 im Ergebnis, das ist doppelt kodiert. Schreiben Sie ein echtes Plus als %2B und ein echtes Prozent als %25. Setzen Sie innere URLs in Parametern komplett kodiert ein. Dekodieren Sie fremde Adressen aus Logs, bevor Sie sie weitergeben, oft stehen Daten drin. Halten Sie Adressen unter 2.000 Zeichen. Nutzen Sie UTF-8 durchgehend, auch auf dem Server. Und testen Sie den Link nach dem Kodieren im Browser. Für Daten, die nicht in eine Adresse gehören, etwa Binärdaten oder lange Texte, ist das Base64-Tool die passende Verpackung.