ما هو Base64؟ شرح الترميز

القيم بعد فك الترميز. JVBERi0xLjcK تُفكّ إلى %PDF-1.7 يليها فاصل سطر، وهي الترويسة التي يبدأ بها ملف PDF، فـ content يحمل بايتات الملف فعلاً. وYWdlbmN5MDc6VmlzYSNUZXN0MjY= تُفكّ إلى agency07:Visa#Test26، أي اسم مستخدم الشريك وكلمة مروره. و2LPYp9ix2Kk= تُفكّ إلى الاسم العربي سارة عندما تُقرأ بايتاتها D8 B3 D8 A7 D8 B1 D8 A9 بترميز UTF-8، وإلى سارة بالضبط عندما تُقرأ البايتات نفسها بترميز Latin-1. أما مرجعا الإيصال فيُفكّ كل منهما إلى ⁦12⁩ بايتاً عشوائياً، ولا يُتوقع فيهما نص مقروء.

O1: عيب في إعدادات البوابة. يحوّل Base64 كل ثلاثة بايتات إلى أربعة أحرف، ويقرّب المجموعة الأخيرة إلى الأعلى. فأكبر ملف مسموح، ⁦5,000,000⁩ بايت، يساوي ⁦1,666,667⁩ مجموعةً، أي إن طول content ⁦6,666,668⁩ حرفاً (مع حرف حشو «=» واحد)، والجسم ⁦6,666,668 + 72 = 6,666,740⁩ بايتاً، وهذا فوق حدّ البوابة البالغ ⁦6,000,000⁩. وأكبر ملف يمرّ: يبقى لـ content ⁦6,000,000 − 72 = 5,999,928⁩ حرفاً، و⁦5,999,928 ÷ 4 = 1,499,982⁩ مجموعةً كاملة، و⁦1,499,982 × 3 = 4,499,946⁩ بايتاً. لذلك، مع ⁦72⁩ بايتاً من JSON كما في العيّنة، يُرفض كل ملف صالح حجمه من ⁦4,499,947⁩ إلى ⁦5,000,000⁩ بايت (فالملف family-book.pdf بحجم ⁦4,800,000⁩ بايت يحتاج جسماً من ⁦6,400,072⁩ بايتاً، بينما يُرمَّز birth-certificate.pdf بحجم ⁦4,200,000⁩ بايت إلى ⁦5,600,000⁩ حرف فيمرّ)، ويتلقى المتقدّم صفحة HTML من البوابة بدلاً من خطأ مفهوم. والملفات التي تتجاوز الحد تتلقى استجابة خاطئة أيضاً: فملف من ⁦5,000,001⁩ بايت يرسله نظام الشريك، الذي لا يسبقه فحص التطبيق، لا يصل إلى الخدمة أصلاً، فلا يعود الخطأ FILE_TOO_LARGE الذي يشترطه DOC-4 أبداً.

وبمصطلحات ISTQB فإن الإخفاق (Failure) هو الاستجابة 413 لملف صالح، والعيب هو حدّ لجسم الطلب ضُبط على حجم الملف الخام لا على الطلب المرمَّز. أبلغ عنه على إعدادات البوابة، مع DOC-4 أساساً للاختبار (Test basis). أما طريقة الإصلاح فقرار الفريق: رفع الحد فوق أكبر جسم مرمَّز مع هامش لأسماء الملفات الطويلة، أو رفع الملفات بصيغة ثنائية (مثل multipart/form-data) بدلاً من Base64 داخل JSON، وهذا يلغي أيضاً زيادة الثلث. وأضف ملاحظة للمطورين: الملفان بحجم ⁦5,000,000⁩ و⁦5,000,001⁩ بايت يُرمَّزان كلاهما إلى ⁦6,666,668⁩ حرفاً، لذا يجب فحص قاعدة الحجم على البايتات بعد فك الترميز، لا على طول سلسلة Base64 أبداً.

O2: عيب في تطبيق Android. فاصل السطر بعد كل ⁦76⁩ حرفاً هو التفاف الأسطر على طريقة MIME. ينص ⁦RFC 4648 §3.1⁩ على أن المرمِّزات يجب ألا تضيف فواصل أسطر ما لم تطلب ذلك المواصفة التي تستخدم Base64، والعقد لا يطلبه؛ وينص ⁦§3.3⁩ على أن مفكّك الترميز يجب أن يرفض الأحرف الخارجة عن الأبجدية ما لم تنص المواصفة على غير ذلك. فاستجابة الخدمة 400 INVALID_BASE64 صحيحة، ونجاح iOS يثبت أن الملفات نفسها سليمة. ويمكنك أن ترى نوعَي مفكّك الترميز جنباً إلى جنب: رمّز ملفاً صغيراً بأداة ترميز Base64 مع ضبط «التفاف السطر» على «76 حرفاً (MIME)»، ثم الصق الناتج في أداة فك ترميز Base64، وهي متسامحة: تتجاهل فواصل الأسطر وتذكر عدد المسافات البيضاء التي تجاهلتها. أما خدمة المستندات فصارمة، كما يطلب الـ RFC افتراضياً. الإصلاح: أن يُخرج مرمِّز Android القيمة في سطر واحد. واطلب من مالك الواجهة البرمجية أن يكتب في العقد صراحةً: «سطر واحد بلا مسافات بيضاء».

