ما هو ترميز Base64 ولماذا ما زالت البرمجيات تعتمد عليه؟

يصادف المطوّرون Base64 غالبًا قبل أن يشرح لهم أحد سبب وجوده أصلًا. فهو يظهر في مرفقات البريد الإلكتروني، وفي روابط البيانات داخل صفحات الويب، وفي ردود واجهات البرمجة، وفي رموز المصادقة، وفي ملفات الإعدادات، وفي مقاطع منسوخة تبدأ بجدار كثيف من الأحرف والأرقام. تبدو هذه المخرجات وكأنها مشفّرة، لكنها ليست كذلك. وتبدو وكأنها مضغوطة، رغم أنها في العادة أكبر حجمًا من الأصل. أما غرضها الحقيقي فأقل إثارة وأكثر عملية: يتيح Base64 للبيانات الثنائية أن تعبر أنظمة صُمّمت في الأساس للتعامل مع النصوص فقط. وحين تفهم هذا الغرض الوحيد البسيط، تتكشّف أمامك كل تفاصيله الغريبة وتصبح منطقية تمامًا.

المشكلة التي وُجد Base64 لحلّها

يخزّن الحاسوب كل ملف على هيئة بايتات. فالصورة الفوتوغرافية، وملف PDF، وأرشيف مضغوط، ومستند نصي، كلها في جوهرها سلاسل من الأرقام تتراوح بين صفر ومئتين وخمسة وخمسين. تستطيع كثير من البروتوكولات الحديثة نقل هذه البايتات مباشرة، لكن أنظمة قديمة أو موجّهة للنص لا تستطيع ذلك بموثوقية. فبعضها يحجز قيمًا معيّنة لأحرف التحكّم، وبعضها يتوقّع ترميزًا محرفيًا بعينه، وبعضها يبدّل نهايات الأسطر أو يرفض البيانات غير القابلة للطباعة.

يبني Base64 تمثيلًا آمنًا عبر ترجمة البايتات العشوائية إلى أبجدية صغيرة من الأحرف الاعتيادية. يستعمل Base64 القياسي الحروف اللاتينية الكبيرة والصغيرة، والأرقام، وعلامتي الجمع والشرطة المائلة، وأحيانًا علامة المساواة للحشو. هذه الأحرف تنجو من حقول النصوص، والسجلّات، وسلاسل JSON، وكثير من طبقات النقل دون أن يُساء فهمها على أنها بيانات تحكّم ثنائية. وهكذا يصبح ممكنًا حمل أيّ ملف، مهما كان نوعه، داخل قناة لا تقبل سوى النص المطبوع.

كيف تتحوّل البايتات إلى أحرف Base64

يأتي الاسم من حجم الأبجدية: أربعة وستون رمزًا ممكنًا. لذا يستطيع حرف Base64 الواحد تمثيل ست بتات، لأن لست خانات ثنائية أربعة وستين احتمالًا. يقرأ المُرمِّز البيانات المصدر في مجموعات من ثلاثة بايتات، أي أربعًا وعشرين بتًا، ثم يقسّمها إلى أربع مجموعات من ست بتات لكل منها. وكل قيمة من ست بتات تختار حرفًا واحدًا من أبجدية Base64.

لنتأمل كلمة Man. في ترميز ASCII تشغل أحرفها الثلاثة ثلاثة بايتات بالضبط. يعيد Base64 تنظيم بتاتها الأربع والعشرين في أربع قيم بست بتات لينتج TWFu. لم يُخفَ شيء ولم يؤمَّن رياضيًا؛ فقد أُعيد تجميع البتات نفسها بصورة مختلفة فحسب. وأيّ شخص لديه فاكّ ترميز يستطيع استعادة البايتات الأصلية تمامًا. هذه الشفافية التامّة جوهرية لفهم الصيغة: فهي إعادة تنظيم، لا تحويل سرّيّ ولا عملية لا رجعة فيها.

لماذا يظهر الحشو في النهاية

لا تنقسم البيانات المدخلة دائمًا انقسامًا نظيفًا إلى مجموعات من ثلاثة بايتات. فحين يتبقّى بايت أو بايتان، يظلّ المُرمِّز بحاجة إلى التعبير عنهما بأحرف Base64 ذات الست بتات. يضيف Base64 القياسي عندئذ علامة مساواة واحدة أو علامتين في النهاية لإظهار أن المجموعة الأخيرة كانت غير مكتملة. والحشو يجعل طول الناتج المُرمَّز من مضاعفات الأربعة، ويساعد فاكّ الترميز على إدراك أين تنتهي البيانات ذات المعنى.

تتخلّى بعض الصِّيَغ عن الحشو لأنه يمكن استنتاج الطول. فمثلًا Base64URL، وهو النوع المستعمل في رموز JSON Web Tokens، يحذف غالبًا علامات المساواة الزائدة. لا يغيّر ذلك الفكرة الجوهرية، لكنه يعني أن فاكّ الترميز قد يحتاج إلى استعادة الحشو قبل استعمال تطبيق صارم لمعيار Base64. وكثير من العلل في الممارسة تنبع تحديدًا من اختلاف الأطراف حول وجود الحشو أو غيابه، وهو خلاف يبدو تافهًا لكنه يكسر التحليل.

كلفة جعل البيانات الثنائية نصيّة

