URL kodirnik / dekodirnik na spletu

Kaj je to orodje?

URL kodiranje (odstotkovno kodiranje) nadomesti znake, ki v URL-jih niso dovoljeni, z znakom % in njihovo bajtno vrednostjo v šestnajstiškem zapisu — presledek postane %20, 你 pa postane %E4%BD%A0. Brez tega bi znaki, kot so presledki, &, ? in besedilo, ki ni ASCII, pokvarili strukturo URL-ja ali bi jih strežnik napačno razumel.

Obstajata dve pogosti potrebi in to orodje podpira obe: kodiranje vrednosti, ki gre v parameter poizvedbe (način za komponente — kodira tudi / ? & =), in kodiranje celega URL-ja ob ohranitvi njegove strukture (način za celoten URL — pusti :// ? & nedotaknjeno).

Ena zgodovinska posebnost, ki jo velja poznati: presledek je pravilno %20 po standardu URL (RFC 3986), a so HTML obrazci tradicionalno kodirali presledek kot znak plus — zato se v praksi pojavljata tako q=hello%20world kot q=hello+world, in zato je pri dekodiranju podatkov obrazca včasih treba + obravnavati posebej.

Zakaj ga uporabiti?

• Varno sestavljanje niza poizvedbe — uporabniški vnos z znaki &, = ali presledki ne bo pokvaril tvojega URL-ja.
• Dekodiraj dolge kodirane URL-je iz dnevnikov, analitike ali verig preusmeritev, da vidiš, kaj dejansko pravijo.
• Pravilna obravnava UTF-8 za kitajščino, emojije in drugo besedilo, ki ni ASCII.
• Dva načina, da nehote ne kodiraš : in / celotnega URL-ja.
• Brezplačno, takojšnje, brez nalaganja.

Kako ga uporabljati

1. Prilepi svoje besedilo ali URL v vnosno polje.
2. Izberi način: "Komponenta" za vrednosti, ki gredo v parametre poizvedbe, "Celoten URL" za cele URL-je.
3. Klikni "Kodiraj" ali "Dekodiraj".
4. Kopiraj rezultat.

Primer

Vnos

https://example.com/search?q=hello world & 你好

Rezultat

Način za komponente: https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dhello%20world%20%26%20%E4%BD%A0%E5%A5%BD
Način za celoten URL:  https://example.com/search?q=hello%20world%20&%20%E4%BD%A0%E5%A5%BD

Način za komponente kodira tudi strukturne znake; način za celoten URL jih ohrani.

Pogosti primeri uporabe

• Sestavljanje URL-ja za deljenje, kjer iskalni izraz ali vrednost filtra prihaja iz uporabniškega vnosa in lahko vsebuje presledke, & ali druge posebne znake.
• Dekodiranje dolgega sledilnega ali preusmeritvenega URL-ja iz e-pošte ali oglaševalske kampanje, da vidiš dejanski cilj in parametre pred klikom nanj.
• Odpravljanje napak, zakaj strežnik parametra poizvedbe ne bere pravilno — pogosto je krivec rezerviran znak, ki bi moral biti kodiran, pa ni bil.
• Priprava neangleške (kitajske, japonske, arabske itd.) vrednosti za uporabo v nizu poizvedbe URL-ja.

encodeURIComponent proti encodeURI v praksi

Ta se neposredno ujemata z dvema načinoma tega orodja in ustrezata resničnima JavaScript funkcijama, ki jih razvijalci že poznajo: encodeURIComponent (način za komponente) kodira vse razen majhne skupine nerezerviranih znakov, kar naredi varno za katerokoli posamezno vrednost, ki se vstavlja v URL — to uporabiš za vrednost parametra poizvedbe, segment poti ali vrednost sidra (hash). encodeURI (način za celoten URL) pusti strukturne znake URL-ja (:, /, ?, #, &, =) nedotaknjene, ker predpostavlja, da kodiraš cel, že strukturiran URL, ne surovo vrednost — uporaba na eni sami parametrski vrednosti ne bi kodirala znakov & ali =, ki jih ta vrednost lahko vsebuje, kar je najpogostejša napaka pri izbiri napačnega načina.

Rezervirani proti nerezerviranim znakom

Specifikacija URL (RFC 3986) deli znake v dve skupini: nerezervirani znaki (črke, števke, - _ . ~) so vedno varni in se nikoli ne kodirajo, medtem ko imajo rezervirani znaki (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) poseben pomen v strukturi URL-ja in jih je treba kodirati le, kadar se pojavijo kot dobesedni podatek in ne kot strukturno ločilo. To je natanko razlog, zakaj obstajata oba načina — način za komponente obravnava rezervirane znake kot podatek, ki ga je treba zaščititi, način za celoten URL pa jih obravnava kot strukturo, ki jo je treba ohraniti. Razumevanje te razlike je bolj koristno kot pomnjenje, kdaj uporabiti kateri način, saj pojasni, zakaj je isti znak (kot &) včasih kodiran, včasih pa ne, odvisno od vloge, ki jo ima v konkretnem URL-ju.

Pogosta vprašanja