Hva er Base64?
Base64 skriver om bytene med fireogseksti lesbare tegn, slik at data overlever en kanal laget for tekst: en e-postkropp, en JSON-streng, en XML-attributt, en URL. Hver tre byte blir til fire tegn, og det er der navnet kommer fra — alfabetet har fireogseksti symboler, og hvert av dem bærer nøyaktig seks bit.
Det er en transportkoding, ikke et sikkerhetstiltak og ikke et komprimeringstrinn. Utdataene er omtrent en tredel større enn inndataene, og hvem som helst som har strengen kan snu den rett tilbake. Vil man vite om data er endret, er det en hash (Hash-generator); vil man at de skal forbli hemmelige, er det kryptering. Base64 gjør ingen av delene.
Det ene tallet å huske: tre inndatabyte blir til fire utdatategn. Alt annet på denne siden følger av det. Fire tegn bærer tjuefire bit, og tjuefire bit er nøyaktig tre byte, så data går aldri tapt eller oppstår fra ingenting — unntatt helt til slutt, der inndataene kanskje ikke fyller den siste gruppen på tre.
De fem alfabetene denne siden kan bruke
De to første radene er standarder, og de tre siste er konvensjoner som vokste fram rundt Unix. Alle fem bærer de samme seks bitene per tegn og skiller seg bare i hvilke fireogseksti tegn som bærer dem, så de samme bytene blir til fem forskjellige strenger. Ingenting inne i en streng sier hvilket alfabet som laget den, og det er grunnen til at alfabetvelgeren står på standard som utgangspunkt, og at avkrysningsboksen for URL-trygt er en snarvei til den andre raden.
Slik velger siden en kandidat: velgeren er standard for begge retninger. Ved dekoding leser panelet til høyre også strengen selv — - og _ kan bare komme fra URL-trygt alfabet, + eller / kan bare komme fra standardalfabetet, og en / eller . nær starten peker på de to Unix-alfabetene. Hvert alfabet som kan lese den nåværende inndataen vises der, med begrunnelsen for hvorfor det er, eller ikke er, en kandidat.
Linjeskift: 76 og 64 tegn
MIME krevde Base64 som får plass i en e-post uten at noen linje blir unødvendig lang, og landet på 76 tegn per linje atskilt med CRLF. PEM-filer, som pakker inn sertifikater og nøkler, bruker 64. Linjeskiftene er ikke en del av dataene: en dekoder fjerner dem og setter linjene sammen igjen før den gjør noe annet, så en innpakket og en uinnpakket streng dekodes til nøyaktig de samme bytene. Hver linje unntatt den siste inneholder et helt antall firetegnsgrupper, og det er det som gjør det trygt å sette dem sammen igjen.
Denne siden lar utdataene stå på én linje med mindre man velger en bredde, og dekoderen tar imot inndata med eller uten linjeskift. Linjeskiftene denne siden skriver er vanlige linjeskift, slik et tekstfelt kan holde; MIME-e-postkropper bruker tradisjonelt en vognretur før hvert linjeskift, og alle dekodere i bruk godtar begge.
Utfylling, og hvorfor den kan utelates
Når inndataene ikke er et multiplum av tre byte, er den siste firetegnsgruppen ufullstendig, og ett eller to =-tegn fyller den ut. De bærer ingen data i det hele tatt: de sier bare hvor mange av de fire tegnene som er reelle. En dekoder kan finne ut det fra lengden i stedet, og det er grunnen til at URL-trygg Base64 tradisjonelt utelater utfyllingen — et = er klønete i en URL eller et filnavn, og noen systemer prosentkoder det.
Avkrysningsboksen i valgraden beholder utfyllingen når det URL-trygge alfabetet er valgt. Ellers endres ingenting; tegnene som bærer data er identiske uansett.
Vanlige misforståelser
- "Base64 skjuler dataene." Det gjør det ikke. Det er en substitusjon uten nøkkel, og hele poenget er at enhver leser kan reversere den. Å pakke et passord eller et token inn i Base64 endrer ingenting om hvem som kan lese det.
- "Base64 komprimerer." Det motsatte: hver tre inndatabyte blir til fire utdatategn, så teksten er en tredel større enn dataene den bærer.
- "Linjeskiftene er en del av verdien." De er presentasjon. Å legge dem til eller fjerne dem endrer aldri bytene som kommer tilbake.
- "URL-trygt betyr en annen koding." Det er samme koding med to tegn byttet:
+ blir til - og / blir til _, så strengen kan stå i en URL-sti eller en spørringsverdi uten escaping. - "En streng som dekodes må være gyldig Base64." Enhver streng med alfabettegn er gyldig Base64, fordi hver kombinasjon av seksbitsverdier er en gyldig sekvens av byte. En streng viser seg først å være feil i neste trinn, når bytene sjekkes mot formatet de skulle følge.
- "Utfyllingen forteller hvilket alfabet som ble brukt." Det gjør den ikke, og i de fleste tilfeller gjør ikke tegnene det heller: standardalfabetet og det URL-trygge alfabetet er enige om seksti-to av sine seksti-fire symboler, så en kort streng leses ofte likt i begge.
Spørsmål som ofte dukker opp
Hvorfor ender en Base64-streng noen ganger med ett = og noen ganger med to? Ett betyr at den siste gruppen bærer tre reelle tegn, altså to inndatabyte; to betyr at den bærer to, altså én inndatabyte. Ingen = betyr at inndatalengden var et multiplum av tre.
Kan Base64 representere vilkårlige binære filer? Ja, og det er dens viktigste bruk. Denne siden behandler inndataene som UTF-8-tekst; det dedikerte verktøyet Fil til Base64 leser rå byte når man vil kode noe som ikke er tekst.
Hvilket alfabet bør jeg bruke i et API? Det mottakersiden dokumenterer. Står det URL-trygt, bruk det; står det ingenting og verdien reiser inne i en URL, er URL-trygt uten utfylling det sikre valget.
Skiller utdataene mellom store og små bokstaver? Fullstendig. a og A er forskjellige verdier, og derfor tåler Base64 en feilskrevet tegn langt dårligere enn Base32 eller Crockford Base32 gjør.
