الخلاصة

  • عالجت RFC 3548 مشكلة توافق دقيقة: كانت المواصفات تقول «base64» من دون تحديد الأبجدية أو فواصل الأسطر أو الحشو أو طريقة التعامل مع المحارف الخارجة عن الأبجدية.
  • والفكرة المحورية أن سلوك نقل الرسائل في MIME هو ملف استخدام محدد، لا عقد شامل لكل مفككات الترميز.

يمكن لمحرر النصوص فتح سلسلة Base64، ولذلك يسهل الظن أن التحويل يشرح نفسه: تدخل البايتات وتخرج محارف قابلة للطباعة، ويستطيع أي مفكك عكس العملية. لكن التاريخ الذي تسجله RFC 3548 أكثر تعقيداً. فقد تراكمت اختلافات صغيرة بين التطبيقات، بينما استُخدمت كلمة «base64» كما لو أن الاسم وحده يحسم كل الخيارات.

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

نُشرت RFC 3548 في يوليو 2003 بوصفها وثيقة Informational، وسعت إلى تقليل هذا الغموض. تشير مقدمتها إلى اختصار متكرر: مواصفات بروتوكولات تستعمل «base64» من دون وصف دقيق أو إحالة محددة، وغالباً ما تستشهد بـMIME من غير النظر إلى آثار التفاف الأسطر أو المحارف غير الأبجدية. لذلك جمعت الوثيقة أنماط Base16 وBase32 وBase64 الشائعة وأظهرت الخيارات المحيطة بها.

كان MIME مصدراً للالتباس لأنه يحدد سياقاً خاصاً. فـRFC 2045 تعرف Base64 على أنها Content-Transfer-Encoding لمحتوى الرسائل. حدّ 76 محرفاً في السطر مرتبط بذلك السياق البريدي؛ أما PEM فاستخدم 64 محرفاً في سياق آخر من الحقبة نفسها. والقاعدة العامة في RFC 3548 هي ألا يضيف المرمّز سطراً جديداً ما لم تطلبه المواصفة المُحيلة صراحة. فإذا كان الطرف الآخر قد يعدّ السطر جزءاً من البيانات أو يرفضه، فالأمر ليس تنسيقاً شكلياً.

الحشو والتسامح بدورهما من خيارات الملف. تطلب RFC 3548 إدراج الحشو المناسب ما لم تنص المواصفة المُحيلة على خلاف ذلك، وتوجب رفض المحارف الخارجة عن الأبجدية إلا إذا اختارت المواصفة سلوكاً آخر بوضوح. يستطيع MIME تجاهل تلك المحارف، ومنها CRLF، لكن ذلك استثناء خاص به. ونقل هذا السلوك إلى بروتوكول مختلف يوسّع مجموعة المدخلات المقبولة. تذكر RFC القنوات الخفية وأخطاء التنفيذ بوصفها أسباباً للحذر؛ ولا تدّعي وقوع هجوم على منتج بعينه.

وكان لا بد أيضاً من تسمية الأبجدية. يستخدم Base64 المعتاد + و/ للقيمتين 62 و63. وتوثق RFC 3548 بديلاً مناسباً لعناوين URL وأسماء الملفات يستبدلهما بـ و_. وتحذر من اعتباره الترميز نفسه أو تسميته «base64» فقط. فحقول المسارات وأسماء الملفات والمعرّفات تخضع لقيود تختلف عن متن البريد.

في أكتوبر 2006، حلت RFC 4648 محل RFC 3548 بوصفها وثيقة على مسار المعايير. وأبقت على نهج تحديد الملف، وأضافت قاعدة للترميز القانوني: يجب أن تكون بتات الحشو في Base64 وBase32 صفراً، وإلا فقد تفك سلاسل متعددة إلى البايتات نفسها. وهذه مسألة مستقلة عن التفاف أسطر MIME. وتوضح الوثيقتان معاً لماذا لا تكفي عبارة «نجح فك الترميز» لاستكمال وصف البروتوكول؛ إذ يجب أن يتفق الطرفان على الصيغة والحشو والتسامح والطبقة التي تفسر القيمة.

الترميز القاعدي ليس تشفيراً ولا مصادقة. إنه تمثيل نصي للبايتات يناسب بعض وسائل النقل. أما مساهمة RFC 3548 التاريخية فمحدودة لكنها باقية: الاسم المألوف لا يعادل مجموعة مكتملة من القواعد.

المصادر