Mikä on Base64?
Base64 kirjoittaa tavut uudelleen kuudellakymmenelläneljällä luettavalla merkillä, jotta data selviää kanavasta, joka on rakennettu tekstille: sähköpostin runko, JSON-merkkijono, XML-attribuutti, URL. Jokainen kolme tavua muuttuu neljäksi merkiksi, mistä nimi tulee — aakkostossa on kuusikymmentäneljä symbolia ja jokainen kantaa tasan kuusi bittiä.
Se on siirtokoodaus, ei turvatoimi eikä pakkausvaihe. Tulos on noin kolmanneksen suurempi kuin syöte, ja kuka tahansa, jolla on merkkijono, voi kääntää sen suoraan takaisin. Jos halutaan tietää, onko data muutettu, tarvitaan tiivisteen (Tiivistegeneraattori); jos halutaan sen pysyvän salaisena, tarvitaan salauksen. Base64 ei tee kumpaakaan.
Yksi luku muistettavaksi: kolme syötetavua muuttuu neljäksi tulosmerkiksi. Kaikki muu tällä sivulla seuraa siitä. Neljä merkkiä kantaa kaksikymmentäneljä bittiä, ja kaksikymmentäneljä bittiä on tasan kolme tavua, joten dataa ei koskaan menetetä eikä keksitä — paitsi aivan lopussa, jossa syöte ei välttämättä täytä viimeistä kolmen ryhmää.
Viisi aakkostoa, joita tämä sivu voi käyttää
Kaksi ensimmäistä riviä ovat standardeja ja kolme viimeistä Unixin ympärille kehittyneitä konventioita. Kaikki viisi kantavat samat kuusi bittiä merkkiä kohden ja eroavat vain siinä, mitkä kuusikymmentäneljä merkkiä kantavat; sama data muuttuu siis viidellä eri merkkijonolla. Merkkijonon sisällä ei ole mitään, mikä kertoisi, mikä aakkosto tuotti sen, minkä vuoksi aakkostovalitsin on oletuksena standardi ja URL-turvallisen valintaruudun pikakuvake on toinen rivi.
Miten sivu valitsee ehdokkaan: valitsin on oletus molempiin suuntiin. Dekoodattaessa oikealla oleva paneeli lukee myös merkkijonon itsensä — - ja _ voivat tulla vain URL-turvallisesta aakkostosta, + tai / vain standardista, ja alun / tai . viittaa kahteen Unix-aakkostoon. Jokainen aakkosto, joka voi lukea nykyisen syötteen, luetellaan siellä perusteluineen, miksi se on tai ei ole ehdokas.
Rivinvaihto: 76 ja 64 merkkiä
MIME vaati Base64:n, joka mahtuu sähköpostiin ilman, että mikään rivi kasvaa kohtuuttoman pitkäksi, ja päätyi 76 merkkiin riviä kohden, joita erottaa CRLF. PEM-tiedostot, jotka kääräisevät varmenteita ja avaimia, käyttävät 64:ää. Rivinvaihdot eivät ole osa dataa: dekooderi poistaa ne ja liittää rivit takaisin yhteen ennen mitään muuta, joten kääritty ja kääräisemätön merkkijono dekoodautuvat täsmälleen samoiksi tavuiksi. Jokainen rivi paitsi viimeinen sisältää kokonaisen määrän neljän merkin ryhmiä, ja se tekee takaisin liittämisestä turvallista.
Tämä sivu jättää tulosteen yhdelle riville, ellet valitse leveyttä, ja dekooderi hyväksyy syötteen rivinvaihtojen kanssa tai ilman. Tämä sivu kirjoittaa tavalliset rivinsyötteet, mitä tekstiruutu pystyy pitämään; MIME-sähköpostin runkot käyttävät perinteisesti vaununpalautuksen jokaisen rivinsyötteen edessä, ja jokainen käytössä oleva dekooderi hyväksyy molemmat.
Täyte ja miksi se voidaan jättää pois
Kun syöte ei ole kolmen tavun monikerta, viimeinen neljän merkin ryhmä on epätäydellinen, ja yksi tai kaksi =-merkkiä täydentää sen. Ne eivät kanna lainkaan dataa: ne kertovat vain, kuinka monta neljästä merkistä on todellisia. Dekooderi voi päätellä sen pituudesta, ja siksi URL-turvallinen Base64 jättää täytteen perinteisesti pois — = on hankala URL-osoitteessa tai tiedostonimessä, ja jotkin järjestelmät koodaavat sen prosenttimerkinnäksi.
Asetusrivin valintaruutu säilyttää täytteen, kun URL-turvallinen aakkosto on valittu. Mikään muu ei muutu; datan kantavat merkit ovat molemmilla tavoilla samat.
Yleisiä väärinkäsityksiä
- "Base64 piilottaa datan." Ei piilota. Se on korvaus ilman avainta, ja koko pointti on, että kuka tahansa lukija voi kumota sen. Salasanan tai tunnisteen kääriminen Base64:ään ei muuta sitä, kuka sen voi lukea.
- "Base64 pakkaa." Päinvastoin: jokainen kolme syötetavua muuttuu neljäksi merkiksi, joten teksti on kolmanneksen suurempi kuin data, jonka se kantaa.
- "Rivinvaihdot ovat osa arvoa." Ne ovat esitystapaa. Niiden lisääminen tai poistaminen ei koskaan muuta takaisin tulevia tavuja.
- "URL-turvallinen tarkoittaa eri koodausta." Se on sama koodaus kahden merkin vaihdettuna:
+ muuttuu -:ksi ja / muuttuu _:ksi, joten merkkijono voi olla URL-polussa tai kyselyarvossa ilman escapointia.
- "Merkkijono, joka dekoodautuu, on oltava kelvollinen Base64." Mikä tahansa aakkosmerkkien jono on kelvollinen Base64, koska jokainen kuuden bitin arvojen yhdistelmä on kelvollinen tavujono. Merkkijono osoittautuu vääräksi vasta seuraavassa vaiheessa, kun tavut tarkistetaan formaattia vasten, jonka oli tarkoitus.
- "Täyte kertoo, mitä aakkostoa käytettiin." Ei kerro, eivätkä merkitkään useimmiten: standardi- ja URL-turvallinen aakkosto ovat samaa mieltä 64 symbolista 62:sta, joten lyhyt merkkijono lukeutuu usein molemmin tavoin.
Usein esitettyjä kysymyksiä
Miksi Base64-merkkijono päättyy joskus yhteen =-merkkiin ja joskus kahteen? Yksi tarkoittaa, että viimeinen ryhmä kantaa kolme todellista merkkiä, eli kaksi syötetavua; kaksi tarkoittaa, että se kantaa kaksi, eli yhden syötetavun. Ei =-merkkiä tarkoittaa, että syötteen pituus oli kolmen monikerta.
Voiko Base64 esittää mielivaltaisia binääritiedostoja? Kyllä, ja se on sen pääkäyttö. Tämä sivu käsittelee syötteen UTF-8-tekstinä; erillinen Tiedosto Base64:ksi -työkalu lukee raakoja tavuja, kun halutaan koodata muuta kuin tekstiä.
Mitä aakkostoa API:ssa pitäisi käyttää? Sitä, minkä vastaanottava pää dokumentoi. Jos siinä lukee URL-turvallinen, käytä sitä; jos siinä ei lue mitään ja arvo kulkee URL-osoitteen sisällä, URL-turvallinen täytteen poistettuna on turvallinen valinta.
Onko tulos kirjainkokoherkkä? Täysin. a ja A ovat eri arvoja, minkä vuoksi Base64 kestää väärin kirjoitetun merkin paljon huonommin kuin Base32 tai Crockford Base32.
