Base64-koodaus selitettynä: Milloin ja miksi käyttää

Olet todennäköisesti nähnyt Base64:n aiemmin — niitä pitkiä, outoja merkkijonoja kuten SGVsbG8gV29ybGQ=. Ne esiintyvät sähköposteissa, data-URI:issa, API-kuormissa ja JWT:issä. Mutta mikä Base64 oikeastaan on, ja milloin sitä pitäisi käyttää? Selvitetään asia.

Mitä Base64 tekee (selkokielellä)

Base64 ottaa mitä tahansa dataa — tekstiä, kuvia, tiedostoja, ihan mitä vaan — ja muuntaa sen merkkijonoksi käyttäen vain 64 "turvallista" ASCII-merkkiä: A-Z, a-z, 0-9, + ja /. Lopun = on täytettä.

Miksi? Koska kaikki järjestelmät eivät käsittele raakaa binääridataa. Sähköposti suunniteltiin tekstille. JSON ei tue binääriä. URL-parametrit eivät voi sisältää mielivaltaisia tavuja. Base64 on silta, joka mahdollistaa binääridatan kuljetuksen pelkkien tekstikanavien läpi.

Miten se toimii konepellin alla

Algoritmi on yllättävän yksinkertainen. Se ottaa 3 tavua syötettä (24 bittiä), jakaa ne 4 ryhmään à 6 bittiä ja yhdistää jokaisen ryhmän yhteen 64 merkistä. Tässä nopea esimerkki:

Syöte: Hi (2 tavua: 72, 105)

Binääri: 01001000 01101001 + täytenollia

Jaettu 6-bitin ryhmiin: 010010 000110 100100

Yhdistetty Base64-aakkostoon: SGk=

Matematiikka tarkoittaa, että Base64-tuloste on aina noin 33% suurempi kuin syöte. Se on kompromissi turvallisen tekstisiirron vuoksi. RFC 4648 -spesifikaatio määrittelee tarkan algoritmin, jos haluat yksityiskohdat.

Milloin sinun pitäisi käyttää Base64:ää

Pienten kuvien upottaminen HTML/CSS:ään: Sen sijaan että selain hakisi erillisen tiedoston, voit upottaa pienen kuvakkeen suoraan: . Tämä säästää yhden HTTP-pyynnön. Loistava alle 2-3KB:n kuvakkeille.

Binääridatan lähettäminen JSON-API:issa: JSON ei voi tallentaa raakoja tavuja. Pitääkö ladata tiedosto JSON-API:n kautta? Koodaa se Base64:llä:

Sähköpostiliitteet: Tähän Base64 kirjaimellisesti suunniteltiin. MIME-koodaus käyttää Base64:ää binääriliitteiden upottamiseen tekstipohjaisiin sähköpostiviesteihin.

JWT:t ja todennustokenit: JSON Web Tokenit käyttävät Base64URL-koodausta (URL-turvallinen muunnos) otsikko- ja kuormaosioissaan.

Binääridatan tallentaminen tekstikenttiin: Tietokantojen tekstisarakkeet, ympäristömuuttujat, konfiguraatiotiedostot — Base64 mahdollistaa binääridatan sijoittamisen minne tahansa, mihin teksti sopii.

Milloin sinun EI pitäisi käyttää Base64:ää

• Suuret tiedostot. 33%:n koon kasvu tuntuu todella suurilta tiedostoilta. 10MB:n kuva kasvaa 13,3MB:hen Base64:nä. Käytä sen sijaan multipart-form-latausta.
• Turvallisuus. Base64 ei ole salausta. Se on trivaalisti palautettavissa. Älä koskaan käytä sitä salasanojen tai arkaluonteisen datan "piilottamiseen". Kuka tahansa voi dekoodata cGFzc3dvcmQ= takaisin muotoon password sekunneissa.
• Suuret upotetut kuvat. Yli ~5KB:n kuville erillinen tiedosto kunnollisella HTTP-välimuistilla toimii paremmin kuin Base64-data-URI.

URL-turvallinen muunnos

Standardi Base64 käyttää + ja / -merkkejä, joilla on erityismerkitys URL:issa. Base64URL-muunnos korvaa ne - ja _ -merkeillä. Näet tämän JWT:issä ja kaikkialla missä Base64-dataa esiintyy URL:issa.

Nopeat koodiesimerkit

Näin koodaat ja dekoodaat Base64:ää yleisimmillä kielillä:

Huomaa, että JavaScriptin selain-funktio btoa() toimii vain ASCII-merkkijonoilla. Jos tarvitset koodata Unicode-tekstiä, sinun täytyy käyttää ensin TextEncoder-luokkaa — tämä kompastuttaa monia kehittäjiä.

