Hvad er Base64?
Base64 omskriver bytes ved hjælp af 64 læselige tegn, så data overlever en kanal bygget til tekst: en e-mailtekst, en JSON-streng, en XML-attribut, en URL. Hver tre bytes bliver til fire tegn, og det er der navnet kommer fra — alfabetet rummer 64 symboler, og hvert af dem bærer præcis seks bit.
Det er en transportkodning, ikke en sikkerhedsforanstaltning og ikke et komprimeringstrin. Outputtet er nogenlunde en tredjedel større end inputtet, og enhver, der har strengen, kan vende den direkte tilbage. Hvis man vil vide, om data er ændret, er det en hash (Hash-generator); hvis de skal forblive hemmelige, er det kryptering. Base64 gør ingen af delene.
Det ene tal at huske: tre inputbytes bliver til fire outputtegn. Alt andet på denne side følger af det. Fire tegn bærer tyve-fire bit, og tyve-fire bit er præcis tre bytes, så data går aldrig tabt og opfindes aldrig — undtagen helt til sidst, hvor inputtet måske ikke fylder den sidste gruppe på tre.
De fem alfabeter, denne side kan bruge
De to første rækker er standarder, og de sidste tre er konventioner, der voksede frem omkring Unix. Alle fem bærer de samme seks bit pr. tegn og adskiller sig kun i hvilke 64 tegn der bærer dem, så de samme bytes bliver til fem forskellige strenge. Ingen streng siger selv, hvilket alfabet der producerede den, hvorfor alfabetsvælgeren er standard som udgangspunkt, og afkrydsningsfeltet for URL-sikker er en genvej til den anden række.
Sådan vælger siden en kandidat: vælgeren er standard for begge retninger. Ved afkodning læser panelet til højre også selve strengen — - og _ kan kun komme fra det URL-sikre alfabet, + eller / kan kun komme fra standardalfabetet, og et / eller . tæt på starten peger på de to Unix-alfabeter. Hvert alfabet, der kan læse det aktuelle input, vises der, med begrundelsen for, om det er en kandidat eller ej.
Linjeombrydning: 76 og 64 tegn
MIME krævede Base64, der kan passe i en e-mail uden at linjer bliver urimeligt lange, og valgte 76 tegn pr. linje adskilt af CRLF. PEM-filer, der omslutter certifikater og nøgler, bruger 64. Linjeskiftene er ikke en del af dataene: en afkoder fjerner dem og sætter linjerne sammen igen, før den gør noget som helst, så en ombrudt streng og en ikke-ombrudt streng afkodes til præcis de samme bytes. Hver linje undtagen den sidste indeholder et helt antal grupper på fire tegn, og det er det, der gør det sikkert at sætte dem sammen igen.
Denne side lader outputtet stå på én linje, medmindre man vælger en bredde, og afkoderen accepterer input med eller uden linjeskift. Skiftene denne side skriver er almindelige linjeskift, hvilket et tekstfelt kan rumme; MIME-mail-tekster bruger traditionelt et vognretur før hvert linjeskift, og alle afkodere i brug accepterer begge dele.
Opfyld, og hvorfor det kan udelades
Når inputtet ikke er et multiplum af tre bytes, er den sidste gruppe på fire tegn ufuldstændig, og et eller to =-tegn udfylder den. De bærer slet ingen data: de siger blot, hvor mange af de fire tegn der er rigtige. En afkoder kan finde det ud fra længden i stedet, hvorfor URL-sikker Base64 traditionelt udelader opfyldet — et = er besværligt i en URL eller et filnavn, og nogle systemer procent-kodede det.
Afkrydsningsfeltet i indstillingsrækken beholder opfyldet, når det URL-sikre alfabet er valgt. Intet andet ændrer sig; tegnene, der bærer data, er identiske begge veje.
Almindelige misforståelser
- "Base64 skjuler dataene." Det gør det ikke. Det er en substitution uden nøgle, og pointen er, at enhver læser kan vende den. At pakke en adgangskode eller et token ind i Base64 ændrer ikke noget ved, hvem der kan læse den.
- "Base64 komprimerer." Det modsatte: hver tre inputbytes bliver til fire outputtegn, så teksten er en tredjedel større end de data, den bærer.
- "Linjeskiftene er en del af værdien." De er præsentation. At tilføje eller fjerne dem ændrer aldrig de bytes, der kommer tilbage.
- "URL-sikker betyder en anden kodning." Det er den samme kodning med to tegn byttet om:
+ bliver til -, og / bliver til _, så strengen kan stå i en URL-sti eller en forespørgselsværdi uden escaping. - "En streng, der kan afkodes, må være gyldig Base64." Enhver streng af alfabettegn er gyldig Base64, fordi enhver kombination af seks-bit-værdier er en gyldig sekvens af bytes. En streng viser først, at den er forkert i næste trin, når bytes kontrolleres mod det format, de skulle have.
- "Opfyldet fortæller, hvilket alfabet der blev brugt." Det gør det ikke, og i de fleste tilfælde gør tegnene det heller ikke: standard- og det URL-sikre alfabet er enige om 62 af deres 64 symboler, så en kort streng ofte læses ens i begge.
Spørgsmål, der dukker op
Hvorfor ender en Base64-streng nogle gange med ét = og nogle gange med to? Ét betyder, at den sidste gruppe bærer tre rigtige tegn, altså to inputbytes; to betyder, at den bærer to, altså én inputbyte. Intet = betyder, at inputlængden var et multiplum af tre.
Kan Base64 repræsentere vilkårlige binære filer? Ja, og det er dens vigtigste brug. Denne side behandler inputtet som UTF-8-tekst; det dedikerede værktøj Fil til Base64 læser rå bytes, når man vil kode noget, der ikke er tekst.
Hvilket alfabet skal jeg bruge i et API? Det, som den modtagende ende dokumenterer. Hvis den siger URL-sikker, så brug det; hvis den ikke siger noget, og værdien rejser inde i en URL, er URL-sikker med opfyldet fjernet det sikre valg.
Skelner outputtet mellem store og små bogstaver? Helt. a og A er forskellige værdier, hvorfor Base64 langt dårligere overlever et forkert skrevet tegn end Base32 eller Crockford Base32 gør.
