Hva Er Base64-koding? Slik Fungerer Det, Med Eksempler
Base64-koding er en måte å representere hvilken som helst data, tekst eller binærdata, med bare 64 utskrivbare ASCII-tegn, slik at den overlever systemer som bare er bygget for å håndtere ren tekst trygt. Det er verken kryptering eller komprimering. Det er en reversibel formatomdanning, og hvem som helst kan reversere den i ett steg.
Hva Base64-koding faktisk gjør
Base64 tar rå byte og skriver dem om med et fast alfabet på 64 symboler: A-Z, a-z, 0-9, pluss + og /. Hver 3 byte med inndata blir til nøyaktig 4 Base64-tegn, så det kodede resultatet ender opp rundt 33 % større enn det som gikk inn.
Det siste punktet er verdt å understreke, for det er den vanligste misforståelsen om Base64: kodingen gjør dataene større, ikke mindre, og den bruker ingen nøkkel av noe slag. Koder du et passord i Base64 og lagrer det slik, har du ikke beskyttet det i det hele tatt. Hvem som helst med fem sekunder og en teksteditor kan dekode det tilbake til klartekst. Base64 løser et transportproblem (kan denne bytesekvensen limes inn i et tekstfelt, en URL eller en JSON-streng uten å ødelegges?), ikke et sikkerhetsproblem. Trenger du hemmelighold, er det hashing og kryptering du skal bruke. Ingen av delene har noe med Base64 å gjøre.
Slik fungerer det: koding av «Man» bit for bit
Navnet forklarer prinsippet: Base64 er en base-konvertering. Vanlige byte er base 256 (8 bit hver, 256 mulige verdier). Base64 grupperer de samme bitene på nytt i 6-bit-blokker, og hver 6-bit-blokk (64 mulige verdier, 0 til 63) tilsvarer ett tegn i alfabetet.
Ta teksten «Man». De tre ASCII-byteverdiene er M=77, a=97, n=110. Skrevet i binær:
| Tegn | Byteverdi | Binær (8 bit) |
|---|---|---|
| M | 77 | 01001101 |
| a | 97 | 01100001 |
| n | 110 | 01101110 |
Slå sammen alle 24 bitene i rekkefølge: 010011010110000101101110. Del så den samme bitstrengen inn i fire grupper på 6 bit hver, uten hensyn til de opprinnelige bytegrensene:
010011 | 010110 | 000101 | 101110
Hver 6-bit-gruppe er bare et tall mellom 0 og 63. Regn dem om til desimal og slå opp hver verdi i Base64-alfabetet:
| 6-bit-gruppe | Desimalverdi | Base64-tegn |
|---|---|---|
| 010011 | 19 | T |
| 010110 | 22 | W |
| 000101 | 5 | F |
| 101110 | 46 | u |
Les tegnene i rekkefølge, og «Man» blir til «TWFu». Ingenting av dette er magi: 3 byte (24 bit) deles jevnt opp i 4 grupper på 6 bit, siden 24 er delelig med både 8 og 6. Det er nøyaktig derfor forholdet alltid lander på 3 byte inn, 4 tegn ut.
Utfylling: hvorfor noen Base64-strenger ender med =
Den rene 3-byte-grupperingen over fungerer bare når inndataen din har en lengde som er delelig med 3. De færreste tekster er det, så Base64 trenger en måte å signalisere «denne siste gruppen er kort» på. Det er akkurat det utfyllingstegnet = gjør.
| Inndata | Byte | Base64-resultat | Hvorfor |
|---|---|---|---|
| «M» | 1 | TQ== | 1 byte fyller ikke en 3-byte-gruppe, så det blir bare 2 reelle tegn, fylt ut med == |
| «Ma» | 2 | TWE= | 2 byte gir 3 reelle tegn, fylt ut med én = |
| «Man» | 3 | TWFu | 3 byte fyller gruppen nøyaktig: 4 tegn, ingen utfylling nødvendig |
Hvert = du ser til slutt i en Base64-streng, er bare fyllstoff som markerer hvor mange bit som manglet i den siste gruppen. Det bærer ingen egen informasjon.
Hvor du faktisk møter Base64
Base64 dukker opp overalt hvor binære eller spesielle tegn må gjennom en kanal som bare tåler ren tekst. Noen konkrete eksempler:
HTTP Basic Authentication. Innloggingsdataene user:pass1234 kodes til dXNlcjpwYXNzMTIzNA== og sendes i headeren som Authorization: Basic dXNlcjpwYXNzMTIzNA==. Det er bokstavelig talt slik Basic Auth fungerer, og det er også en god påminnelse om at Basic Auth ikke gir noen reell beskyttelse på egen hånd (se over), med mindre den kjører over HTTPS.
Å legge strukturerte data i en payload eller URL. Et JSON-objekt som {"id":42,"active":true} blir til eyJpZCI6NDIsImFjdGl2ZSI6dHJ1ZX0=, en flat streng uten anførselstegn eller krøllparenteser, trygg å legge rett inn i en URL-parameter eller et annet JSON-felt.
Data-URL-er. CSS og HTML kan legge inn et lite bilde direkte med data:image/png;base64,iVBORw0K... i stedet for en egen filforespørsel, som er grunnen til at man av og til ser en solid Base64-blokk midt inne i et stilark.
E-postvedlegg. MIME, formatet e-post bruker for vedlegg, ble designet for flere tiår siden rundt tekstsikker transport, så binærfiler Base64-kodes før de flettes inn i selve meldingen.
JWT-tokener. Et JSON Web Token er tre Base64url-segmenter atskilt med punktum: header.payload.signature. Payload-segmentet er bare Base64url-kodet JSON, så en vanlig Base64/Base64url-dekoder, som den under, avslører innholdet uten videre (dette er ikke en dedikert JWT-dekoder, den dekoder rett og slett segmentet du limer inn).
To eksempler til, nyttige for å sjekke at en dekoder du jobber med regner riktig:
«Hello, World!» kodes til SGVsbG8sIFdvcmxkIQ==.
«café» kodes til Y2Fmw6k=. Det er verdt å stoppe opp ved: «café» har 4 tegn, men é tar 2 byte i UTF-8, så strengen er egentlig 5 byte, ikke 4, og Base64 opererer på byte, aldri på tegn. Samme logikk gjelder for en emoji som «🚀», som alene er 4 UTF-8-byte og kodes til 8J+agA==. Ser du et Base64-resultat som er lengre enn du ventet ut fra antall synlige tegn, er UTF-8 med flere byte per tegn nesten alltid grunnen.
Kod eller dekod din egen tekst
Skriv i en av widgetene under. Alt skjer lokalt i nettleseren din, ingenting sendes til noen server.
Vanlige feil og spesialtilfeller
Å behandle Base64 som kryptering. Dette er verdt å gjenta rett ut: Base64 er ikke en sikkerhetsmekanisme. Den har ingen nøkkel, den er fullt reversibel av design, og å bruke den til å «beskytte» et passord, et token eller personopplysninger er et reelt antimønster, ikke bare en teknisk detalj. Skal noe holdes hemmelig, krypter det. Base64 er ikke det laget.
Standard Base64 er ikke URL-sikker. Tegnene +, / og = kan bli ødelagt eller skape tvetydighet inni en URL, en spørrestreng eller et filnavn. Derfor finnes varianten Base64url, som bytter ut + og / med - og _, og ofte dropper utfylling helt. Ser du en Base64-lignende streng i en URL eller et JWT uten +, uten / og uten =, er det derfor: det er den URL-sikre varianten, ikke en annen koding.
Mellomrom eller manglende utfylling som ødelegger dekodingen. Strenge dekodere kan avvise en streng med et løst linjeskift, et mellomrom eller et utfyllingstegn som har blitt klippet bort av det som limte den inn. Rydd opp i strengen først hvis en dekoding feiler uventet.
Flerbyte-UTF-8 som blåser opp resultatet mer enn ventet. Som vist over med «café» og «🚀», koder Base64 byte, ikke synlige tegn. Bokstaver med aksenter, CJK-tekst og emojier tar alle mer enn én byte hver i UTF-8, så den kodede lengden gjenspeiler antall byte, ikke det du ville telt som tegn på skjermen.
Dobbeltkoding ved et uhell. Kjører du en allerede Base64-kodet streng gjennom koderen én gang til, får du et ekstra lag Base64 rundt det første. Dekoder du bare én gang, ender du opp med den opprinnelige kodede strengen igjen, fortsatt uleselig, ikke det egentlige innholdet. Ser en dekoding ut som rot, prøv å dekode en gang til før du antar at strengen er skadet.
Ofte stilte spørsmål
Er Base64 det samme som kryptering? Nei. Base64 er en reversibel koding uten noen nøkkel. Hvem som helst kan dekode den i ett eneste steg, uten spesialverktøy eller kunnskap. Trenger du å holde data hemmelig, bruk faktisk kryptering. Base64 endrer bare representasjonen, ikke konfidensialiteten.
Hvorfor blir Base64-resultatet lengre enn originalteksten? Fordi det bytter 8-bit byte mot 6-bit tegn, så 3 byte inndata blir alltid til 4 tegn utdata, en fast økning på rundt 33 %. Det er prisen for å representere vilkårlige byte med et lite, tekstsikkert alfabet.
Hva betyr =-tegnene på slutten av en Base64-streng?
De er utfylling, lagt til når inndatalengden ikke er delelig med 3 byte uten rest. Én = betyr at siste gruppe manglet én byte, == betyr at den manglet to. De koder ingen egentlige data, de markerer bare hvor inndataen tok slutt.
Hvorfor har noen Base64-strenger i URL-er eller JWT-er verken +, / eller =?
De bruker Base64url, en variant bygget spesielt for URL-er, filnavn og tokener som JWT. Den bytter ut de to tegnene som skaper trøbbel i en URL (+ og /) med - og _, og hopper som regel helt over utfylling.
Kan jeg dekode et JWT med en Base64-dekoder? Du kan dekode header- og payload-segmentene, siden begge bare er Base64url-kodet JSON atskilt med punktum. Lim inn ett av segmentene (ikke hele tokenet, og ikke signatur-delen) i en Base64/Base64url-dekoder for å lese claimene inni.