Base64-kodning och avkodning

Base64-kodning och avkodning konverterar godtyckliga bytes till en ASCII-sträng med RFC 4648-alfabetet och vänder tillbaka den strängen till de ursprungliga byten. Textläget accepterar en teckenkodning som UTF-8; filläge läser en uppladdning via webbläsarens FileReader och kan sända ut en data: URI för inbäddning. Kodning är inte kryptering. Alla som tar emot strängen kan avkoda den.

All kodning och avkodning körs i din webbläsare. Inget du klistrar in skickas till en server.

Koda text eller en fil till Base64

Kodning tar råbyte och skriver en sträng av A till Ö, a till z, 0 till 9, plus, snedstreck och utfyllnad =. Klistra in text eller välj en fil, välj teckenkodning när källan är text och läs resultatet.

Filläge passar små bilder och dokument som måste resa inuti JSON, XML eller e-post utan en binär kanal.

Utdata är säkert för transport genom system som korrumperar godtycklig binär, såsom äldre e-postgateways eller kopiera och klistra in i XML. Den är längre än designen. Ogiltig tom indata producerar ingen sträng; verktyget väntar på byte innan det avger tecken.

Avkoda en Base64-sträng tillbaka till data

Avkodning vänder på alfabetssökningen, bygger om den ursprungliga bitströmmen och returnerar text eller en nedladdningsbar fil. Utfyllnad av =-tecken i slutet är signifikant: de markerar hur många byte som fanns i den sista ofullständiga gruppen. Tecken utanför alfabetet orsakar ett tydligt fel snarare än en tyst partiell avkodning.

Whitespace ignoreras ofta så strängar som kopierats från PEM-certifikat eller MIME-kroppar fungerar fortfarande. En sträng som ser ut som Base64 men använder det URL-säkra alfabetet behöver det URL-säkra avkodningsläget, annars kommer bindestreck och understreck att avvisas som olagliga i standardalfabetet.

Förstå hur Base64-kodning fungerar

Base64 bearbetar indata i block om tre byte (24 bitar). Dessa 24 bitar är uppdelade i fyra grupper om 6 bitar. Varje 6-bitars värde är ett index från 0 till 63 i alfabetet med 64 tecken. Tre ingångsbyte blir därför fyra utdatatecken.

Bytes:  [ byte1 ][ byte2 ][ byte3 ]
Bits:   aaaaaaaa bbbbbbbb cccccccc
Groups: aaaaaa aabbbb bbbbcc cccccc
Chars:  Char1  Char2  Char3  Char4

När färre än tre byte återstår avger kodaren fortfarande fyra tecken men lägger till utfyllnad så att avkodaren känner till den ursprungliga längden. Bitomgrupperingen är hela algoritmen; det finns ingen kontrollsumma och ingen nyckel.

Koda ordet Hund steg för steg

Ordet "Hund" är tre ASCII-byte, så det fyller en Base64-grupp och kodar utan utfyllnadstecken. Armaturens utgång är RG9n. Att gå byte till bitar, omgruppera till 6-bitars index och läsa RFC 4648-alfabetet visar varför dessa fyra tecken visas och hur alla tre-byte-block följer samma väg.

1. Skriv byte. "D" = 0x44 = "01000100". o = 0x6F = 01101111 "g" = 0x67 = "01100111".

2. Sammanfoga 24 bitar. 01000100 01101111 01100111

3. Dela upp i 6-bitars grupper. 010001 000110 111101 100111

4. Konvertera varje grupp till ett decimalindex. 17, 6, 61, 39

5. Slå upp alfabetet. Index 17 = "R", 6 = "G", 61 = "9", 39 = "n"

Resultat: RG9n. Avkodning av RG9n returnerar de tre ursprungliga byten och texten Dog under UTF-8 eller ASCII.

Förstå stoppning med likhetstecknet

Utfyllnad visas när byteantalet inte är en multipel av tre. En överbliven byte ger två bokstäver och två "="-tecken. Två överblivna byte producerar tre tecken och en =. Fixturerna Do → RG8= och Dogs → RG9ncw== visar båda återstående skiftlägen bredvid det opaddade tre-byte ordet Dog.

Input	Bytes	Encoded	Padding
Dog	3	RG9n	none
Do	2	RG8=	one =
Dogs	4	RG9ncw==	two =

