شرح Base64: كيف يعمل الترميز وفكّ الترميز فعلًا

ما هو Base64 في حقيقته

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

قد تكون تلك القناة متن رسالة بريد، أو حقل JSON، أو عنوان URL، أو ترويسة HTTP، أو ملف إعداد YAML، أو ملف PEM. أرسل بايتات خامًا وسيُفسدها شيء في الطريق: بايت صفري يقطع السلسلة، و 0x0D يُعاد كتابته بتحويل نهايات الأسطر، وبايت مرتفع يُفهم على نحو آخر في ترميز محارف مختلف. يتجنّب Base64 ذلك كله لأنه لا يستخدم سوى حروف وأرقام وعلامتي ترقيم، وكلها تنجو من معاملتها كنص.

الثمن هو الحجم: المخرج أكبر من المدخل بنحو الثلث. هذه هي المقايضة، وهي تستحق في أغلب الأحوال، لأن البديل بيانات تصل تالفة.

كيف تصير ثلاث بايتات أربعة حروف

يعمل Base64 على مجموعات من ثلاث بايتات. ثلاث بايتات تساوي 24 بتًا، و24 ينقسم بالتساوي إلى أربع مجموعات من ستة. وكل مجموعة من 6 بتات تشير إلى موضع في أبجدية من 64 حرفًا، فتُنتج ثلاث بايتات داخلة أربعة حروف خارجة.

خُذ بايتات كلمة Man:

M = 77 = 01001101, a = 97 = 01100001, n = 110 = 01101110

ألصق البتات ثم أعد تقسيمها ستّات:

010011 010110 000101 101110 → 19, 22, 5, 46 → T, W, F, u

إذن تُرمَّز Man إلى TWFu. أربعة حروف، بلا حشو، لأن الثلاث بايتات انقسمت بالضبط. وهذا «انقسمت بالضبط» هو موضوع القسم التالي بالذات.

هذه الحروف الـ 64

المواضع 0–25 هي A–Z، و26–51 هي a–z، و52–61 هي 0–9، وأما 62 و63 فهما الاثنان اللذان يسبّبان كل المتاعب. وفي Base64 القياسي هما + و /.

الأبجدية، ولماذا هي اثنتان

+ و/ مقبولان تمامًا في متن رسالة، ومعاديان صراحةً داخل عنوان URL. فـ/ فاصل مسار، و+ يعني مسافة في سلسلة استعلام، لذا فإن قيمة Base64 تُلصق في عنوان قد تعود ببايتات مختلفة ودون أي خطأ في أي مكان.

ومن هنا جاء base64url، وهو صيغة تُبقي الحروف الـ 62 الأولى وتستبدل الأخيرين: - بدل + و_ بدل /. وهي الصيغة التي تستخدمها رموز JSON Web Token — فإن قرأت رمز JWT يدويًا يومًا فقد قرأت base64url — وكل ما يسافر في عنوان أو في اسم ملف.

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

الحشو، ولماذا تختلف المفكّكات حوله

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

• 3 بايتات → 4 حروف، بلا حشو
• بايتان → 3 حروف + =
• بايت واحد → حرفان + ==

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

المشكلة العملية

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

Base64 ليس تشفيرًا

يستحق هذا قسمًا خاصًا لأن الخطأ شائع جدًا ومكلف جدًا. ليس لـ Base64 مفتاح. ولا يخفي شيئًا. وعكسه نداء دالة واحد، متاح في كل لغة وفي كل صفحة كهذه.

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

وينطبق هذا على حمولة رمز JWT، وعلى كتلة Base64 في ملف إعداد، وعلى مفتاح API «أخفاه» أحدهم قبل دفعه إلى المستودع. فإن كان كل ما يقف بين مهاجم وسرّك هو Base64، فلا شيء يقف بين مهاجم وسرّك. ودليلنا لفكّ ترميز JSON Web Token وتتبّع أخطائه يمضي أبعد في معنى ذلك للرموز تحديدًا.

أين تلتقي Base64 فعلًا

وبمجرد أن تعرف شكلها تراها في كل مكان:

• مرفقات البريد. ينقل MIME البيانات الثنائية بهذه الطريقة منذ أوائل التسعينيات، مكسورةً عند 76 حرفًا في السطر.
• data: URI. صورة صغيرة مدمجة في CSS أو HTML بالشكل data:image/png;base64,…، تُبادل طلب HTTP بزيادة الثلث في البايتات.
• ملفات PEM. الشهادات والمفاتيح بين علامتي -----BEGIN… هي Base64 لصيغة DER الكامنة تحتها، مكسورةً عند 64 حرفًا.
• رموز JWT. الترويسة والحمولة JSON بترميز base64url، والتوقيع base64url لبايتات خام.
• مصادقة Basic وبعض بيانات اعتماد الـ API. كما سبق، وبالتحذير نفسه.
• بيانات ثنائية داخل JSON. لا نوع «بايت» في JSON، فتسافر البايتات كسلسلة Base64.

