Polskie znaki diakrytyczne — ą ć ę ł ń ó ś ź ż — nie należą do bezpiecznego zestawu znaków w adresach URL, więc słowo takie jak "łódź" albo "źdźbło" trzeba przed wstawieniem do linku zamienić na percent-encoding.
Dlaczego "łódź" robi się dużo dłuższe po zakodowaniu
Każdy polski znak diakrytyczny jest najpierw kodowany jako UTF-8 (2 bajty), a potem każdy bajt zapisywany jako %XX — ł zamienia się w %C5%82. Krótkie słowo "łódź" po zakodowaniu zajmuje ponad 20 znaków zamiast czterech, co widać choćby w parametrach wyszukiwania na Allegro, gdzie zapytanie z polskimi znakami tworzy znacznie dłuższy adres niż jego angielski odpowiednik.
encodeURIComponent kontra encodeURI
encodeURIComponent koduje niemal wszystkie znaki o znaczeniu strukturalnym — &, ?, =, / — dlatego nadaje się do pojedynczej wartości parametru, np. frazy wyszukiwania wstawianej do ?q=. encodeURI pozostawia te znaki strukturalne nietknięte, bo służy do kodowania całego, już złożonego adresu URL.
Częsty błąd przy budowaniu linków
Jeśli zakodujemy całą część zapytania naraz funkcją encodeURIComponent, znaki & i = oddzielające parametry również zamienią się w %26 i %3D — serwer dostanie jeden nieczytelny parametr zamiast kilku odrębnych wartości. Każdą wartość trzeba kodować osobno.
Kiedy się to przydaje
- Wstawianie frazy wyszukiwania lub nazwy produktu z polskimi znakami do parametru.
- Tworzenie linków z dynamicznymi wartościami (wyszukiwania, identyfikatory).
- Diagnostyka: dekodowanie adresu URL, by zobaczyć, jakie dane są w nim faktycznie zakodowane.
Przypadek szczególny: podwójne kodowanie
Jeśli już zakodowany ciąg znaków zostanie zakodowany po raz drugi, sam znak % zamieni się w %25, a wynik stanie się nieczytelnym, podwójnie zakodowanym ciągiem (%C5%82 zmienia się w %25C5%2582). Zdarza się to, gdy framework już automatycznie koduje adres URL, a deweloper dodatkowo wywołuje encodeURIComponent ręcznie na wartości, która była już zakodowana.