Te trzy nazwy opisują powiązane schematy zamiany binarnej na tekst, ale mają różne ograniczenia. Base64 i Base64URL używają grup sześciobitowych. Standard Base32 wykorzystuje grupy pięciobitowe i mniejszy alfabet. Właściwy wybór to ten, który może dokładnie zachować Twoja aplikacja do transportu, przechowywania i odbioru.
Porównaj alfabety przed długościami
Standard Base64 używa wielkich i małych liter, cyfr, plusów i ukośników. Base64URL zastępuje myślnik i podkreślenie ostatnich dwóch znaków. W obu przypadkach rozróżniana jest wielkość liter. Standard RFC Base32 używa wielkich liter A–Z i cyfr 2–7. Dekoder może dla wygody akceptować małe litery, ale protokół powinien określać, czy jest to dozwolone i definiować jego kanoniczny wynik.
Kanał niewrażliwy na wielkość liter może zniszczyć wartość Base64, zachowując prawidłowo określoną wartość Base32. Token URL ma inne ograniczenia niż kod odczytywany na głos przez telefon. Nie wybieraj wyłącznie na podstawie tego, jak krótka jest próbka.
Zrozumienie kompromisu w zakresie rozmiaru
Pomijając ostatnią grupę częściową, Base64 potrzebuje około 1,33 znaku na bajt, a Base32 potrzebuje 1,6. Standardowo dopełniony Base32 emituje grupy ośmioznakowe dla pięciu bajtów. Dla jednego bajtu zawierającego literę f wspólnymi wektorami są Zg== w Base64 i MY====== w Base32. Małe dane wejściowe powodują nadmierne obciążenie wypełniania, więc porównaj realistyczne długości ładunku.
Payload bytes: 66 (ASCII f)
Base64: Zg==
Base64URL: Zg== (or Zg when the protocol omits padding)
RFC Base32: MY======Nie mieszać wariantów Base32
Crockford Base32 został zaprojektowany w oparciu o identyfikatory czytelne dla człowieka i wykorzystuje inny alfabet i zasady niejednoznaczności z RFC Base32. Base32hex również się różni. Wartości wytworzonej przez jeden wariant nie można ślepo przekazać innemu dekoderowi. Nazwij wariant, alfabet, zasady dopełniania i wszelkie zachowanie sumy kontrolnej w swojej dokumentacji.
Kodowanie również nie zapewnia uwierzytelnienia. Błędnie wpisana wartość może nadal być poprawna składniowo i zostać zdekodowana do różnych bajtów. Jeśli użytkownicy dokonują transkrypcji kodu, rozważ użycie sumy kontrolnej lub etapu weryfikacji zdefiniowanego w protokole, zamiast zakładać, że alfabet wyłapie każdy błąd.
Zapisz całą umowę
Określ kolejność bajtów wejściowych, jeśli ma to zastosowanie, zachowanie pustych danych wejściowych, zachowanie zera wiodącego, maksymalną długość, akceptowanie białych znaków i obsługę nieprawidłowych znaków. Dołącz wektory testowe z bajtami o dużej wartości i grupami częściowymi. Używaj wybranego kodera i dekodera niezależnie przeciwko tym wektorom, a nie tylko przeciwko sobie; w przeciwnym razie pasujące błędy mogą sprawiać wrażenie, że przechodzą w obie strony. Dostępne są standardowe formy i wektory odniesienia RFC 4648.