Ein Wort wie "Straße" oder "München" lässt sich nicht unverändert in eine URL schreiben: Umlaute, das ß und Leerzeichen gehören nicht zum sicheren Zeichensatz und müssen als Percent-Encoding geschrieben werden.
Warum das ß eine Sonderrolle spielt
Jeder Umlaut wird zuerst als UTF-8 codiert (2 Bytes für ä, ö, ü, ß) und dann byteweise als %XX geschrieben — aus "Straße" wird Stra%C3%9Fe. Anders als bei IDN-Domains, wo ü.de intern in Punycode umgewandelt wird, betrifft das Percent-Encoding hier den Pfad und die Query-Parameter, nicht den Domainnamen selbst — zwei komplett unterschiedliche Mechanismen für ähnlich aussehende Zeichen.
encodeURIComponent vs. encodeURI
encodeURIComponent codiert fast alle Zeichen mit struktureller Bedeutung — &, ?, =, / — und eignet sich deshalb nur für einen einzelnen Parameterwert, etwa einen Suchbegriff, der in ?q= eingesetzt wird. encodeURI lässt diese Strukturzeichen unangetastet und ist für eine bereits zusammengesetzte, vollständige URL gedacht.
Ein typischer Fehler bei langen Parameterwerten
Wird die gesamte Query-Zeichenkette statt jedes Werts einzeln mit encodeURIComponent codiert, verwandeln sich auch die trennenden Zeichen & und = in %26 und %3D — der Server erhält dann einen einzigen unlesbaren Parameter statt mehrerer getrennter Werte, etwa bei langen zusammengesetzten Suchbegriffen mit mehreren Wörtern.
Wann man das braucht
- Einen Suchbegriff oder Produktnamen mit Umlauten als Parameterwert einsetzen.
- Links mit dynamischen Werten erstellen (Suchanfragen, IDs).
- Diagnose: eine URL decodieren, um zu sehen, welche Daten tatsächlich codiert sind.
Grenzfall: doppelte Codierung
Wird eine bereits codierte Zeichenkette erneut codiert, wird aus dem Prozentzeichen selbst %25 — das Ergebnis ist doppelt codierter, unlesbarer Text (%C3%9F wird zu %25C3%259F). Das passiert häufig, wenn ein Framework die URL bereits automatisch codiert und zusätzlich manuell encodeURIComponent auf einen schon codierten Wert angewendet wird.