URL-Encoder/Decoder

Wissenschaft und Geschichte der Prozentkodierung

Die Prozentkodierung entstand aus einer grundlegenden Beschränkung des fruehen Internets: der ASCII-Limitierung. Als Tim Berners-Lee 1994 die URL-Syntax entwarf, beschränkte die Uniform Resource Locator Spezifikation (RFC 1738) Webadressen auf eine kleine Untermenge von ASCII-Zeichen. Dies war für das vorwiegend englischsprachige Internet der fruehen 1990er Jahre sinnvoll, bedeutete aber, dass jedes Zeichen ausserhalb dieses sicheren Satzes einen Darstellungsmechanismus benötigte. Die Lösung war elegant einfach: Jedes unsichere Byte als Prozentzeichen gefolgt von seinem zweistelligen Hexadezimalwert darstellen. Ein Leerzeichen (Bytewert 32, hex 20) wird zu %20, ein Fragezeichen (Bytewert 63, hex 3F) zu %3F. Dieses Schema konnte jeden Bytewert von 00 bis FF darstellen und damit jedes Zeichen in jedem Zeichensatz kodieren. Die Einführung von UTF-8 als Standard-Zeichenkodierung des Webs verwandelte die Prozentkodierung von einem einfachen Byte-Zuordnungsschema in ein Multibyte-Kodierungssystem. Ein einzelnes chinesisches Zeichen kann drei Bytes in UTF-8 benoetigen und erzeugt drei aufeinanderfolgende prozentkodierte Tripletts. Das Eurozeichen beispielsweise belegt drei Bytes (E2, 82, AC) und wird zur sechs Zeichen langen Sequenz %E2%82%AC. Deshalb können kodierte URLs mit nicht-lateinischem Text deutlich länger erscheinen. RFC 3986, veröffentlicht 2005, verfeinerte die urspruengliche URL-Spezifikation und formalisierte die modernen Regeln für die Prozentkodierung. Es etablierte das Konzept reservierter und nicht reservierter Zeichensaetze und klaerte, welche Zeichen als strukturelle Trennzeichen in URLs dienen. Diese Unterscheidung erklärt, warum in JavaScript zwei Kodierungsfunktionen existieren: encodeURI bewahrt Strukturzeichen für vollständige URLs, während encodeURIComponent alles für sicheres Einbetten kodiert. Die Spezifikation führte auch das Prinzip der Normalisierung ein, das definiert, wann zwei unterschiedlich kodierte URLs als aequivalent gelten.

Methodik

URL-Kodierung ersetzt unsichere ASCII-Zeichen durch ein Prozentzeichen (%) gefolgt von zwei hexadezimalen Ziffern, die den Bytewert des Zeichens darstellen. Beispielsweise wird ein Leerzeichen zu %20 (hex 20 = dezimal 32), ein Kaufmanns-Und zu %26 und ein Pluszeichen zu %2B. Die Kodierung folgt RFC 3986, der die Menge der nicht reservierten Zeichen definiert, die nie kodiert werden müssen: Gross- und Kleinbuchstaben (A-Z, a-z), Ziffern (0-9) und vier Sonderzeichen (Bindestrich, Punkt, Unterstrich, Tilde). Dieses Tool bietet zwei Kodierungsmodi, die direkt auf JavaScripts native Funktionen abbilden. Der Komponentenmodus verwendet encodeURIComponent(), das jedes Zeichen ausser dem nicht reservierten Satz kodiert und damit ideal für Query-Parameter-Werte ist, in denen Zeichen wie & und = escaped werden müssen. Der Vollstaendige-URL-Modus verwendet encodeURI(), das zusätzlich URL-Strukturzeichen wie : / ? # [ ] @ ! $ & ' ( ) * + , ; = bewahrt, damit eine vollständige URL nach der Kodierung funktionsfaehig bleibt. Für internationale Zeichen und Emojis konvertiert das Tool den Text zunaechst in seine UTF-8-Byte-Darstellung und kodiert dann jedes Byte einzeln. Ein einzelnes Unicode-Zeichen wie das Eurozeichen kann mehrere prozentkodierte Tripletts (%E2%82%AC) erzeugen, da UTF-8 eine variable Kodierungslänge von ein bis vier Bytes pro Zeichen verwendet.