Yleiset virheet Base64:n kanssa

Tässä ovat sudenkuopat, joihin näen kehittäjien lankeavat useimmin:

1. Oletus että Base64 on salausta. En voi korostaa tätä tarpeeksi. Olen nähnyt tuotantokoodikantoja, jotka Base64-koodaavat API-avaimia ja salasanoja, luullen niiden olevan "suojattuja". Kuka tahansa selaimen konsolilla voi dekoodata ne välittömästi. Jos sinun täytyy suojata dataa, käytä oikeaa salausta (AES, RSA) tai hajautusta (bcrypt, argon2).

2. Täytteen käsittelyn virheet. Jotkin toteutukset poistavat loppuun tulevat =-merkit, mikä voi aiheuttaa dekoodausvirheitä tiukoissa parsereissa. Jos lähetät Base64:ää järjestelmien välillä, sovi sisällytetäänkö täyte vai ei.

3. Standardi Base64:n käyttö URL:issa. + ja / -merkit standardi-Base64:ssä rikkovat URL:t. Käytä aina URL-turvallista muunnosta (Base64URL) kun upotat koodattua dataa kyselyparametreihin tai polkusegmentteihin.

4. Suurten tiedostojen Base64-koodaus JSON-kuormissa. 5MB:n tiedostosta tulee lähes 7MB Base64-koodauksen jälkeen, ja koko merkkijonon täytyy mahtua muistiin. Kaikkeen muutamaa KB:tä suurempaan käytä multipart/form-dataa sen sijaan.

Base64-merkistön pikaopas

Käytännön esimerkki: Fonttien upottaminen CSS:ään

Yksi yleinen Base64:n käyttö, jota et ehkä tule ajatelleeksi, on mukautettujen fonttien upottaminen suoraan CSS-tiedostoihin. Tämä välttää ylimääräisen HTTP-pyynnön fonttitiedostolle:

Tämä tekniikka toimii hyvin pienille kuvakefonteille (alle 10-15KB). Suuremmille fonttitiedostoille on parempi tarjoilla ne erikseen, jotta selain voi välimuistittaa ne itsenäisesti.

Base64 vs muut koodausmenetelmät

Base64 ei ole ainoa tapa esittää binääridataa tekstinä. On useita vaihtoehtoja, ja jokaisella on vahvuutensa. Vertaillaan pääasiallisia.

