Wat is Base64?
Base64 herschrijft bytes met vierenzestig leesbare tekens, zodat data een kanaal overleeft dat voor tekst is gebouwd: de tekst van een e-mail, een JSON-tekenreeks, een XML-attribuut, een URL. Elke drie bytes worden vier tekens, en daar komt de naam vandaan — het alfabet bevat vierenzestig symbolen en elk draagt precies zes bits.
Het is een transportcodering, geen beveiligingsmaatregel en geen compressiestap. De uitvoer is ongeveer een derde groter dan de invoer, en iedereen die de tekenreeks heeft, kan hem direct terugdraaien. Als u wilt weten of data is gewijzigd, is dat een hash (Hashgenerator); als u wilt dat het geheim blijft, is dat versleuteling. Base64 doet geen van beide.
Het ene getal om te onthouden: drie invoerbytes worden vier uitvoertekens. Al het andere op deze pagina volgt daaruit. Vier tekens dragen vierentwintig bits, en vierentwintig bits is precies drie bytes, dus er gaat nooit data verloren of ontstaat er nooit data — behalve aan het eind, waar de invoer de laatste groep van drie misschien niet vult.
De vijf alfabetten die deze pagina kan gebruiken
De eerste twee rijen zijn standaarden en de laatste drie zijn conventies die rond Unix zijn ontstaan. Alle vijf dragen dezelfde zes bits per teken en verschillen alleen in welke vierenzestig tekens het dragen, dus dezelfde bytes worden vijf verschillende tekenreeksen. Niets in een tekenreeks zegt welk alfabet hem heeft voortgebracht, en daarom staat de alfabetkeuzelijst op standaard en is het URL-veilige vinkje een snelkoppeling naar de tweede rij.
Hoe de pagina een kandidaat kiest: de keuzelijst is de standaard voor beide richtingen. Bij het decoderen leest het paneel rechts de tekenreeks ook zelf — - en _ kunnen alleen uit het URL-veilige alfabet komen, + of / alleen uit het standaardalfabet, en een / of . dicht bij het begin wijst op de twee Unix-alfabetten. Elk alfabet dat de huidige invoer kan lezen, staat daar vermeld, met de reden waarom het wel of niet een kandidaat is.
Regelafbreking: 76 en 64 tekens
MIME vroeg om Base64 die in een e-mail past zonder dat een regel onredelijk lang wordt, en koos 76 tekens per regel, gescheiden door CRLF. PEM-bestanden, die certificaten en sleutels omhullen, gebruiken 64. De regelafbrekingen zijn niet onderdeel van de data: een decoder verwijdert ze en voegt de regels weer samen voordat hij iets anders doet, dus een omwikkelde en een niet-omwikkelde tekenreeks decoderen naar precies dezelfde bytes. Elke regel behalve de laatste bevat een heel aantal groepen van vier tekens, en dat maakt het veilig om ze weer samen te voegen.
Deze pagina laat de uitvoer op één regel staan, tenzij u een breedte kiest, en de decoder accepteert invoer met of zonder regelafbrekingen. De afbrekingen die deze pagina schrijft zijn gewone regelinvoeren, wat een tekstvak kan bevatten; MIME-mailtekst gebruikt traditioneel een wagenterugloop vóór elke regelinvoer, en elke decoder die in gebruik is accepteert beide.
Opvulling, en waarom die weggelaten kan worden
Wanneer de invoer geen veelvoud van drie bytes is, is de laatste groep van vier tekens onvolledig, en één of twee =-tekens vullen die aan. Ze dragen helemaal geen data: ze zeggen alleen hoeveel van de vier tekens echt zijn. Een decoder kan dat ook uit de lengte afleiden, en daarom laat URL-veilige Base64 traditioneel de opvulling weg — een = is lastig in een URL of bestandsnaam, en sommige systemen percent-coderen die.
Het vinkje in de optiesrij houdt de opvulling wanneer het URL-veilige alfabet is gekozen. Verder verandert er niets; de tekens die data dragen zijn in beide gevallen identiek.
Veelvoorkomende misverstanden
- "Base64 verbergt de data." Dat doet het niet. Het is een substitutie zonder sleutel, en het hele punt is dat elke lezer hem kan ongedaan maken. Een wachtwoord of token in Base64 zetten verandert niets aan wie het kan lezen.
- "Base64 comprimeert." Het tegendeel: elke drie invoerbytes worden vier uitvoertekens, dus de tekst is een derde groter dan de data die hij draagt.
- "De regelafbrekingen maken deel uit van de waarde." Ze zijn presentatie. Ze toevoegen of weghalen verandert nooit de bytes die eruit komen.
- "URL-veilig betekent een andere codering." Het is dezelfde codering met twee tekens omgewisseld:
+ wordt - en / wordt _, zodat de tekenreeks in een URL-pad of queryWaarde kan staan zonder ontsnapping. - "Een tekenreeks die decodeert, moet geldige Base64 zijn." Elke tekenreeks van alfabettekens is geldige Base64, want elke combinatie van zesbitwaarden is een geldige reeks bytes. Een tekenreeks blijkt pas fout bij de volgende stap, wanneer die bytes worden gecontroleerd tegen het formaat dat ze hadden moeten hebben.
- "Opvulling vertelt u welk alfabet is gebruikt." Dat doet het niet, en in de meeste gevallen de tekens ook niet: het standaard- en het URL-veilige alfabet zijn het eens over tweeënzestig van hun vierenzestig symbolen, dus een korte tekenreeks leest vaak op beide manieren hetzelfde.
Vragen die vaak opkomen
Waarom eindigt een Base64-tekenreeks soms met één = en soms met twee? Eén betekent dat de laatste groep drie echte tekens draagt, dat zijn twee invoerbytes; twee betekent dat hij er twee draagt, dat is één invoerbyte. Geen = betekent dat de invoerlengte een veelvoud van drie was.
Kan Base64 willekeurige binaire bestanden voorstellen? Ja, en dat is het belangrijkste gebruik. Deze pagina behandelt de invoer als UTF-8-tekst; het speciale hulpmiddel Bestand naar Base64 leest ruwe bytes wanneer u iets codeert dat geen tekst is.
Welk alfabet moet ik in een API gebruiken? Wat het ontvangende eind documenteert. Als er URL-veilig staat, gebruik dat; als er niets staat en de waarde in een URL reist, is URL-veilig zonder opvulling de veilige keuze.
Is de uitvoer hoofdlettergevoelig? Volledig. a en A zijn verschillende waarden, en daarom overleeft Base64 een verkeerd getypt teken veel minder soepel dan Base32 of Crockford Base32.
