ترميز وفك ترميز Base64: ما هو ومتى تستخدمه

Base64 طريقة لتمثيل أي بايتات باستخدام 64 حرفاً قابلاً للطباعة فقط: الحروف الكبيرة A–Z والصغيرة a–z، والأرقام 0–9، والرمزان + و /، مع استخدام = كحشوٍ في النهاية. تُدخل نصاً فتحصل على سلسلة أطول مكوّنة من تلك الحروف. وتُدخل تلك السلسلة فتستعيد البايتات الأصلية بعينها.

ووُجد لأن جزءاً كبيراً من العالم لا يزال ينتظر نصاً لا بايتات — ومجموعة فرعية محددة من النص أصلاً. فالبيانات الثنائية الخام مليئة بحروف التحكم والبايتات الصفرية والقيم العالية التي تتشوّه أو يُرفض قبولها بمجرد أن تعبر نظاماً صُمِّم لـ ASCII. وBase64 يترجم كل ذلك إلى حروف تنجو من تلك الرحلة.

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

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

لماذا وُجد Base64 أصلاً؟

المشكلة أقدم من الويب. فالبريد الإلكتروني صُمِّم لحمل نص ASCII بسيط. وحين أراد الناس إرسال صورة أو برنامج مُترجم من خلاله، أحدثت البايتات الخام فوضى: تُقرأ البايتة بقيمة 10 على أنها سطر جديد، وتُنهي البايتة الصفرية الرسالة قبل أوانها، وتُعاد تعريف القيم فوق 127 بحسب النظام الذي يستقبلها. فالرسالة التي تصل لم تكن الرسالة التي أُرسلت.

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

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

الأبجدية، والحشو، وعبء الـ33%

الآلية حسابية لا سحرية. يقرأ Base64 بايتات المدخل في مجموعات من ثلاث. وثلاث بايتات هي 24 بتة، و24 بتة مقسّمة إلى أربع مجموعات من 6 بتات تعطي أربعة أرقام — كل واحد بين 0 و63، وهذا هو السبب في أن هناك 64 حرفاً. ويُبحث عن كل رقم في الأبجدية ليصبح حرفاً. أربعة حروف مقابل كل ثلاث بايتات.

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

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

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

الترميز وفك الترميز، خطوة بخطوة

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

خذ الكلمة Hello. تُرمَّز بايتاتها في UTF-8 لتعطي SGVsbG8=. ويفك ترميز SGVsbG8= فتحصل على البايتات الخمس نفسها، والتي تُقرأ ثانية «Hello». أما Hi فتصبح SGk=، و Hello, World! تصبح SGVsbG8sIFdvcmxkIQ== — ويظهر الحشو المزدوج لأن المدخل 13 بايتة، وهو ما يترك بايتة واحدة في المجموعة الأخيرة.

لأي عمل تفاعلي، فأسرع طريق هو مُرمِّز ومُفكِّك Base64. الصق نصاً تحصل على Base64، أو الصق Base64 تستعيد النص — بما في ذلك الحروف خارج ASCII، التي تتعامل معها الأداة كـ UTF-8 صحيح. وهي أيضاً جزء من مجموعة أدوات النصوص الأوسع لعدّ الكلمات وتحويل حالة الأحرف وترميز الروابط.

وإن كنت تفعل ذلك بالكود، فالمكتبة القياسية لكل لغة تقريباً تضمّه داخلياً، بأسماء واضحة عادةً — btoa و atob في المتصفح، و base64.b64encode في بايثون، و Base64.getEncoder() في جافا. والفخ هو نفسه في الجميع: انتبه للحد الفاصل بين النص والبايتات.

الأخطاء التي تستنزف الوقت

Base64 نفسه بسيط. الحالات الحدّية حوله هي ما يلتهم العصيات.