يحسّن Base64 التوافق مقابل زيادة في الحجم. فثلاثة بايتات مصدرية تصير أربعة أحرف نصية، ما يعني أن التمثيل المُرمَّز أكبر بنحو الثلث قبل احتساب فواصل الأسطر أو الترميز المحيط. قد يكون ترميز أيقونة صغيرة داخل ملف CSS أمرًا مريحًا، أما ترميز مقطع فيديو كبير داخل JSON فمضيعة في الغالب، وأصعب في البثّ، وأكلف في التحليل.

قد يخفّف الضغط من هذه الكلفة الإضافية حين توجد أنماط متكرّرة، لكنه لا يجعل Base64 مجانيًا. ينبغي للأنظمة أن تستعمله حين تتطلّب حدودٌ نصيّة بحتة ذلك فعلًا، لا أن تجعله بديلًا افتراضيًا عن رفع الملفات أو عن أجسام الردود الثنائية أو عن تخزين الكائنات. ومع تكرار البيانات نفسها في كل طلب، تتراكم هذه الزيادة بسرعة وتتحوّل من تفصيل هيّن إلى كلفة حقيقية في عرض النطاق والتخزين معًا.

أين يكون Base64 مفيدًا فعلًا

البريد الإلكتروني مثال كلاسيكي. يستعمل معيار MIME ترميز Base64 كي تمرّ المرفقات عبر بنية بريدية كانت تتوقّع تاريخيًا أحرفًا قابلة للطباعة. وتستعمل صفحات الويب روابط البيانات لتضمين صور أو خطوط صغيرة مباشرة في HTML وCSS. وتستعمل واجهات البرمجة أحيانًا Base64 لقيم ثنائية صغيرة داخل JSON الذي لا يملك نوعًا أصيلًا للبايتات. كما تُغلَّف الشهادات والمفاتيح ومواد التعمية الأخرى في نصّ PEM يحتوي على Base64 بين سطري ترويسة وتذييل مقروءين.

يحلّ Base64URL مشكلة نقل ذات صلة. فمعيار Base64 يضمّ علامة الجمع والشرطة المائلة اللتين لهما معنى خاص في الروابط، وقد تكون علامة المساواة محرجة في معاملات الاستعلام. تستبدل الأبجدية الآمنة للروابط هذين الحرفين بالشرطة والشرطة السفلية، وتُسقط الحشو غالبًا. وتستعمل ترويسات JWT وحمولاتها هذا النوع كي يعبر كل جزء من الرمز بنظافة في ترويسات HTTP وفي الروابط. القاسم المشترك بين كل هذه الأمثلة أن الحدّ الذي تعبره البيانات نصيّ بطبيعته، وهنا بالضبط يبرع Base64.

ما لا يوفّره Base64

أخطر مفهوم خاطئ هو ظنّ أن Base64 يحمي المعلومات. فهو لا يوفّر سرّية، ولا سلامة، ولا أصالة، ولا أمان كلمات مرور. قد تبدو سلسلة Base64 غير مألوفة لإنسان، لكن فكّ ترميزها فوريّ ولا يتطلّب أيّ سرّ. إن وضع بيانات اعتماد أو معلومات شخصية في مُرمِّز Base64 يكافئ تغيير صيغتها، لا إقفالها في خزانة. وكثير من الثغرات الأمنية نشأت من فريق ظنّ أن قيمة ما "محميّة" لمجرّد أنها مُرمَّزة.

كما أن Base64 لا يتحقّق من معنى البيانات المفكوكة. فبإمكان فاكّ الترميز أن يقرّر ما إذا كانت الأحرف تنتمي إلى الأبجدية المتوقّعة، لكن البايتات الناتجة قد تظلّ تالفة أو خبيثة أو بصيغة ملف خاطئة. لذا يجب على التطبيقات أن تفرض حدودًا للحجم على نحو مستقل، وأن تتحقّق من التواقيع أو من قيم التجزئة عند الاقتضاء، وأن تعامل المحتوى المفكوك بوصفه مدخلًا غير موثوق يجب التحقّق منه قبل استعماله.

طريقة عملية للتفكير فيه

يُفهَم Base64 خير فهم بوصفه تغليفًا. فهو يأخذ بايتات قد يصعب حملها عبر قناة نصيّة، ويضعها في حاوية نصيّة متوقّعة. الحاوية أكبر حجمًا، وسهلة الفتح، ولا تقدّم أيّ أمان بذاتها. وهذه المقايضة تستحقّ العناء حين يكون التوافق أهمّ من الإيجاز. هذا التشبيه البسيط يلتقط جوهر الصيغة كله: غلاف مريح يحمل المحتوى عبر حدود لا تقبله خامًا.

عند الحسم في استعمال Base64 ابدأ من الحدّ الذي يجب أن تعبره البيانات. فإن كان الحدّ يقبل بيانات ثنائية، أرسل بيانات ثنائية. وإن كان لا يقبل سوى النص وكانت الحمولة صغيرة على نحو معقول، فإن Base64 جسر موثوق. هذه القاعدة البسيطة تفسّر طول عمر الصيغة وكثرة المواقف التي ينبغي تجنّبها فيها معًا، وتحوّل قرار استعماله من عادة إلى اختيار واعٍ يخدم تصميمك.