Disse tre navnene beskriver relaterte binær-til-tekst-skjemaer, men de tjener forskjellige begrensninger. Base64 og Base64URL bruker seks-bits grupper. Standard Base32 bruker fem-bits grupper og et mindre alfabet. Det riktige valget er det som transport-, lagrings- og mottaksapplikasjonen din kan bevare nøyaktig.
Sammenlign alfabeter før lengder
Standard Base64 bruker store og små bokstaver, sifre, pluss og skråstrek. Base64URL erstatter bindestrek og understrek for de to siste tegnene. Begge skiller mellom store og små bokstaver. Standard RFC Base32 bruker store bokstaver A–Z og sifrene 2–7. En dekoder kan godta små bokstaver som en bekvemmelighet, men en protokoll bør angi om det er tillatt og definere dens kanoniske utdata.
En kanal som ikke skiller mellom store og små bokstaver, kan ødelegge en Base64 verdi samtidig som den beholder en riktig spesifisert Base32. Et URL-token har andre begrensninger enn en kode som leses høyt over en telefon. Ikke velg utelukkende etter hvor kort prøven ser ut.
Forstå størrelsesavveiningen
Hvis du ignorerer den siste delgruppen, trenger Base64 omtrent 1,33 tegn per byte og Base32 trenger 1,6. Standard polstret Base32 sender ut grupper på åtte tegn for fem byte. For en byte som inneholder bokstaven f, er de vanlige vektorene Zg== i Base64 og MY====== i Base32. Små innganger overdriver polstring over hodet, så sammenlign realistiske nyttelastlengder.
Payload bytes: 66 (ASCII f)
Base64: Zg==
Base64URL: Zg== (or Zg when the protocol omits padding)
RFC Base32: MY======Ikke bland Base32 varianter
Crockford Base32 er designet rundt menneskelesbare identifikatorer og bruker et annet alfabet og tvetydighetsregler enn RFC Base32. Base32hex er også forskjellig. En verdi produsert av en variant kan ikke overlates blindt til en annen dekoder. Navngi varianten, alfabetet, utfyllingspolicyen og eventuell kontrollsum-atferd i dokumentasjonen.
Koding gir heller ikke autentisering. En feiltastet verdi kan fortsatt være syntaktisk gyldig og dekode til forskjellige byte. Hvis brukere transkriberer en kode, bør du vurdere en protokolldefinert kontrollsum eller verifiseringstrinn i stedet for å anta at alfabetet fanger opp hver feil.
Skriv ned hele kontrakten
Spesifiser inndatabyte-rekkefølge der det er relevant, tom-input-atferd, førende-null-bevaring, maksimal lengde, tomromsgodkjenning og håndtering av ugyldige tegn. Inkluder testvektorer med høyverdige byte og delgrupper. Bruk din valgte koder og dekoder uavhengig mot disse vektorene, ikke bare mot hverandre; matchende feil kan ellers se ut til å passere en tur-retur. Standardskjemaene og referansevektorene er inne RFC 4648.