Base32'nin tek amacı şu: bir kod sesli okunacaksa, telefonda söylenecekse ya da elle yeniden yazılacaksa, 32 karakterlik bir alfabe, Base64'ün 64 karakterine göre çok daha az hataya yol açar.
Türkçe'de "I" harfinin klasik tuzağı — ve Base32'nin bundan neden etkilenmediği
Türkçe klavyelerde ve yazılımlarda ünlü bir hata vardır: "i".toUpperCase() Türkçe yerel ayarında (locale) beklenmedik şekilde noktalı "İ" üretir, çünkü Türkçe alfabesinde noktalı ve noktasız I birbirinden bağımsız iki harftir. Base32 bu tuzağa hiç girmez — alfabesi zaten sabit bir ASCII harf kümesidir (A–Z, 2–7) ve kodun kendisi hiçbir zaman yerel ayara duyarlı büyütme/küçültme işleminden geçmez, sadece bayt bayt eşlenir.
QR kodu okunamayınca ortaya çıkan Base32
Google Authenticator gibi bir uygulama QR kodu tarayamadığında, elle girilecek bir "kurulum anahtarı" gösterir — bu anahtar Base32'dir, Base64 değil. TOTP standardı bunu özellikle şart koşar, çünkü format telefonda harf harf okunduğunda bile karışıklığa yol açmayacak şekilde tasarlanmıştır.
Pratikte nerede karşımıza çıkar
- Tor ağındaki .onion adresleri — 56 karakterlik alt alan adı, Ed25519 açık anahtarının Base32 ile kodlanmış hâlidir.
- Büyük/küçük harf ayrımı yapmayan DNS etiketleri ve alt alan adları.
- Kağıt fişte basılı referans veya kupon kodları — müşterinin bir web sitesine elle yeniden yazması gereken kodlar.
Okunabilirliğin bedeli: daha uzun dizeler
Daha az sembol, her bayt için daha fazla karakter demektir — sonuç Base64'e göre yaklaşık %60 daha uzundur. 20 baytlık bir gizli anahtar için bu fark önemsizdir; birkaç megabaytlık bir dosya için ise Base32 kullanmak pratik değildir.
Base32 ile Base32hex birbirinin yerine geçmez
RFC 4648, A–Z2–7 yerine 0–9A–V alfabesini kullanan Base32hex'i de tanımlar; bu varyant, kodlanmış dizelerin sıralama düzenini orijinal baytların sıralamasıyla aynı tutar — bazı veritabanları için önemli bir özellik. Bir varyantla kodlanan dize diğeriyle doğru şekilde çözülmez, bu yüzden çözmeden önce hangi varyantın kullanıldığını doğrulamak gerekir.