Do är två byte: 01000100 01101111. Efter 6-bitars gruppering finns det bara tillräckligt med bitar för tre meningsfulla tecken (RG8), och en utfyllnad = fyller den fjärde luckan. Hundar är fyra byte: en hel tre-byte grupp som kodar som RG9n, sedan en en-byte restkodning som cw==. Att ta bort stoppning för hand utan att justera bitlängden bryter avkodningen; lämna =-tecknen på plats när du klistrar in.

Läs Base64-alfabetet

RFC 4648 definierar 64 tecken plus utfyllnadsmärket =. Index 0 till 25 är "A" till "Z", 26 till 51 är "a" till "z", 52 till 61 är "0" till "9", index 62 är "+", och index 63 är "/".

Index 0 är "A", inte "0", vilket gör att alla som förväntar sig att siffror ska leda alfabetet löser sig.

Index range	Tecken
0 to 25	A to Z
26 to 51	a to z
52 to 61	0 to 9
62	+
63	/
padding	=

Kalkylatorns alfabetpanel listar samma tabell som kodaren använder, så ett misstänkt tecken kan kontrolleras mot standarduppsättningen. Hela strängen är ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/.

Använd den URL-säkra Base64-varianten

Det URL-säkra alfabetet (base64url) ersätter + med - och / med _. Utfyllnad kan utelämnas i vissa protokoll. JSON Web Tokens använder den här varianten så att tokensegment kan sitta i URL:er och HTTP-rubriker utan att procentkoda plus- och snedstreck.

Standardsträngar och URL-säkra strängar är inte utbytbara. Avkodning av en JWT-nyttolast med standardalfabetet misslyckas på bindestreck. Verktyget erbjuder ett explicit URL-säkert läge för både kodning och avkodning. Att procentkoda en URL är ett annat problem; använd sidan för URL-kodning och avkodning när målet är RFC 3986-escape snarare än Base64.

Ta hänsyn till storleksökningen

Var tredje byte blir fyra tecken, så den kodade längden är cirka 4/3 av inmatningen, en ökning med 33 procent före radbrytningar. Utfyllnad kan lägga till en eller två extra tecken på den sista gruppen. Data-URI:er och e-postbilagor känner att detta kostar snabbt: en bild på 300 KB blir ungefär 400 KB text.

encoded_length ≈ 4 × ceil(byte_length / 3)

Radbrytning med 76 tecken, vanligt i MIME, lägger till nya radbytes överst. Föredrar binära bilagor eller komprimerade format när storleken spelar roll; använd Base64 när kanalen verkligen inte kan bära råbytes.

Välj en teckenkodning

Base64 kodar bytes, inte abstrakta tecken. Samma bokstäver producerar olika bytes under UTF-8, UTF-16, Shift JIS eller Big5. Avkodning och sedan tolkning med fel teckenuppsättning ger mojibake även när Base64-lagret var perfekt, så teckenuppsättningen för textläge måste matcha producenten vid kodning och konsumenten vid avkodning.

Charset	Typical use
UTF-8	Default for modern text and APIs
Windows-1252	Legacy Western European text
UTF-16 LE / BE	Some Windows and Java payloads
Shift JIS	Older Japanese text
Big5	Older Traditional Chinese text

För ordet Dog producerar ASCII och UTF-8 samma tre byte, så RG9n är identisk. Icke-ASCII-text avviker. Välj den teckenuppsättning som matchar producenten före kodning, och samma teckenuppsättning efter avkodning, annars kommer resan att se ut som en Base64-bugg när misstaget är uppströms.

Vanliga frågor

Sammanfattning

Base64-kodning och avkodning mappar bytes till RFC 4648-alfabetet i 6-bitarsgrupper och vänder processen lokalt i webbläsaren. Dog blir RG9n, Do blir RG8= och Dogs blir RG9ncw==, vilket illustrerar utfyllnad för en- och två-byte-rester.

Det URL-säkra alfabetet byter ut +// mot -/_, utdata växer med ungefär en tredjedel, och teckenuppsättningsvalet avgör vilka bytes som textläget matas in i kodaren. Inget inklistrat laddas upp.

Relaterade miniräknare

URL Koda och avkoda · Binär kalkylator · Hexkalkylator