Ihre Ergebnisse verstehen

Verwenden Sie den Komponentenmodus (encodeURIComponent) immer dann, wenn Sie einen Wert kodieren, der nach einem Gleichheitszeichen in einem Query-String platziert wird. Dies stellt sicher, dass Zeichen wie &, = und # in Ihrem Wert die URL-Struktur nicht versehentlich beschädigen. Verwenden Sie den Vollstaendige-URL-Modus (encodeURI), wenn Sie eine vollständige URL haben und nur Leerzeichen und Nicht-ASCII-Zeichen kodieren moechten, während die Strukturtrennzeichen intakt bleiben. Wenn Sie %25 in Ihrer Ausgabe sehen, bedeutet dies, dass das Prozentzeichen selbst kodiert würde, was typischerweise auf Doppelkodierung hinweist—die Eingabe war bereits prozentkodiert, bevor Sie sie verarbeitet haben. Zweimaliges Dekodieren solcher Strings stellt den Originaltext wieder her. Dies ist einer der häufigsten URL-Kodierungsfehler in Webanwendungen und APIs. Dekodierung ist nützlich, um URLs beim Debugging menschenlesbar zu machen, Serverprotokolle zu analysieren oder Query-Parameter zu inspizieren, die kodierte Werte enthalten. Internationale Domainnamen (IDN) verwenden eine andere Kodierung namens Punycode statt Prozentkodierung, sodass Domainnamen mit nicht-lateinischen Zeichen eine separate Behandlung erfordern. Kodieren Sie Benutzereingaben immer vor dem Einfuegen in URLs, um Injection-Angriffe zu verhindern.

Praktische Beispiele

Suchabfrage-Parameter: Die Kodierung von 'coffee & tea' im Komponentenmodus ergibt 'coffee%20%26%20tea', wobei sowohl Leerzeichen als auch Kaufmanns-Und sicher escaped werden, damit der Server den wortwoertlichen Text erhaelt. Formularübermittlung: Ein Benutzer gibt 'price=50$' ein, was als 'price%3D50%24' kodiert werden muss, damit das Gleichheitszeichen nicht als Schlüssel-Wert-Trenner interpretiert wird. API-Redirect-URLs: Wenn eine Callback-URL wie 'https://app.com/auth?token=abc' als Parameter an eine andere URL übergeben wird, kodiert der Komponentenmodus den gesamten Callback einschließlich seines eigenen Query-Strings. Mehrsprachiger Inhalt: Die Kodierung japanischer Schriftzeichen erzeugt UTF-8-Bytesequenzen als Prozent-Tripletts. Debug-Dekodierung: Fuegen Sie eine vollständige URL aus Serverprotokollen ein und dekodieren Sie sie, um die urspruengliche Abfrage sofort zur schnellen Fehlersuche zu sehen.

Tipps und Best Practices

Verwenden Sie immer den Komponentenmodus beim Kodieren einzelner Query-Parameter-Werte. Der Vollstaendige-URL-Modus lässt Strukturzeichen wie & und = unkodiert, was Ihre URL beschädigt, wenn diese Zeichen in den Daten selbst statt als Trennzeichen vorkommen. Vermeiden Sie Doppelkodierung, indem Sie prüfen, ob Ihre Eingabe bereits prozentkodiert ist. Wenn Sie Sequenzen wie %20 oder %26 in der Eingabe sehen, dekodieren Sie zuerst vor dem erneuten Kodieren, um Staplung zu verhindern (wobei %20 zu %2520 wird). Beim programmatischen Erstellen von URLs kodieren Sie jeden Parameterwert separat und setzen dann die vollständige URL zusammen. Kodieren Sie niemals die gesamte URL auf einmal, da dies die Strukturzeichen beschädigt, die Schema, Host, Pfad und Query trennen. Zum Debuggen von API-Aufrufen fuegen Sie die vollständig kodierte URL in den Dekodierungsmodus ein, um alle Parameterwerte schnell in lesbarer Form zu sehen. Dies ist besonders hilfreich bei der Fehlerbehebung von Webhook-URLs oder OAuth-Callback-Redirects mit verschachtelten kodierten Werten.

Häufige URL-Kodierungen

Quellen

• RFC 3986 – Generische URI-Syntax
• MDN – encodeURIComponent