URL-enkodering en -dekodering, verduidelik vir ontwikkelaars
Tik 'n spasie in 'n URL, of 'n Cyrilliese woord, of 'n en-teken wat aan jou data behoort eerder as aan die adres self, en iets moet plek maak. Die web waarborg net veilige vervoer vir 'n klein, voorspelbare stel ASCII-karakters. Alles anders moet toegedraai word in 'n formaat wat roeteerders, bedieners en blaaiers almal saamstem oor. Daardie formaat is persent-enkodering, meer algemeen URL-enkodering genoem, en hierdie bladsy laat jou teks in beide rigtings direk in jou blaaier omskakel.
Wat persent-enkodering werklik is
Die reël is meganies en maklik om te volg. Enige karakter wat nie letterlik kan verskyn nie, word vervang deur 'n %-teken gevolg deur twee heksadesimale syfers wat die grepe-waarde van daardie karakter uitspel. 'n Spasie word %20. 'n Plusteken word %2B. Die hekiesimbool word %23. Wanneer 'n karakter na verskeie grepe omskakel, soos die meeste nie-ASCII-teks onder UTF-8 doen, kry jy eenvoudig verskeie drietalle op 'n ry: die euroteken word %E2%82%AC. Dekodering keer die proses om, en lees elke drietal terug in sy oorspronklike greep.
Hierdie konvensie word gedefinieer in die URI-spesifikasie (RFC 3986) en dit is doelbewus vervelig. Vervelig is die punt. Elke goed-gedraagde HTTP-kliënt en -bediener op die planeet implementeer dieselfde reëls, sodat 'n skakel wat korrek op een plek geënkodeer is, ongeskonde orals anders aankom.
Waarom dit moet bestaan
URL's dra twee soorte karakters met heel verskillende take. Gereserveerde karakters soos /, ?, #, &, = en : is struktureel. Hulle vertel 'n ontleder waar die pad eindig en die navraagstring begin, of waar een parameter ophou en die volgende begin. As jou werklike data een van daardie simbole bevat, moet dit geënkodeer word sodat die ontleder dit nie met leestekens verwar nie. 'n Bestellingverwysing soos A&B/2024 wat rou in 'n navraagstring geplaas word, sou verkeerdelik as twee parameters en 'n padsegment gelees word.
Dan is daar onveilige en nie-ASCII-karakters: spasies, aanhalingstekens, hoekhakies, geaksentueerde letters, emoji's, enigiets buite die gewone ASCII-omvang. Hierdie het geen besigheid om letterlik in 'n URL te verskyn nie, óf omdat hulle in vervoer verminak word óf omdat hulle geen gedefinieerde voorstelling het nie. Om hulle te enkodeer hou skakels skoon en voorspelbaar in plaas daarvan om die uitkoms aan kans oor te laat.
Waar dit in werklike werk voorkom
Navraagstringe is die klassieke geval. Elke waarde wat jy by ?key=... aanheg, moet geënkodeer word sodat gebruikersinvoer nie die struktuur kan breek nie. Dieselfde geld vir HTML-vormindienings gestuur as application/x-www-form-urlencoded, waar die blaaier veldwaardes outomaties enkodeer (en, volgens historiese konvensie, spasies in + verander eerder as %20). Jy sal dit ook teëkom wanneer jy skakels bou wat na bladsye met nie-Latynse titels wys, wanneer jy API-versoeke met die hand konstrueer, wanneer jy herleidingsteikens as parameters deurgee, en wanneer jy ontfout waarom 'n versoek wat goed lyk in die adresbalk verwronge by die bediener aankom.
encodeURI teenoor encodeURIComponent
JavaScript verskeep twee enkodeerders, en om die verkeerde een te kies is 'n algemene fout. Die verskil gaan oor omvang. encodeURIComponent is vir 'n enkele stuk data, soos een navraagwaarde. Dit enkodeer byna alles, insluitend die gereserveerde karakters /, ?, :, @, &, =, + en #. Dit is presies wat jy wil hê wanneer die data toegelaat word om daardie simbole as gewone teks te bevat.
encodeURI is vir 'n hele adres wat jy wil laat werk. Dit los die strukturele karakters uit, sodat die skuinsstrepe, dubbelpunte en vraagtekens wat die URL bymekaarhou, oorleef. Gebruik dit wanneer jy 'n volledige URL het en net spasies of nie-ASCII-karakters wil opruim; gryp na encodeURIComponent wanneer jy ook al 'n waarde in 'n groter URL invoeg. 'n Eenvoudige vuistreël: enkodeer die hele skakel met encodeURI, enkodeer die dele wat jy inprop met encodeURIComponent.
Alles bly op jou masjien
Hierdie instrument loop heeltemal binne jou blaaier. Teks wat jy plak, word plaaslik geënkodeer of gedekodeer met dieselfde standaardroetines en beweeg nooit na 'n bediener nie, wat dit veilig maak vir tokens, ondertekende parameters of enigiets anders wat jy liewer nie oor die draad wil stuur nie. As jy met ander tekstransformasies werk, sit die Base64-omskakelaar reg langsaan, en jy kan die volle stel ontwikkelaarinstrumente deurblaai vir meer alledaagse hulpmiddels.
Gereelde vrae
Wat beteken %20 in 'n URL?
Dit is 'n geënkodeerde spasie. Die spasiekarakter word nie letterlik in 'n URL toegelaat nie, sodat dit vervang word deur 'n persentteken en die heksadesimale waarde 20, wat die grepe-waarde van 'n spasie is.
Waarom sien ek soms 'n plusteken in plaas van %20?
HTML-vormdata van tipe application/x-www-form-urlencoded enkodeer spasies as 'n plusteken volgens historiese konvensie. In 'n normale pad of navraag word 'n spasie as %20 geënkodeer. Albei dekodeer terug na 'n spasie in hul regte konteks.
Wanneer moet ek encodeURIComponent gebruik in plaas van encodeURI?
Gebruik encodeURIComponent vir 'n enkele waarde wat jy in 'n URL invoeg, soos 'n navraagparameter, want dit enkodeer gereserveerde karakters ook. Gebruik encodeURI vir 'n volledige adres wanneer jy die skuinsstrepe, dubbelpunte en vraagtekens wil behou wat dit bymekaarhou.
Verander URL-enkodering die betekenis van my data?
Nee. Enkodering is volkome omkeerbaar. Om die resultaat te dekodeer, gee presies die oorspronklike teks terug, greep vir greep, solank dieselfde karakterstel aan beide kante gebruik word.
Hoe word nie-ASCII-karakters soos aksente of emoji's hanteer?
Hulle word eers na UTF-8-grepe omgeskakel, en dan word elke greep sy eie persent-drietal. 'n Enkele geaksentueerde letter of emoji kan dus uitbrei tot verskeie drietalle in die geënkodeerde uitvoer.
Word my teks na 'n bediener gestuur wanneer ek hierdie instrument gebruik?
Nee. Enkodering en dekodering vind heeltemal binne jou blaaier plaas. Niks wat jy plak word opgelaai nie, sodat dit veilig is om met privaat of sensitiewe stringe te gebruik.