Heksakoodaus (Base16): Yksinkertaisin lähestymistapa — jokainen tavu muuttuu kahdeksi heksamerkiksi (0-9, A-F). Joten Hi muuttuu muotoon 4869. Se on erittäin yksinkertainen ja ihmisen luettavissa, mutta tuloste on 100% suurempi kuin syöte (kaksinkertainen koko). Heksaa näkee kaikkialla: värikoodit (#FF5733), SHA-hajautukset, MAC-osoitteet ja debug-tulosteet.

Base32: Käyttää 32 merkkiä (A-Z ja 2-7). Tuloste on noin 60% suurempi kuin syöte. Olet todennäköisesti nähnyt sen huomaamattasi — ne 6-numeroiset koodit Google Authenticatorista ja muista TOTP/2FA-sovelluksista käyttävät Base32-koodattuja salaisuuksia taustalla. Se on myös kirjainkoosta riippumaton, mikä tekee siitä loistavan tilanteisiin, joissa käyttäjien täytyy kirjoittaa koodattu data manuaalisesti.

ASCII85 / Base85: Käyttää 85 tulostettavaa ASCII-merkkiä ja tuottaa tulosteen, joka on vain noin 25% suurempi kuin syöte. Se on tehokkaampi kuin Base64. Git käyttää Base85:n muunnosta binääripaikkausformaatissaan (packfiles), ja Adobe PostScript- ja PDF-tiedostot käyttävät ASCII85-koodausta sisäisesti. Haittapuoli? Se käyttää merkkejä kuten {, } ja lainausmerkkejä, jotka voivat aiheuttaa ongelmia JSON:issa, XML:ssä ja URL:issa.

Tässä vertailu saman 100 tavun syötteen koodaamisesta:

Miksi Base64 voittaa useimmissa tapauksissa? Se osuu kultaiseen keskitiehen: kohtuullinen ylimäärä, laajasti tuettu jokaisella kielellä ja alustalla, ja se välttää useimmat erikoismerkit, jotka aiheuttavat ongelmia yleisimmissä formaateissa. Base85 on kompaktimpi mutta vähemmän universaalisti tuettu ja vaikeampi käyttää turvallisesti jäsennellyissä tekstiformaateissa.

Base64 todennusvirroissa

Yksi Base64:n laajimmin levinneistä (ja eniten väärinymmärretyistä) käyttötavoista on HTTP Basic Authentication. Kun lähetät käyttäjänimen ja salasanan Basic Authin kautta, selain yhdistää ne kaksoispisteellä ja Base64-koodaa tuloksen.

Tässä mitä tapahtuu konepellin alla kun kirjaudut käyttäjänimellä admin ja salasanalla secret123:

Palvelin vastaanottaa otsikon, Base64-dekoodaa sen, jakaa kaksoispisteestä ja tarkistaa tunnistetiedot. Yksinkertaista, eikö? Mutta tässä on ratkaiseva asia: tämä EI ole turvallista ilman HTTPS:ää. Tuo Base64-merkkijono on trivaalisti palautettavissa — kuka tahansa pyynnön sieppaava voi dekoodata YWRtaW46c2VjcmV0MTIz ja saada salasanasi alle sekunnissa. RFC 7617 -spesifikaatio Basic Authille varoittaa tästä nimenomaisesti.

Base64 esiintyy myös muissa todennuskonteksteissa. OAuth 2.0:n access-tokenit ja refresh-tokenit ovat usein Base64-koodattuja (vaikka tämä on toteutusyksityiskohta, ei vaatimus). Monet API-avaimet palveluilta kuten AWS, Stripe ja Google Cloud ovat Base64-koodattuja merkkijonoja. Jälleen, koodaus on turvallista siirtoa varten — ei turvallisuutta varten. Lähetä ne aina HTTPS:n yli ja tallenna ne turvallisesti.

Data-URI:t syvemmin

Mainitsimme data-URI:t lyhyesti aiemmin, mutta ne ansaitsevat syvemmän katsauksen. Data-URI mahdollistaa tiedoston sisällön upottamisen suoraan HTML:ään, CSS:ään tai JavaScriptiin — ilman ulkoista HTTP-pyyntöä. Täydellinen syntaksi on:

mediatype on standardi MIME-tyyppi, ;base64-lippu kertoo selaimelle, että data on Base64-koodattua (ilman sitä datan oletetaan olevan URL-koodattua tekstiä), ja on varsinainen sisältö.

Tässä esimerkkejä eri mediatyypeille:

PNG-kuva (yleisin):

Inline SVG (ei tarvetta Base64:lle!):

Huomaa, että SVG:t ovat jo tekstiä, joten voit URL-koodata ne Base64-koodauksen sijaan. Tämä on itse asiassa pienempi, koska ohitat 33%:n ylimäärän. Taitavat kehittäjät käyttävät tätä temppua yksinkertaisille SVG-kuvakkeille.

PDF-dokumentti:

Äänitiedosto:

Selainrajoituksista: vaikka data-URI-spesifikaatio MDN:ssä ei määrittele maksimikokoa, selaimet asettavat omat rajansa. Chrome rajoittaa data-URI:t noin 2MB:iin navigaatiokonteksteissa (kuten iframe:t ja ylätason sivut). Firefox on anteliaampi. CSS-taustakuville ja inline-kuville käytännön raja on käyttäjiesi kärsivällisyys — 500KB:n Base64-merkkijono CSS-tiedostossasi on teknisesti validi, mutta tuhoaa latausajat täysin.

Suorituskykyvaikutus: Kun Base64 haittaa

Puhutaan oikeista numeroista, koska "33% ylimäärää" kuulostaa abstraktilta, kunnes näet vaikutuksen käytännössä.

Kaistanleveyskulut: 50KB:n kuva kasvaa ~67KB:hen Base64-koodauksen jälkeen. Se on 17KB ylimääräistä per kuva. Kerro se sivulla, jolla on 20 inline-kuvaketta, ja lähetät 340KB turhaa dataa. Vertailun vuoksi, se on enemmän kuin useimpien verkkosivujen koko HTML.

Muistin käyttö: Kun Base64-koodaat kuvan ja upotat sen HTML:ään tai CSS:ään, koko koodattu merkkijono täytyy pitää muistissa osana DOM:ia tai tyylitiedostoa. Selain dekoodaa sen sitten takaisin binääriksi, joten hetkellisesti pidät sekä koodattua että dekoodattua versiota. 1MB:n kuvalle se on noin 2,33MB pelkästään koodatulle merkkijonolle, plus 1MB dekoodatulle binäärille — yli 3x alkuperäisen tiedoston koko.

Jäsennysaika: Base64-merkkijonot HTML:n tai CSS:n sisällä täytyy jäsentää osana noita dokumentteja. Suuri data-URI tekee koko CSS-tiedostosta tai HTML-dokumentista hitaamman jäsentää. web.dev:n kuvaoptimointiopas suosittelee, että inline-kuvien tulisi yleisesti olla alle 2-4KB nettosuorituskykyhyödyn saavuttamiseksi.

Välimuistin tehottomuus: Tämä on se, jonka useimmat kehittäjät unohtavat. Kun tarjoilet kuvan erillisenä tiedostona, selain välimuistittaa sen itsenäisesti — seuraavat sivulataukset ohittavat latauksen kokonaan. Mutta kun Base64-koodaat saman kuvan CSS-tiedostosi sisään, siitä tulee osa CSS:ää. Jos muutat mitään muuta CSS:ssä, selain lataa koko tiedoston uudelleen, mukaan lukien Base64-kuvadatan, joka ei muuttunut. Menetät yksityiskohtaisen välimuistituksen.

Tässä karkea vertailukohta:

Nyrkkisääntö: Base64-upota kaikki alle 2-4KB. Tarjoile kaikki muu erillisenä tiedostona. HTTP/2:n ja HTTP/3:n myötä ylimääräisten pyyntöjen kustannus on minimaalinen, joten kynnys on laskenut entisestään vuosien varrella.

Base64 eri ohjelmointikielissä

Käsittelimme JavaScriptin ja Pythonin aiemmin. Näin Base64:ää käsitellään muissa suosituissa kielissä — kukin vain pari riviä:

Huomaa, miten jokaisessa kielessä Base64 on vakiokirjastossa — kolmannen osapuolen paketteja ei tarvita. Se kertoo, kuinka perustavanlaatuinen tämä koodaus on. Huomaa myös, että Rubyssä on strict_encode64 (ei rivinvaihtoja) ja encode64 (lisää rivinvaihdot joka 60. merkki, alkuperäisen MIME-standardin mukaisesti). Useimmat modernit käyttötarkoitukset haluavat strict-version.

Base64:n historia

Base64 ei ilmestynyt tyhjästä. Sen tarina liittyy sähköpostin historiaan, ja sen ymmärtäminen selittää monia suunnittelupäätöksiä.

Internetin alkuaikoina sähköposti (SMTP) suunniteltiin käsittelemään vain 7-bittistä ASCII-tekstiä — 128 merkkiä, ja siinä se. Tämä riitti englanninkieliselle tekstille, mutta oli täysin hyödytön kuvien, dokumenttien tai edes muun kuin englanninkielisen tekstin lähettämiseen. Binääridataa ei yksinkertaisesti voinut lähettää sähköpostilla.

Base64:n ensimmäinen muodollinen spesifikaatio ilmestyi vuonna 1993 RFC 1421:ssä, osana Privacy Enhanced Mail (PEM) -standardia. Ajatus oli suoraviivainen: muuntaa binääridata ASCII:n osajoukoksi, joka selviytyisi mistä tahansa tekstipohjaisesta siirtojärjestelmästä ilman vioittumista.

Sitten tuli RFC 2045 vuonna 1996, joka määritteli MIME:n (Multipurpose Internet Mail Extensions). MIME standardoi sähköpostiliitteiden toiminnan, ja Base64 oli sen ensisijainen koodaus binäärisisällölle. Tämän vuoksi näet edelleen Content-Transfer-Encoding: base64 -otsikoita raakojen sähköpostiviestien joukossa.

Koodausta parannettiin jälleen RFC 4648:ssa (2006), josta tuli lopullinen viite. Tämä RFC esitteli myös URL-turvallisen muunnoksen (Base64URL) ja selvensi reunatapauksia täytteen ympärillä. MDN:n Base64-sanastosivu on hyvä lähtökohta, jos haluat tutustua spesifikaatioon lukematta raakoja RFC:itä.

Kiehtovaa on, että Base64 syntyi rajoituksesta — 7-bittisestä sähköpostista — jota ei enää ole. Moderni SMTP tukee 8-bittistä ja binäärisiirtoa. Silti Base64 on elänyt paljon alkuperäistä tarkoitustaan pidempään, löytäen uuden elämän web-API:issa, JWT:issä, data-URI:issa ja lukemattomissa muissa konteksteissa. Se on yksi niistä teknologioista, joka ratkaisi ongelman niin hyvin, että ihmiset jatkavat uusien ongelmien löytämistä sille ratkaistavaksi.

Kokeile itse

Haluatko nähdä Base64:n toiminnassa? Liitä mikä tahansa teksti tai tiedosto Base64 Encoder -työkaluumme nähdäksesi koodatun tulosteen välittömästi. Tarvitsetko dekoodata jotain? Base64 Decoder hoitaa sen. Ja jos työskentelet Base64-koodattujen kuvien kanssa, Base64 to Image -työkalumme antaa sinun esikatsella niitä suoraan selaimessa.