Base64 forklart: hvorfor det gjør data større og hvordan du dekoder det

Base64 skriver binære data som vanlig tekst med 64 tegn: A til Z, a til z, 0 til 9, pluss + og /. Hver tre byte blir til fire tegn, så teksten er omtrent en tredjedel lengre enn dataene den inneholder. Folk bruker det når et format bare godtar tekst, for eksempel en data-URL i en nettside, et JSON-felt eller et e-postvedlegg.

Base64-koding og dekodingLese eller lage en Base64-strengGjør det gratis

Hvorfor tekstformater trenger det

Mange formater ble laget bare for tekst. En e-posttekst, en JSON-fil og en CSS-fil kan trygt inneholde bokstaver og symboler, men et rått bilde eller en zip-fil inneholder byteverdier som noen systemer kan endre, kutte av eller tolke som kontrolltegn. Base64 bruker bare tegn som alle tekstsystemer slipper gjennom uendret, så dataene kommer frem intakt. Det er definert i RFC 4648.

Base64 er en koding, ikke en hemmelighet. Alle kan dekode den uten nøkkel, så den må aldri brukes til å skjule passord eller personopplysninger.

Slik blir tre byte til fire tegn

Ta ordet Man, som er tre byte: 77, 97 og 110 i desimal. Sammen utgjør de tre bytene 24 bits. Del de 24 bitene i fire grupper på seks bits, så er hver gruppe et tall fra 0 til 63, som peker på ett tegn i alfabetet. Man blir til TWFu.

Seks bits kan bare gi 64 verdier, så fire tegn bærer tre byte. Utdata er derfor omtrent en tredjedel større enn inndata, før eventuelle linjeskift legges til.

Når dataene ikke går opp i tre byte, fyller koderen ut slutten med =-tegn. Ma, som er to byte, blir til TWE=, og M, som er én byte, blir til TQ==. Utfyllingen forteller dekoderen hvor mange byte den siste gruppen inneholder.

Tekst må kodes som UTF-8 først

Base64 jobber med byte, og tekst består av tegn. Et tegn som é eller ✓ lagres som mer enn én byte i UTF-8, kodingen som brukes på hele nettet. Nettleserfunksjonen btoa() tar en streng og behandler hvert tegn som én byte, så den feiler på tegn utenfor det grunnleggende latinske området. Kaller du den på et hakemerke, kastes en InvalidCharacterError.

Løsningen er å gjøre teksten om til UTF-8-byte først, og så kode disse bytene. Frasen héllo ✓ er 10 byte i UTF-8, og Base64-versjonen er aMOpbGxvIOKckw==. Base64-verktøyet gjør dette trinnet for deg. Når det dekoder, leser det bytene tilbake som UTF-8. Hvis bytene ikke er gyldig UTF-8-tekst, behandler verktøyet dem som en fil og tilbyr nedlasting.

URL-sikker Base64

Standardalfabetet inneholder + og /. I en URL kan + bety et mellomrom, og / skiller delene i en sti, så en Base64-streng kan ødelegge en lenke. Den URL-sikre formen (RFC 4648, seksjon 5) bruker - og _ i stedet, og dropper vanligvis =-utfyllingen. Bruk den når strengen skal inn i en URL, et filnavn eller et token. Dekoderen godtar begge former, med eller uten utfylling.

Hvis Base64-en kommer fra en lenke, dekod URL-en først. En verdi som er prosentkodet i en lenke må dekodes før Base64 kan leses. Guiden om prosentkoding forklarer reglene for lenker.

Et innloggingstoken er det vanligste tilfellet: et JSON Web Token er tre Base64url-deler satt sammen med punktum, en header, dataene og en signatur. JWT-dekoderen deler opp et slikt token og viser header og data som lesbar JSON.

Data-URL-er og bilder

En data-URL legger selve filen inne i lenken. Formen er data:, deretter medietypen, så ;base64, og så et komma og dataene. Et lite bilde blir til data:image/png;base64, etterfulgt av de kodede bytene. Nettsider og stilark godtar denne formen, noe som sparer én forespørsel for et lite ikon.

Prisen er størrelsen. Dataene er omtrent en tredjedel større, og de reiser inne i siden eller stilarket i stedet for som en egen fil som nettleseren kan mellomlagre. Bruk data-URL-er for små bilder, ikke for store fotografier. Komprimer bildet før du koder det hvis det er stort.

Når du dekoder Base64 i verktøyet, ser det på de første bytene i dataene. PNG-, JPEG-, GIF- og WebP-filer begynner hver med en kjent signatur, så verktøyet viser en forhåndsvisning og tilbyr nedlasting. En data-URL med bildetype vises også som et bilde.

Slik gjør du det med fixmint

1. Velg Kode eller Dekode over Tekst eller Base64, og lim inn teksten eller Base64-en.
2. Kryss av for URL-sikkert alfabet, uten =-utfylling for tokens, filnavn og lenker. Dekoderen godtar begge former uansett.
3. For å lage en data-URL av en fil, slipp filen i slippområdet og kryss av for For filer: lag en data:-URL.
4. Kopier resultatet. Hvis de dekodede bytene er en fil og ikke tekst, bruk nedlastingen verktøyet tilbyr.

Vanlige feil ved dekoding

• Et tegn er ikke tillatt. Inndata inneholder et tegn utenfor de 64, for eksempel et anførselstegn fra en kopiert setning. Sjekk hvor teksten kommer fra. Et nullbreddemellomrom i kopiert tekst gir samme feil, så fjern skjulte tegn og prøv igjen. Guiden om skjulte tegn forklarer hvor de kommer fra.
• Lengden er feil. Et tegn mangler eller er for mye, noe som vanligvis betyr at kopieringen ble kuttet av.
• Linjeskift og mellomrom. E-post (MIME) bryter Base64 etter hvert 76. tegn. Dekoderen fjerner mellomrom og linjeskift, så du kan lime inn brutt tekst slik den er.
• Manglende utfylling. Noen systemer fjerner =-tegnene. Dekoderen legger dem til igjen.

Spesialtilfeller

• Resultatet ser ut som tull. Det kan være en fil og ikke tekst. En zip-fil, en PDF eller et program dekodes til byte som ikke lar seg lese som tekst. Verktøyet tilbyr dem som nedlasting.
• Svært store filer. Hele filen holdes i nettleseren mens den kodes eller dekodes, så en veldig stor fil kan gå tregt, og på en telefon kan den feile.

Raske svar

Er Base64 det samme som kryptering?

Nei. Det er en reversibel koding uten nøkkel, så alle kan dekode den.

Hvorfor er Base64-en min lengre enn filen?

Hvert sett med tre byte blir til fire tegn, så teksten er omtrent en tredjedel større.

Hvorfor feiler en kopiert Base64-streng ved dekoding?

Vanligvis gikk et tegn tapt eller ble lagt til under kopieringen, for eksempel et linjeskift på feil sted eller et manglende siste tegn. Kopier den på nytt fra kilden.