O3: عيب في طريقة بناء رابط الإيصال. المرجع الثاني يحوي «+». فالرابط يضع Base64 القياسي في سلسلة الاستعلام (Query string) دون ترميز بالنسبة المئوية، والخدمة تقرأ سلسلة الاستعلام بقواعد ترميز النماذج (Form encoding) التي يعني فيها «+» مسافة، فتستلم k7Qd2 fA9w1Z0LsE وترفضه. وأداة فك ترميز URL تعيد إنتاج ذلك: مع تفعيل «فك ترميز + كمسافة» يخرج k7Qd2+fA9w1Z0LsE بصورة k7Qd2 fA9w1Z0LsE. والمرجع الأول ينجح فقط لأنه لا يحوي «+»؛ أما «/» فيه فمسموح في سلسلة الاستعلام، لكنه سيكسر المسار لو نُقل المرجع يوماً إلى المسار نفسه. ولأن المراجع بايتات عشوائية، يبدو فشل الروابط عشوائياً أيضاً، ولهذا كثيراً ما يُبلَّغ عن هذا النوع من العيوب على أنه متقطع. الإصلاح: استخدام Base64URL ⁦(RFC 4648 §5)⁩ للمرجع، فلا تحتاج القيمتان k7Qd2-fA9w1Z0LsE وLm0x8Qp_Vt2aKc3Q إلى أي تهريب؛ أو ترميز القيمة بالنسبة المئوية فيصبح «+» هو %2B (تُظهره أداة ترميز URL)، لكن نسيان ذلك أسهل. ويجب أن تبقى الروابط المرسلة سابقاً بالبريد صالحة بعد الإصلاح: اسأل كيف ستُقبل المراجع القديمة.

O4: عيب أمني، وهو أخطر الملاحظات الست لأنه يكشف بيانات اعتماد. تُفكّ الترويسة في ثوانٍ إلى agency07:Visa#Test26، أي إن سجل البوابة يحفظ كلمة مرور الشريك بصيغة مقروءة لكل من يستطيع قراءة السجلات، والإنتاج يسجّل بالطريقة نفسها. وتعليق المطوّر خاطئ: Base64 ترميز بلا مفتاح وليس تشفيراً، وHTTPS يحمي بيانات اعتماد Basic أثناء النقل فقط، لا بعد كتابتها في سجل. أبلغ عنه بخطورة عالية، واذكر في التقرير اسم المستخدم مع إخفاء كلمة المرور. الإصلاح المتوقع: إخفاء ترويسة Authorization أو حذفها من سجل البوابة ومن أي سجل أو أداة مراقبة أخرى تسجّل الترويسات، وتغيير بيانات الاعتماد المكشوفة. اختبار التأكيد: كرّر استدعاء الشريك وتحقق من أن السجل لا يُظهر أي بيانات اعتماد؛ وفي اختبارات الانحدار افحص الترويسات الأخرى التي تحمل أسراراً، مثل مفاتيح API ورموز Bearer.

O5: عيب في النظام الداخلي. التطبيقان على صواب: 2LPYp9ix2Kk= هو ترميز UTF-8 للاسم سارة (أربعة أحرف في ثمانية بايتات). أما النظام الداخلي فيحوّل البايتات بعد فك الترميز إلى نص بترميز Latin-1، حرفاً لكل بايت، فيصبح D8 هو Ø وB3 هو ³، والنتيجة سارة؛ ويعيد إنتاجها بالضبط اختيارُ «Latin-1 / سلسلة ثنائية» في «فك ترميز النص كـ» بأداة فك ترميز Base64. وتتابُع Ø أو Ù، يلي كلاً منهما رمز آخر، علامة نموذجية على نص عربي بترميز UTF-8 قُرئ بترميز Latin-1. الإصلاح: قراءة البايتات بعد فك الترميز بترميز UTF-8. بيانات الاختبار لاختبار التأكيد ولحزمة الانحدار: اسم عربي، واسم هندي بالخط الديوناغري (ثلاثة بايتات لكل حرف في UTF-8)، واسم لاتيني فيه حرف بعلامة تشكيل مثل José (الحرف é بايتان)، واسم فيه رمز تعبيري إن كان الحقل يسمح به (أربعة بايتات)، واسم بأحرف ASCII فقط يجب أن يبقى كما هو.

