+ بـ - و/ بـ _ ويزيل الحشو = (RFC 4648 §5).كيف يعمل
يمثّل Base64 البيانات باستخدام 64 حرفًا من أحرف ASCII القابلة للطباعة. تتحوّل كل 3 بايتات من المدخل إلى 4 أحرف، لذا تشغل النتيجة نحو 33% أكثر من الأصل.
ليس تشفيرًا ولا ضغطًا: بل ترميز قابل للعكس يستطيع أي شخص فك ترميزه. ويُستخدم لنقل البيانات الثنائية عبر قنوات مخصَّصة للنص فقط.
يستخدم البديل الآمن للروابط (RFC 4648 §5) الرمزين - و_ بدل + و/، ويحذف حشو =، حتى يمكن تضمين النتيجة في عناوين URL وأسماء الملفات دون تهريبها.
أمثلة
Hello WorldSGVsbG8gV29ybGQ=CaféQ2Fmw6k=في UTF-8 تشغل الأحرف غير ASCII أكثر من بايت، لذا يضيف "é" بايتين.>>>?estándar: Pj4+Pw== · URL-safe: Pj4-Pwيستبدل البديل الآمن للروابط + و/ بـ - و_، ويزيل حشو =.حالات الاستخدام
- تضمين الصور أو الخطوط أو الأيقونات مباشرةً في HTML/CSS عبر data URI.
- إرسال مرفقات البريد الإلكتروني (MIME) أو بيانات ثنائية داخل JSON.
- تخزين المفاتيح أو الشهادات أو الرموز في متغيرات البيئة وملفات الإعداد.
- ترميز بيانات الاعتماد لترويسة Authorization: Basic في HTTP.
الأسئلة الشائعة
هل Base64 طريقة تشفير؟
لا. إنه ترميز قابل للعكس بلا مفتاح: يستطيع أي شخص فك ترميزه. ولا يضيف أي أمان؛ ولحماية البيانات يجب تشفيرها.
لماذا تنتهي النتيجة بـ "="؟
الرمز "=" هو حشو (padding) لإكمال كتل من 4 أحرف عندما لا يكون المدخل من مضاعفات 3 بايتات. ويحذفه البديل الآمن للروابط.
متى يُفضَّل البديل الآمن للروابط؟
عندما تذهب القيمة في عنوان URL أو اسم ملف أو معرّف، لأن الحرفين + و/ لهما معنى خاص في تلك السياقات.
لماذا يكون النص المُرمَّز أطول من الأصل؟
لأنه يستخدم 4 أحرف لكل 3 بايتات من المدخل، لذا يزداد الحجم بنحو 33%.
هل يُرفَع نصي إلى خادم؟
لا. يتم الترميز وفك الترميز بالكامل في متصفحك.