Disse tre navne beskriver relaterede binære-til-tekst-skemaer, men de tjener forskellige begrænsninger. Base64 og Base64URL bruger seks-bit grupper. Standard Base32 bruger fem-bit grupper og et mindre alfabet. Det rigtige valg er det, som din transport-, opbevarings- og modtageapplikation kan bevare nøjagtigt.
Sammenlign alfabeter før længder
Standard Base64 bruger store og små bogstaver, cifre, plus og skråstreg. Base64URL erstatter bindestreg og understregning for de sidste to tegn. Der skelnes mellem store og små bogstaver i begge. Standard RFC Base32 bruger store bogstaver A–Z og cifrene 2–7. En dekoder kan acceptere små bogstaver som en bekvemmelighed, men en protokol bør angive, om det er tilladt, og definere dens kanoniske output.
En kanal, der ikke skelner mellem store og små bogstaver, kan ødelægge en Base64 værdi, mens den bevarer en korrekt specificeret Base32. Et URL-token har andre begrænsninger end en kode, der læses højt over en telefon. Vælg ikke udelukkende efter, hvor kort en prøve ser ud.
Forstå størrelsesafvejningen
Når man ignorerer den sidste delgruppe, har Base64 brug for ca. 1,33 tegn pr. byte, og Base32 har brug for 1,6. Standard polstret Base32 udsender grupper på otte tegn for fem bytes. For en byte, der indeholder bogstavet f, er de fælles vektorer Zg== i Base64 og MY====== i Base32. Små input overdriver polstring over hovedet, så sammenlign realistiske nyttelastlængder.
Payload bytes: 66 (ASCII f)
Base64: Zg==
Base64URL: Zg== (or Zg when the protocol omits padding)
RFC Base32: MY======Bland ikke Base32 varianter
Crockford Base32 er designet omkring menneskelæselige identifikatorer og bruger et andet alfabet og flertydighedsregler end RFC Base32. Base32hex adskiller sig også. En værdi produceret af en variant kan ikke videregives blindt til en anden dekoder. Navngiv varianten, alfabetet, udfyldningspolitikken og eventuel kontrolsumsadfærd i din dokumentation.
Kodning giver heller ikke godkendelse. En forkert indtastet værdi kan stadig være syntaktisk gyldig og afkode til forskellige bytes. Hvis brugere transskriberer en kode, skal du overveje en protokoldefineret kontrolsum eller et verifikationstrin i stedet for at antage, at alfabetet fanger hver fejl.
Skriv hele kontrakten ned
Angiv inputbyte-rækkefølge, hvor det er relevant, tom-input-adfærd, førende nul-bevarelse, maksimal længde, accept af blanktegn og håndtering af ugyldige tegn. Inkluder testvektorer med bytes og partielle grupper af høj værdi. Brug din valgte koder og dekoder uafhængigt mod disse vektorer, ikke kun mod hinanden; matchende fejl kan ellers se ud til at passere en rundtur. Standardformularerne og referencevektorerne er inde RFC 4648.