Deze drie namen beschrijven gerelateerde binaire-naar-tekst-schema's, maar ze hebben verschillende beperkingen. Base64 en Base64URL gebruiken groepen van zes bits. Standaard Base32 gebruikt groepen van vijf bits en een kleiner alfabet. De juiste keuze is degene die uw transport-, opslag- en ontvangsttoepassing precies kan behouden.
Vergelijk alfabetten vóór lengtes
Standaard Base64 gebruikt hoofdletters en kleine letters, cijfers, plus en schuine streep. Base64URL vervangt streepje en onderstrepingsteken voor de laatste twee tekens. Beide zijn hoofdlettergevoelig. Standaard RFC Base32 gebruikt hoofdletters A–Z en cijfers 2–7. Een decoder kan voor het gemak kleine letters accepteren, maar een protocol moet aangeven of dat is toegestaan en de canonieke uitvoer ervan definiëren.
Een hoofdletterongevoelig kanaal kan een Base64-waarde vernietigen, terwijl een correct gespecificeerde Base32-waarde behouden blijft. Een URL-token heeft andere beperkingen dan een code die via een telefoon wordt voorgelezen. Kies niet louter op basis van hoe kort een monster eruit ziet.
Begrijp de afweging tussen afmetingen
Als we de laatste gedeeltelijke groep negeren, heeft Base64 ongeveer 1,33 tekens per byte nodig en Base32 1,6. Standaard opgevulde Base32 zendt groepen van acht tekens uit voor vijf bytes. Voor één byte die de letter f bevat, zijn de gemeenschappelijke vectoren Zg== in Base64 en MY====== in Base32. Kleine inputs overdrijven de overheadkosten, dus vergelijk realistische payloadlengtes.
Payload bytes: 66 (ASCII f)
Base64: Zg==
Base64URL: Zg== (or Zg when the protocol omits padding)
RFC Base32: MY======Meng geen Base32 varianten
Crockford Base32 is ontworpen rond voor mensen leesbare identificatiegegevens en gebruikt een ander alfabet en ambiguïteitregels dan RFC Base32. Base32hex verschilt ook. Een waarde die door de ene variant wordt geproduceerd, kan niet blindelings aan een andere decoder worden doorgegeven. Noem de variant, het alfabet, het opvulbeleid en eventueel controlesomgedrag in uw documentatie.
Codering biedt ook geen authenticatie. Een verkeerd getypte waarde kan nog steeds syntactisch geldig zijn en naar verschillende bytes worden gedecodeerd. Als gebruikers een code transcriberen, overweeg dan een in het protocol gedefinieerde controlesom of verificatiestap in plaats van aan te nemen dat het alfabet elke fout opvangt.
Schrijf het volledige contract op
Specificeer waar relevant de volgorde van de invoerbytes, het gedrag bij lege invoer, behoud van voorloopnul, maximale lengte, acceptatie van witruimte en afhandeling van ongeldige tekens. Neem testvectoren op met bytes en gedeeltelijke groepen van hoge waarde. Gebruik de door u gekozen encoder en decoder onafhankelijk van elkaar tegen die vectoren, niet alleen tegen elkaar; overeenkomende bugs kunnen anders een rondreis lijken te passeren. De standaardformulieren en referentievectoren zijn binnen RFC 4648.