URL-koodaus ja -purku selitettynä kehittäjille
Kirjoita URL-osoitteeseen välilyönti, kyrillinen sana tai &-merkki, joka kuuluu dataasi eikä itse osoitteeseen, ja jotain on annettava periksi. Verkko takaa turvallisen kuljetuksen vain pienelle, ennustettavalle joukolle ASCII-merkkejä. Kaikki muu on käärittävä muotoon, josta reitittimet, palvelimet ja selaimet ovat kaikki yhtä mieltä. Tämä muoto on prosenttikoodaus, yleisemmin URL-koodaus, ja tämä sivu antaa sinun muuntaa tekstiä kumpaankin suuntaan suoraan selaimessasi.
Mitä prosenttikoodaus todella on
Sääntö on mekaaninen ja helppo seurata. Jokainen merkki, joka ei voi esiintyä sellaisenaan, korvataan %-merkillä, jota seuraa kaksi heksadesimaalinumeroa, jotka kirjoittavat auki kyseisen merkin tavuarvon. Välilyönnistä tulee %20. Plusmerkistä tulee %2B. Ristikkomerkistä tulee %23. Kun merkki kartoittuu useiksi tavuiksi, kuten useimmat ei-ASCII-merkit tekevät UTF-8:ssa, saat yksinkertaisesti useita kolmikoita peräkkäin: euromerkistä tulee %E2%82%AC. Purku kääntää prosessin, lukien kunkin kolmikon takaisin alkuperäiseksi tavuksi.
Tämä käytäntö on määritelty URI-määrittelyssä (RFC 3986), ja se on tarkoituksella tylsä. Tylsyys on juuri pointti. Jokainen kunnolla toimiva HTTP-asiakas ja -palvelin maailmassa toteuttaa samat säännöt, joten yhdessä paikassa oikein koodattu linkki saapuu ehjänä joka muualle.
Miksi sen on pakko olla olemassa
URL:t kuljettavat kahdenlaisia merkkejä, joilla on hyvin erilaiset tehtävät. Varatut merkit, kuten /, ?, #, &, = ja :, ovat rakenteellisia. Ne kertovat jäsentäjälle, mistä polku päättyy ja kyselymerkkijono alkaa, tai mistä yksi parametri loppuu ja seuraava alkaa. Jos varsinainen datasi sisältää jonkin näistä symboleista, se on koodattava, jotta jäsentäjä ei erehdy pitämään sitä välimerkkinä. Tilausviite kuten A&B/2024 raakana kyselymerkkijonoon pudotettuna tulkittaisiin väärin kahdeksi parametriksi ja polkusegmentiksi.
Sitten on olemassa epäturvalliset ja ei-ASCII-merkit: välilyönnit, lainausmerkit, kulmasulkeet, aksentilliset kirjaimet, emojit, mikä tahansa ASCII-alueen ulkopuolella. Näillä ei ole asiaa esiintyä sellaisenaan URL:ssa, joko koska ne silpoutuvat siirron aikana tai koska niillä ei ole määriteltyä esitystapaa. Niiden koodaaminen pitää linkit siisteinä ja ennustettavina sen sijaan, että lopputulos jäisi sattuman varaan.
Missä sitä kohtaa oikeassa työssä
Kyselymerkkijonot ovat klassinen tapaus. Jokainen arvo, jonka liität kohtaan ?key=..., tulisi koodata, jotta käyttäjän syöte ei voi rikkoa rakennetta. Sama pätee HTML-lomakkeiden lähetyksiin, jotka lähetetään muodossa application/x-www-form-urlencoded, jossa selain koodaa kenttäarvot automaattisesti (ja historiallisen käytännön mukaan muuttaa välilyönnit +-merkeiksi %20:n sijaan). Törmäät siihen myös rakentaessasi linkkejä, jotka osoittavat sivuille, joilla on ei-latinalaisia otsikoita, käsin rakentaessasi API-pyyntöjä, välittäessäsi uudelleenohjauskohteita parametreina, ja debugatessasi miksi pyyntö, joka näyttää kunnossa olevalta osoitepalkissa, saapuu palvelimelle vääristyneenä.
encodeURI vastaan encodeURIComponent
JavaScript tarjoaa kaksi koodainta, ja väärän valitseminen on yleinen bugi. Ero liittyy laajuuteen. encodeURIComponent on tarkoitettu yhdelle datanpalalle, kuten yhdelle kyselyarvolle. Se koodaa lähes kaiken, mukaan lukien varatut merkit /, ?, :, @, &, =, + ja #. Se on juuri sitä, mitä haluat, kun datalla on lupa sisältää nuo symbolit tavallisena tekstinä.
encodeURI on tarkoitettu koko osoitteelle, jonka aiot pitää toimivana. Se jättää rakenteelliset merkit rauhaan, joten kauttaviivat, kaksoispisteet ja kysymysmerkit, jotka pitävät URL:n koossa, säilyvät. Käytä sitä, kun sinulla on kokonainen URL ja haluat vain siistiä välilyönnit tai ei-ASCII-merkit; tartu encodeURIComponent-työkaluun aina, kun lisäät arvon suurempaan URL:iin. Yksinkertainen nyrkkisääntö: koodaa koko linkki encodeURI-funktiolla, koodaa osat, jotka tunget sisään encodeURIComponent-funktiolla.
Kaikki pysyy koneellasi
Tämä työkalu toimii kokonaan selaimessasi. Liittämäsi teksti koodataan tai puretaan paikallisesti samoilla vakiorutiineilla eikä koskaan matkusta palvelimelle, mikä tekee siitä turvallisen tokeneille, allekirjoitetuille parametreille tai millekään muulle, mitä mieluummin et lähettäisi verkon yli. Jos työskentelet muiden tekstimuunnosten kanssa, Base64-muunnin istuu aivan vieressä, ja voit selata koko joukkoa kehittäjätyökaluja lisää arkisia apuvälineitä varten.
Usein kysytyt kysymykset
Mitä %20 tarkoittaa URL:ssa?
Se on koodattu välilyönti. Välilyöntimerkki ei ole sallittu sellaisenaan URL:ssa, joten se korvataan prosenttimerkillä ja heksadesimaaliarvolla 20, joka on välilyönnin tavuarvo.
Miksi joskus näen plusmerkin %20:n sijaan?
Tyyppiä application/x-www-form-urlencoded oleva HTML-lomakedata koodaa välilyönnit plusmerkiksi historiallisen käytännön mukaan. Tavallisessa polussa tai kyselyssä välilyönti koodataan muotoon %20. Molemmat puretaan takaisin välilyönniksi omassa asiayhteydessään.
Milloin minun pitäisi käyttää encodeURIComponentia encodeURIn sijaan?
Käytä encodeURIComponentia yhdelle arvolle, jonka lisäät URL:iin, kuten kyselyparametrille, koska se koodaa myös varatut merkit. Käytä encodeURIa kokonaiselle osoitteelle, kun haluat säilyttää kauttaviivat, kaksoispisteet ja kysymysmerkit, jotka pitävät sen koossa.
Muuttaako URL-koodaus datani merkitystä?
Ei. Koodaus on täysin palautettavissa. Tuloksen purkaminen antaa takaisin täsmälleen alkuperäisen tekstin, tavu tavulta, kunhan sama merkistö on käytössä molemmissa päissä.
Miten ei-ASCII-merkkejä, kuten aksentteja tai emojeja, käsitellään?
Ne muutetaan ensin UTF-8-tavuiksi, ja sitten jokaisesta tavusta tulee oma prosenttikolmikkonsa. Yksi aksentillinen kirjain tai emoji voi siis laajentua useiksi kolmikoiksi koodatussa tulosteessa.
Lähetetäänkö tekstini palvelimelle, kun käytän tätä työkalua?
Ei. Koodaus ja purku tapahtuvat kokonaan selaimessasi. Mitään liittämääsi ei ladata, joten sitä on turvallista käyttää yksityisten tai arkaluontoisten merkkijonojen kanssa.