O6: ليس عيباً. الحشو يتبع حجم الملف لأن Base64 يعمل على مجموعات من ثلاثة بايتات: ⁦48,211⁩ يترك باقياً قدره ⁦1⁩ عند القسمة على ⁦3⁩ فتنتهي القيمة بـ «==»، و⁦120,005⁩ يترك ⁦2⁩ فتنتهي بـ «=»، و⁦96,300⁩ يترك ⁦0⁩ فلا حشو. (طريقة سريعة للتحقق: باقي قسمة العدد على ⁦3⁩ يساوي باقي قسمة مجموع أرقامه على ⁦3⁩.) والأطوال تساوي ⁦4⁩ × (الحجم ÷ ⁦3⁩ مقرَّباً إلى الأعلى): ⁦16,071 × 4 = 64,284⁩ و⁦40,002 × 4 = 160,008⁩ و⁦32,100 × 4 = 128,400⁩، أي أكثر من كل ملف بنحو الثلث كما هو متوقع. أغلق الملاحظة بأنها ليست عيباً مع هذا الحساب، واحتفظ بالملفات الثلاثة: فهي معاً تغطي حالات الحشو كلها.

قيم اختبار حجم الملف (تحليل القيم الحدّية الثنائي). حدّ المتطلب: ⁦5,000,000⁩ بايت تُقبل بالرمز 201، و⁦5,000,001⁩ بايت تُرفض بالرمز 413 والخطأ FILE_TOO_LARGE؛ أرسل الحالتين إلى الواجهة البرمجية مباشرةً كما يفعل نظام الشريك، لا عبر التطبيق فقط. حدّ البوابة لاسم الملف في العيّنة، وهو حدّ تقني لا يذكره المتطلب: ⁦4,499,946⁩ بايتاً (الجسم ⁦6,000,000⁩ بالضبط، يُقبل) و⁦4,499,947⁩ بايتاً (الجسم ⁦6,000,004⁩، ترفضه البوابة اليوم، ويُقبل بعد إصلاح العيب). حالات الحشو: ثلاثة أحجام بواقي قسمتها على ⁦3⁩ هي ⁦0⁩ و⁦1⁩ و⁦2⁩، مثل ملفات O6. وشغّل حدّ البوابة أيضاً بأطول اسم ملف مسموح، لأن كل بايت إضافي في JSON يخفض أكبر ملف يمرّ، واسأل ماذا يتوقع DOC-4 لملف فارغ. وأبقِ الحالتين ⁦4,499,947⁩ و⁦5,000,000⁩ في حزمة الانحدار بعد الإصلاح.

اختبارات سلبية لـ content، يُتوقع في كل منها 400 INVALID_BASE64 وعدم تخزين أي شيء، بحسب نص العقد اليوم: فواصل أسطر أو مسافات داخل القيمة؛ وحرفا Base64URL «-» أو «_»؛ وحرف خارج الأبجدية مثل «*»؛ وطول ليس من مضاعفات الأربعة (بحذف الحشو)؛ وعلامة «=» في وسط القيمة. أما الملف المرمَّز مرتين فهو Base64 صالح تُفكّ بايتاته إلى نص Base64 (يبدأ بـ SlZCRVJp بدلاً من JVBERi0): ينبغي رفضه لأنه ليس PDF إن كانت الخدمة تفحص محتوى الملف مقابل mimeType، فاسأل هل تفعل. ولمرجع الإيصال: مراجع تحوي «+» و«/»، و«=» إن كان طول المراجع قد يتغير؛ ومرجع فيه مسافة؛ ومرجع مرمَّز بالنسبة المئوية (%2B)؛ ومرجع سليم الصيغة لكنه غير موجود، ويجب أن يعيد خطأً من جهة العميل (Client error)، لا 500 أبداً (ولا يحدد المقتطف أيّ خطأ، فاسأل عنه).

أسئلة لمالك الواجهة البرمجية: هل تقبل الخدمة غياب الحشو والمسافات البيضاء أم ترفضهما، وهل يمكن أن ينص العقد على ذلك صراحةً؟ ما أطول اسم ملف مسموح، بما أنه يحرّك حدّ البوابة؟ هل تتحقق الخدمة من أن البايتات بعد فك الترميز تطابق mimeType؟ هل ستنتقل مراجع الإيصالات إلى Base64URL، وكيف ستبقى الروابط المرسلة سابقاً صالحة؟ وهل Base64 داخل JSON هو القناة المناسبة أصلاً لملفات حتى ⁦5⁩ ميغابايت، مع زيادة الثلث التي يضيفها؟

إن اختلفت أرقامك فتحقق من أنك قرّبت عدد المجموعات إلى الأعلى عند حساب الطول المرمَّز وإلى الأدنى عند حساب أكبر ملف يمرّ، ومن أنك أضفت ⁦72⁩ بايتاً من JSON.