Vad är Base64?
Base64 skriver om byte med sextiofyra läsbara tecken så att data överlever en kanal som är byggd för text: ett e-postmeddelande, en JSON-sträng, ett XML-attribut, en URL. Varje tre byte blir fyra tecken, vilket är var namnet kommer ifrån — alfabetet har sextiofyra symboler och var och en bär exakt sex bitar.
Det är en transportkodning, inte en säkerhetsåtgärd och inte ett komprimeringssteg. Utdata är ungefär en tredjedel större än indata, och vem som helst som har strängen kan vända den direkt. Om det ska kontrolleras om data har ändrats är det en hash (Hashgenerator); om den ska förbli hemlig är det kryptering. Base64 gör ingetdera.
Det enda talet att komma ihåg: tre indatabyte blir fyra utdatatecken. Allt annat på den här sidan följer av det. Fyra tecken bär tjugofyra bitar, och tjugofyra bitar är exakt tre byte, så ingen data förloras eller hittas på — utom i slutet, där indata kanske inte fyller den sista gruppen med tre.
De fem alfabeten som den här sidan kan använda
De två första raderna är standarder och de tre sista är konventioner som växte fram kring Unix. Alla fem bär samma sex bitar per tecken och skiljer sig bara åt i vilka sextiofyra tecken som bär, så samma byte blir fem olika strängar. Ingenting i en sträng säger vilket alfabet som skapade den, vilket är anledningen till att alfabetsväljaren väljer standard som förval och kryssrutan för URL-säker är en genväg till den andra raden.
Så väljer sidan en kandidat: väljaren är standard för båda riktningarna. Vid avkodning läser panelen till höger också strängen själv — - och _ kan bara komma från det URL-säkra alfabetet, + eller / kan bara komma från det standardiserade, och ett / eller . nära början pekar på de två Unix-alfabeten. Varje alfabet som kan läsa den aktuella indatan visas där, med anledningen till att det är eller inte är en kandidat.
Radbrytning: 76 och 64 tecken
MIME krävde Base64 som får plats i ett e-postmeddelande utan att någon rad blir orimligt lång, och valde 76 tecken per rad avgränsade med CRLF. PEM-filer, som omsluter certifikat och nycklar, använder 64. Radbrytningarna är inte en del av datan: en avkodare tar bort dem och sammanfogar raderna igen innan något annat görs, så en inslagen sträng och en oinslagen avkodas till exakt samma byte. Varje rad utom den sista innehåller ett helt antal grupper om fyra tecken, vilket är det som gör att det är säkert att sammanfoga dem igen.
Den här sidan lämnar utdata på en rad om ingen bredd väljs, och avkodaren accepterar indata med eller utan radbrytningar. Radbrytningarna den här sidan skriver är vanliga radmatningar, vilket är vad en textruta kan hålla; MIME-brev använder traditionellt en vagnretur före varje radmatning, och alla avkodare som används tar emot båda.
Utfyllnad, och varför den kan tas bort
När indatan inte är ett multipel av tre byte är den sista gruppen med fyra tecken ofullständig, och ett eller två =-tecken fyller ut den. De bär ingen data alls: de anger bara hur många av de fyra tecknen som är riktiga. En avkodare kan räkna ut det från längden i stället, vilket är anledningen till att URL-säker Base64 traditionellt utelämnar utfyllnaden — ett = är besvärligt i en URL eller ett filnamn, och vissa system procentkodar det.
Kryssrutan i alternativraden behåller utfyllnaden när det URL-säkra alfabetet är valt. Inget annat ändras; tecknen som bär data är identiska i båda fallen.
Vanliga missuppfattningar
- "Base64 döljer datan." Det gör det inte. Det är en substitution utan nyckel, och hela poängen är att vem som helst kan vända den. Att packa in ett lösenord eller en token i Base64 ändrar ingenting om vem som kan läsa den.
- "Base64 komprimerar." Tvärtom: varje tre indatabyte blir fyra utdatatecken, så texten är en tredjedel större än datan den bär.
- "Radbrytningarna är en del av värdet." De är presentation. Att lägga till eller ta bort dem ändrar aldrig de byte som kommer tillbaka.
- "URL-säker betyder en annan kodning." Det är samma kodning med två tecken utbytta:
+ blir - och / blir _, så strängen kan ligga i en URL-sökväg eller ett frågevärde utan escapning. - "En sträng som avkodas måste vara giltig Base64." Varje sträng av alfabettecken är giltig Base64, eftersom varje kombination av sexbitarsvärden är en giltig följd av byte. En sträng visar sig vara fel först i nästa steg, när byten kontrolleras mot det format de skulle följa.
- "Utfyllnaden visar vilket alfabet som användes." Det gör den inte, och i de flesta fall gör inte tecknen det heller: det standardiserade och det URL-säkra alfabetet stämmer överens för sextiotvå av sina sextiofyra symboler, så en kort sträng läses ofta lika i båda.
Frågor som brukar dyka upp
Varför slutar en Base64-sträng ibland med ett = och ibland med två? Ett betyder att den sista gruppen bär tre riktiga tecken, vilket är två indatabyte; två betyder att den bär två, vilket är en indatabyte. Inget = betyder att indatans längd var ett multipel av tre.
Kan Base64 representera godtyckliga binärfiler? Ja, och det är dess huvudsakliga användning. Den här sidan behandlar indata som UTF-8-text; verktyget Fil till Base64 läser råa byte när något som inte är text ska kodas.
Vilket alfabet ska jag använda i ett API? Det mottagande systemet dokumenterar vad som gäller. Om det säger URL-säker, använd det; om det inte säger något och värdet ska ligga i en URL, är URL-säker utan utfyllnad det säkra valet.
Är utdata skiftlägeskänslig? Helt. a och A är olika värden, vilket är anledningen till att Base64 klarar ett felskrivet tecken betydligt sämre än Base32 eller Crockford Base32 gör.
