Wie Sie URLs kodieren und dekodieren

Wenn Sie jemals %20 in einer URL gesehen haben, wo ein Leerzeichen sein sollte, oder %C3%A9, wo ein akzentuiertes Zeichen hingehört, sind Sie auf URL-Kodierung gestoßen. Es ist ein grundlegender Bestandteil davon, wie das Web funktioniert, und es zu verstehen hilft Ihnen beim Debuggen kaputter Links, API-Probleme und Formularübermittlungen. Ein browserbasierter Encoder erledigt die gesamte Arbeit lokal, ohne Ihre Daten auf einen Server hochzuladen.

Was URL-Kodierung tut

URLs können nur einen begrenzten Satz von Zeichen sicher enthalten: Buchstaben (A-Z, a-z), Ziffern (0-9) und einige Sonderzeichen (-, _, ., ~). Alles andere (Leerzeichen, akzentuierte Zeichen, Emoji und Symbole wie &, =, #, ?) muss in ein sicheres Format konvertiert werden.

URL-Kodierung (auch Prozent-Kodierung genannt) ersetzt unsichere Zeichen durch ein % gefolgt von ihren hexadezimalen Bytewerten:

Wann Sie URL-Kodierung benötigen

• Abfrageparameter mit Sonderzeichen: Eine Suchanfrage wie preis > 100 & kategorie = schuhe muss kodiert werden, um in einer URL zu funktionieren
• Nicht-englische Zeichen in URLs: Namen, Städte oder Inhalte in anderen Sprachen müssen kodiert werden
• API-Anfragen: Beim manuellen Erstellen von API-Aufrufen müssen Parameterwerte oft kodiert werden
• Debugging: Wenn eine URL nicht funktioniert, zeigt das Dekodieren, was die tatsächlichen Werte sind
• E-Mail-Links (mailto:): Betreffzeilen und Textinhalte in mailto-Links müssen kodiert werden
• OAuth-Umleitungs-URIs: Der an OAuth-Anbieter übergebene redirect_uri-Parameter muss vollständig kodiert sein
• Webhook-Payloads: Abfragestrings in Webhook-URLs, die von Diensten wie Stripe oder Slack geliefert werden
• Deep Links in mobile Apps: Benutzerdefinierte URL-Schemas für iOS/Android-Apps benötigen Kodierung für sichere Handhabung
• GraphQL-persistente Abfragen: Gehashte Abfragen, die als URL-Parameter angehängt werden, müssen kodiert werden
• PostgreSQL-Verbindungszeichenfolgen: Passwörter und andere Sonderzeichen in DATABASE_URL-Werten

So kodieren und dekodieren Sie

1. Wählen Sie kodieren oder dekodieren: Wählen Sie die Richtung. Wählen Sie encodeURIComponent für Abfrageparameter oder encodeURI für vollständige URLs.
2. Fügen Sie Ihre Eingabe ein: Geben Sie den Text oder die URL ein. Das Ergebnis wird sofort aktualisiert.
3. Kopieren Sie die Ausgabe: Verwenden Sie das Ergebnis in Ihrem Code, Ihrer API-Anfrage oder Ihrem Browser.

Eine kurze Geschichte der URL-Kodierung

Die URL-Kodierung wurde im Dezember 1994 durch RFC 1738 zusammen mit der ursprünglichen URL-Spezifikation definiert. Der RFC wurde von Tim Berners-Lee (Erfinder des Webs) mit Eingaben der IETF URI Working Group geschrieben. Das ursprüngliche Kodierungsschema verwendete ASCII-Bytewerte: jedes reservierte oder unsichere Zeichen wurde als % gefolgt von zwei Hex-Ziffern kodiert.

Die Kodierung wurde mehrmals aktualisiert:

• RFC 1738 (1994): ursprüngliche URL-Spezifikation, nur ASCII
• RFC 2396 (1998): strengere Syntax, trennte «reservierte» von «nicht reservierten» Zeichen
• RFC 3986 (2005): aktuelle URI-Spezifikation, definiert zwei Kodierungsmodi (Pfad vs Abfrage), UTF-8-Byte-Sequenzen für Nicht-ASCII
• WHATWG URL-Standard (laufend): die lebende Browser-Standard-Spezifikation, die von allen modernen Browsern verwendet wird, geringfügig andere Regeln als RFC 3986 für Abwärtskompatibilität

Die größte Änderung war die Umstellung auf UTF-8 in RFC 3986. Davor waren kodierte URLs nur ASCII, und nicht-lateinische Zeichen erforderten Workarounds (Punycode für Domains, IDN für internationale Adressen). Heute kodiert ein akzentuiertes «é» in einer URL zu %C3%A9 (seine zwei UTF-8-Bytes), nicht zu dem Latin-1-Byte %E9, das ältere Systeme produzieren würden.

encodeURI vs encodeURIComponent vs encodeURIFull

JavaScript hat drei Kodierungsfunktionen mit subtil unterschiedlichem Verhalten:

In Python:

• urllib.parse.quote() ist wie encodeURI (behält /, aber nicht :)
• urllib.parse.quote_plus() ist wie encodeURIComponent, verwendet aber + für Leerzeichen
• urllib.parse.urlencode(dict) kodiert ganze Abfragestrings

In anderen Sprachen:

Häufige Stolperfallen

• Die gesamte URL kodieren: Wenn Sie https://example.com/search?q=hello kodieren, erhalten Sie https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dhello, was keine funktionierende URL mehr ist. Kodieren Sie nur die Werte, nicht die strukturellen Zeichen.
• Doppelte Kodierung: Das Kodieren einer bereits kodierten Zeichenfolge erzeugt Dinge wie %2520 (das % wird als %25 kodiert). Wenn Ihre URL falsch aussieht, prüfen Sie, ob etwas doppelt kodiert wird.
• Leerzeichen als + vs %20: In application/x-www-form-urlencoded (Formular-POST-Bodies) werden Leerzeichen zu +. In URLs werden Leerzeichen zu %20. Die meisten Server akzeptieren beide, aber einige strenge Parser nicht.
• Reservierte Zeichen falsch kodieren: ?, #, &, = haben spezielle Bedeutung in der URL-Syntax. Wenn sie in einem Wert erscheinen, müssen sie kodiert werden; wenn sie als Syntax erscheinen, dürfen sie nicht kodiert werden.
• Vergessen zu dekodieren beim Empfang: Wenn Sie einen Wert kodieren, senden, und Ihr Server ?q=hello%20world wörtlich ohne Dekodierung liest, sieht Ihre Anwendung hello%20world statt hello world. Die meisten Frameworks dekodieren automatisch, aber überprüfen Sie es in benutzerdefiniertem Code.
• Pluszeichen-Verwirrung: + ist ein wörtliches Plus in Pfadsegmenten und ein Leerzeichen in Abfragestrings. Kodieren Sie tatsächliche Pluszeichen als %2B in Abfragewerten, um Mehrdeutigkeit zu vermeiden.
• UTF-8 vs andere Kodierungen: Wenn Ihre URL «résumé» enthält und der Server Latin-1 statt UTF-8 erwartet, können Sie Mojibake erhalten. Modernes Web ist UTF-8; Legacy-Systeme nicht.
• URL-Längenbeschränkungen: Auch wenn es keine strikte Begrenzung in der Spezifikation gibt, begrenzen Browser und Server URLs oft auf 2048-8192 Zeichen. Stark kodierte Daten können Grenzen schneller als erwartet erreichen.
• Cookies und Referer-Header: URLs werden in Referer-Headern übergeben und können protokolliert werden. Sensible Daten in URLs (Passwörter, Token) gelangen in Protokolle und Analysen. Verwenden Sie POST-Bodies für sensible Daten.
• Nicht-ASCII-Domainnamen: Domains verwenden Punycode (RFC 3492), nicht Prozentkodierung. «münchen.de» wird in DNS-Lookups zu «xn--mnchen-3ya.de», nicht zu «m%C3%BCnchen.de».

Durchgearbeitete Beispiele

Tipps

• Werte kodieren, nicht ganze URLs: Wenn Sie eine ganze URL kodieren, werden die Schrägstriche und Doppelpunkte, die die URL strukturieren, ebenfalls kodiert und die URL kaputt gemacht. Kodieren Sie nur die Werte innerhalb der Abfrageparameter.
• Doppelte Kodierung: Das Kodieren einer bereits kodierten Zeichenfolge erzeugt Dinge wie %2520 (das % wird als %25 kodiert). Wenn Ihre URL falsch aussieht, prüfen Sie, ob etwas doppelt kodiert wird.
• Zum Debuggen dekodieren: Wenn eine API-Anfrage fehlschlägt oder eine URL verstümmelt aussieht, dekodieren Sie sie, um die tatsächlichen Parameterwerte zu sehen. Dies enthüllt oft sofort das Problem.
• Verwenden Sie die eingebauten Funktionen Ihrer Sprache: Verwenden Sie im Produktionscode immer encodeURIComponent() (JavaScript), urllib.parse.quote() (Python) oder URLEncoder.encode() (Java) statt manuell zu kodieren.
• Mit Grenzfällen testen: Probieren Sie Eingaben mit Leerzeichen, Akzenten, Emoji und Sonderzeichen aus. Wenn Ihre Kodierung für alle funktioniert, funktioniert sie.
• In der Browser-Adressleiste überprüfen: Fügen Sie Ihre kodierte URL in einen Browser ein. Wenn die Seite lädt, ist die URL wohlgeformt. Wenn nicht, hat Ihre Kodierung einen Fehler.
• Verwenden Sie eine Abfragestring-Bibliothek für komplexe Fälle: Eine Abfragezeichenfolge aus einem Wörterbuch oder Objekt (?a=1&b=2&c=3) zu erstellen ist mit einer Bibliotheksfunktion (urlencode in Python, URLSearchParams in JavaScript) einfacher und sicherer als manuelle Montage.
• Kennen Sie den Unterschied zwischen Pfad- und Abfragekodierung: Ein Schrägstrich / in einem Pfadsegment ist strukturell; in einem Abfragewert muss er kodiert werden. RFC 3986 hat unterschiedliche Regeln für jeden.

Datenschutz und vertrauliche URLs

Der URL-Encoder und -Decoder laufen vollständig in Ihrem Browser. Die URLs, die Sie einfügen, die Zwischenverarbeitung und die kodierte/dekodierte Ausgabe bleiben alle auf Ihrem Gerät. Nichts wird auf einen Server hochgeladen, protokolliert oder mit irgendjemandem geteilt.

Dies ist wichtig, weil URLs häufig extrem sensible Daten enthalten: API-Schlüssel und Token in Abfrageparametern, OAuth-Autorisierungscodes, die Kontozugriff gewähren, Session-IDs, signierte URLs für private S3-Buckets mit eingebetteten Anmeldeinformationen, Magic-Link-Login-Token, Passwort-Reset-URLs, interne Administrator-URLs, die die Produktstruktur enthüllen, Kunden-E-Mail-Adressen in Abmeldelinks, persönliche Daten in Formularübermittlungen. Cloud-URL-Encoder protokollieren jedes Einfügen, behalten sie manchmal zur «Service-Verbesserung» und waren an echten Lecks beteiligt, bei denen eingefügte Authentifizierungstoken von Angreifern extrahiert wurden, die die Protokolle überwachen. Ein browserbasierter Encoder hat null Exposition: Die URL verlässt niemals Ihren Computer.

Browserbasierte Kodierung funktioniert auch offline, sobald die Seite geladen ist, nützlich für die Kodierung von URLs in Flugzeugen, in sicheren Umgebungen ohne Internetzugang oder überall dort, wo Sie keine authentifizierungstragenden URLs in einen Drittanbieterdienst einfügen können oder sollten.