• الحروف المتغيرة والإيموجي. لأن Base64 يرمِّز بايتات، فالحرف المتغيّر أكثر من بايتة في UTF-8. والكلمة الفرنسية café تُرمَّز إلى Y2Fmw6k= — فاللاحقة w6k هي البايتتان اللتان تمثّلان é. وإن قرأ مفكوك الترميز تلك البايتات وفق ترميز ذو بايتة واحدة بدلاً من UTF-8، انقلب الحرف المتغيّر رموزاً غريبة. وإن بدت حروفك المتغيّرة مشوّهة بعد رحلة ذهاب وإياب، فهذا هو السبب.
• أسطر مكسورة داخل البيانات. اصطلاحات البريد تقطع Base64 كل 76 حرفاً وتدرج أسطراً جديدة، وليست هذه جزءاً من الترميز. وقد تُفك قيمة منسوخة من بريد أو شهادة بشكل خاطئ أو تفشل تماماً حتى تُزال تلك الأسطر أولاً.
• الأبجدية القياسية مقابل الآمنة للروابط. علامتا + و / في الأبجدية العادية غير آمنتين في الروابط وأسماء الملفات. أما النسخة الآمنة Base64URL فتبدلهما بـ - و _ وتحذف الحشو عادةً. والرمز الذي «يبدو Base64» لكن لا يُفك ترميزه هو غالباً مكتوب بالأبجدية الأخرى.
• الحشو الذي يكسر الـAPI. بعض الأنظمة ترفض حشو =، وبعضها يتطلبه. ورموز JSON Web Tokens تحذفه بالكامل. وحين يختلف نظامان، فإن نفس القيمة بالضبط تنجح مع أحدهما وتفشل مع الآخر.
• اعتباره تشفيراً. Base64 لا يخفي شيئاً. إنه تحويل معروف منشور، بلا مفتاح، يعكسه أي مفكوك ترميز في ميكروثوان. وسنعود إليه، لأنه الخطأ الوحيد ذو العواقب الأمنية الحقيقية.

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

أين تلتقي بـ Base64 حقاً؟

لا تحتاج للبحث عن Base64 — فهو يظهر من تلقاء نفسه. والتعرف عليه بالنظرة مهارة نافعة فعلاً، لأن نصف المهمة في معرفة ما الذي بين يديك.

• روابط data. البادئة data:image/png;base64,… تُضمِّن صورة مباشرة في HTML أو CSS كسلسلة Base64 طويلة، فتستبدل طلباً إضافياً بمستند أكبر. مفيدة للأيقونات الصغيرة، ومضرة للصور الكبيرة.
• مرفقات البريد. لا يزال SMTP يحمل المرفقات كـ Base64 داخل بنية MIME، ومن هنا أتى اصطلاح التقطيع إلى أسطر.
• رموز JSON Web Tokens. رمز JWT هو ثلاثة أقسام من Base64URL موصلة بنقاط — الترويسة والحمولة والتوقيع. ويستطيع أي يملك الرمز فك ترميز القسم الأوسط وقراءة المطالبات، وذلك بالتصميم: الرمز موقَّع لا مشفَّر.
• المصادقة الأساسية في HTTP. الترويسة Authorization: Basic ترسل البيانات السرية كـ المستخدم:كلمةالمرور مرمَّزة في Base64 — توضيح تام لسبب كون الترميز ليس حماية، إذ يُفك بسهولة تامة.
• حمولات الـAPI والإعدادات. أينما احتاج نظام إلى بيانات ثنائية داخل صيغة نصية: رفع الصور عبر JSON، وخرائط المصدر، والأسرار في متغيرات الـCI، والشهادات المُضمَّنة.

عادة التنقيح التي تستحق البناء بسيطة: حين ترى كتلة كثيفة من الحروف والأرقام و + و / و = في النهاية، أو - و _ بلا حشو، فاختبرها أولاً كـ Base64. الصقها في أداة فك الترميز وانظر هل يخرج نص مقروء.

Base64 ليس أماناً

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

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

على جانب الخصوصية هناك أمر إيجابي حقيقية يستحق المعرفة. حين تعمل الأداة بالكامل داخل متصفحك، فإن النص الذي تلصقه لا يصل إلى أي خادم. وأداة Base64 من RMBG.PRO مبنية على هذا النحو، لذا فإن فك ترميز Base64 دون رفع أي شيء ليس وعداً تثق به — بل هو ببساطة كيف تعمل الصفحة. ولمن يتعامل مع بيانات اعتماد أو رموز أو بيانات عملاء، فإن هذا التمييز مهم.

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

رمِّز أو فُك الترميز بلا تعقيد

أيًّا كان ما تحتاجه من Base64، التحويل نفسه ينبغي أن يكون الجزء السهل:

• مُرمِّز ومُفكِّك Base64 مجاني يتعامل مع نصوص UTF-8، الحروف المتغيرة والإيموجي منها.
• يعمل بالكامل داخل متصفحك — لا يُرفع شيء مما تلصقه.
• جزء من مجموعة أدوات النصوص الأوسع: عدّاد الكلمات وعدّاد الأحرف ومحوّل حالة الأحرف ومُرمِّز الروابط.
• بلا تسجيل، وبلا تثبيت، وبلا شيء تضبطه قبل أن تلصق.

الأسئلة الشائعة