على عكس النص العربي، لا يتأثر Base32 إطلاقًا باتجاه الكتابة — فناتجه دائمًا سلسلة من الأحرف اللاتينية الكبيرة والأرقام تُقرأ من اليسار إلى اليمين بغض النظر عن لغة المستند الأصلي أو اتجاه الصفحة المحيطة به.
أين يظهر Base32 عمليًا
عند إعداد تطبيق مصادقة ثنائية مثل Google Authenticator يدويًا دون مسح رمز QR، يعرض التطبيق "مفتاح إعداد" لكتابته يدويًا — وهذا المفتاح مُرمَّز بـ Base32 وليس Base64، لأن المعيار يشترط ذلك تحديدًا لتسهيل النسخ اليدوي دون التباس.
أبجدية مصمَّمة لتفادي الالتباس عند النطق
يستبعد Base32 الرقمين 0 و1 والحرفين O وI تمامًا — وهي بالضبط الرموز التي يسهل الخلط بينها عند قراءتها بصوت عالٍ عبر الهاتف أو على شاشة صغيرة الدقة. بما أن الأرقام العربية الشرقية (٠١٢٣) تُستخدم أحيانًا جنبًا إلى جنب مع الأرقام اللاتينية في الكتابة العربية، فإن أي التباس إضافي بين الحرف والرقم يصبح مصدر خطأ حقيقيًا عند إملاء الرمز — وهذا بالضبط ما يتجنبه Base32 من جذوره.
حالات استخدام شائعة
- عناوين شبكة Tor بامتداد onion. — الجزء المكوّن من 56 حرفًا هو مفتاح Ed25519 عام مُرمَّز بـ Base32.
- تسميات DNS والنطاقات الفرعية، التي لا تفرّق بين حالة الأحرف وفق المعيار.
- رموز الإحالة أو القسائم المطبوعة على إيصال ورقي، والتي يُعاد كتابتها يدويًا على موقع إلكتروني.
ثمن سهولة القراءة: نص أطول
وجود عدد أقل من الرموز في الأبجدية يعني أن كل بايت يحتاج إلى عدد أكبر من الأحرف لتمثيله — الناتج أطول بنحو 60% مقارنة بـ Base64. لمفتاح سري من 20 بايت هذا فارق بسيط لا يُذكر، لكنه يجعل Base32 خيارًا غير عملي لملف حجمه عدة ميغابايت.
Base32 وBase32hex ليسا قابلين للتبادل
يُعرّف معيار RFC 4648 أيضًا صيغة Base32hex التي تستخدم الأبجدية 0–9A–V بدلاً من A–Z2–7، وتحافظ على ترتيب الفرز الأبجدي للسلاسل مطابقًا لترتيب البايتات الأصلية — وهي خاصية تعتمد عليها بعض قواعد البيانات. السلسلة المُرمَّزة بإحدى الصيغتين لا تُفك بشكل صحيح بالأخرى، لذا يستحسن التأكد من الصيغة المطلوبة قبل فك الترميز.