Dessa tre namn beskriver relaterade binära-till-text-scheman, men de tjänar olika begränsningar. Base64 och Base64URL använder sex-bitars grupper. Standard Base32 använder fem-bitars grupper och ett mindre alfabet. Rätt val är det som din transport-, lagrings- och mottagningsapplikation kan bevara exakt.
Jämför alfabet före längder
Standard Base64 använder stora och små bokstäver, siffror, plus och snedstreck. Base64URL ersätter bindestreck och understreck för de två sista tecknen. Båda är skiftlägeskänsliga. Standard RFC Base32 använder versaler A–Z och siffror 2–7. En avkodare kan acceptera gemener som en bekvämlighet, men ett protokoll bör ange om det är tillåtet och definiera dess kanoniska utdata.
En skiftlägesokänslig kanal kan förstöra ett Base64-värde samtidigt som ett korrekt specificerat Base32-värde bevaras. En URL token har andra begränsningar än en kod som läses upp över en telefon. Välj inte enbart efter hur kort ett prov ser ut.
Förstå storleksavvägningen
Om man ignorerar den sista partiella gruppen behöver Base64 ungefär 1,33 tecken per byte och Base32 behöver 1,6. Standard vadderade Base32 avger grupper med åtta tecken för fem byte. För en byte som innehåller bokstaven f är de vanliga vektorerna Zg== i Base64 och MY====== i Base32. Små ingångar överdriver stoppning över huvudet, så jämför realistiska nyttolastlängder.
Payload bytes: 66 (ASCII f)
Base64: Zg==
Base64URL: Zg== (or Zg when the protocol omits padding)
RFC Base32: MY======Blanda inte Base32 varianter
Crockford Base32 är designad kring mänskligt läsbara identifierare och använder ett annat alfabet och tvetydighetsregler från RFC Base32. Base32hex skiljer sig också. Ett värde som produceras av en variant kan inte lämnas blint till en annan avkodare. Namnge varianten, alfabetet, utfyllnadspolicyn och eventuella kontrollsummor i din dokumentation.
Kodning ger inte heller autentisering. Ett felskrivet värde kan fortfarande vara syntaktisk giltigt och avkoda till olika byte. Om användare transkriberar en kod, överväg en protokolldefinierad kontrollsumma eller verifieringssteg snarare än att anta att alfabetet fångar varje fel.
Skriv ner hela kontraktet
Ange indatabyteordning där det är relevant, tom-inmatningsbeteende, inledande-nollbevarande, maximal längd, blankstegsacceptans och ogiltiga teckenhantering. Inkludera testvektorer med högt värdefulla bytes och partiella grupper. Använd din valda kodare och avkodare oberoende mot dessa vektorer, inte bara mot varandra; matchande buggar kan annars tyckas passera en tur och retur. Standardformulären och referensvektorerna finns i RFC 4648.