لماذا يحتوي بعض Base64 على كسور أسطر

يكسر MIME عند 76 حرفًا و PEM عند 64، لأن الصيغتين التي يعيشان فيهما أقدم من الأسطر الطويلة. وهذه الكسور ليست من البيانات، وعلى المفكّك أن يُهملها. ومعظمها يفعل؛ وقليلها لا يفعل، ولهذا قد يفشل لصق متن PEM مكسور في مفكّك متشدّد حتى تحذف كسور الأسطر.

تكلفة الحجم، ومتى تهم

أربعة حروف لكل ثلاث بايتات تعني توسّعًا بمقدار 4/3 — نحو 33 % — قبل الحشو وكسور الأسطر. وهذا بلا أثر لقيمة إعداد تُكتب مرة واحدة. أما لأي شيء على مسار ساخن فليس كذلك.

صورة بحجم 10 ك.ب مدمجة كـ data: URI تكلّف نحو 13.3 ك.ب من HTML، وبخلاف صورة حقيقية لا يمكن تخزينها مؤقتًا على حدة ولا تحميلها متأخرًا. والرمز الذي يُرسل مع كل نداء API يحمل زيادته في كل طلب. والضغط لن ينجيك: فمخرج Base64 يُضغط أسوأ بكثير من البايتات الأصلية، لأن الترميز يهدم الأنماط على مستوى البايت التي يبحث عنها الضاغط. اضغط أولًا ثم رمّز — لا العكس أبدًا.

ترميز النص يعني ترميز البايتات

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

وعمليًا الجواب هو UTF-8، وواجهات البرمجة الحديثة تعتمده افتراضيًا. لكن إن رمّز طرف النص بـ UTF-16 أو Latin-1 وفكّه الطرف الآخر على أنه UTF-8، فإن Base64 يكون صالحًا تمامًا والنص الخارج حروفًا مشوّهة. والدليل أن المحارف غير ASCII تنجو بشكل سيئ بينما ينجو ASCII الصريح تمامًا، لأن ASCII جزء من UTF-8.

اختبار الذهاب والعودة

إن لم تكن واثقًا أن مسار معالجتك يتعامل مع النص صحيحًا، فرمّز سلسلة فيها حرف بعلامة وحرف غير لاتيني، ثم فكّها وقارن. فكل ما يُفسد José أو رمزًا تعبيريًا يفقد معلومات في مكان ما من التحويل إلى بايتات، لا في Base64 نفسه.

عندما يفشل فكّ الترميز

أربعة تشخيصات تغطي كل الحالات تقريبًا:

• «حرف غير صالح». دخل شيء من خارج الأبجدية — غالبًا مسافة شاردة، أو علامة تنصيص نُسخت مع السلسلة، أو بادئة data:image/png;base64, بقيت في المقدمة.
• «طول غير صالح». بعد حذف الفراغات يصبح الطول بباقي أربعة يساوي 1، وهذا ما لا ينتجه أي Base64 صالح. أي أن حرفًا ضاع في الطريق.
• يُفكّ لكن إلى حروف مشوّهة. فإما أن الأبجديتين غير متوافقتين (base64url فُكّ على أنه قياسي أو العكس)، أو أن ترميز المحارف غير متوافق كما وُصف أعلاه.
• يُفكّ إلى بايتات ليست نصًا أصلًا. وهذا ليس خطأ. فكثير من Base64 يحمل صورة أو مفتاحًا أو بنية مُسلسلة؛ والمفكّك الجيد يعرض لك هيئة ست عشرية بدل التظاهر بأن الناتج سلسلة نصية.

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

أدوات وأدلة ذات صلة:

• مرمّز ومفكّك ترميز Base64 — رمّز النص إلى Base64 أو فكّ ترميزه، بمخرج آمن للعناوين ومعالجة صحيحة لـ UTF-8.
• مفكّك ترميز JWT — فكّ ترميز أي JSON Web Token واقرأ ترويسته وحمولته ومطالباته وتاريخ انتهائه.
• شرح JWT: كيف تفكّ ترميز JSON Web Token وتصلح أخطاءه — ما يحتويه JSON Web Token

أسئلة شائعة