شرح ترميز Base64: متى ولماذا تستخدمه

ربما رأيت Base64 من قبل — تلك السلاسل الطويلة الغريبة مثل SGVsbG8gV29ybGQ=. تظهر في رسائل البريد الإلكتروني، ومعرفات URI للبيانات، وحمولات API، ورموز JWT. لكن ما هو Base64 بالضبط، ومتى يجب استخدامه؟ دعنا نوضح الأمر.

ماذا يفعل Base64 (بكلمات بسيطة)

يأخذ Base64 أي بيانات — نصوص، صور، ملفات، أي شيء — ويحولها إلى سلسلة نصية باستخدام 64 حرفًا ASCII "آمنًا" فقط: A-Z، a-z، 0-9، + و /. الرمز = في النهاية هو حشو.

لماذا؟ لأن ليس كل نظام يمكنه التعامل مع البيانات الثنائية الخام. البريد الإلكتروني صُمم للنصوص. JSON لا يدعم البيانات الثنائية. معاملات URL لا يمكنها احتواء بايتات عشوائية. Base64 هو الجسر الذي يتيح لك تمرير البيانات الثنائية عبر قنوات نصية فقط.

كيف يعمل داخليًا

الخوارزمية بسيطة بشكل مدهش. تأخذ 3 بايتات من المدخلات (24 بت)، وتقسمها إلى 4 مجموعات من 6 بتات لكل منها، وتربط كل مجموعة بواحد من 64 حرفًا. إليك مثالًا سريعًا:

المدخلات: Hi (2 بايت: 72، 105)

ثنائي: 01001000 01101001 + أصفار حشو

مقسمة إلى مجموعات 6 بت: 010010 000110 100100

مربوطة بأبجدية Base64: SGk=

الحسابات تعني أن مخرجات Base64 دائمًا أكبر بحوالي 33% من المدخلات. هذا هو الثمن مقابل نقل نصي آمن. مواصفة RFC 4648 تحدد الخوارزمية بدقة إذا أردت التفاصيل الدقيقة.

متى يجب استخدام Base64

تضمين الصور الصغيرة في HTML/CSS: بدلاً من جعل المتصفح يجلب ملفًا منفصلاً، يمكنك تضمين أيقونة صغيرة مباشرة: . هذا يوفر طلب HTTP واحد. مثالي للأيقونات أقل من 2-3 كيلوبايت.

إرسال بيانات ثنائية في واجهات JSON: لا يمكن لـ JSON تخزين بايتات خام. هل تحتاج لرفع ملف عبر واجهة JSON؟ شفّره بـ Base64:

مرفقات البريد الإلكتروني: هذا هو بالضبط ما صُمم Base64 من أجله. ترميز MIME يستخدم Base64 لتضمين المرفقات الثنائية في رسائل البريد الإلكتروني النصية.

JWT ورموز المصادقة: تستخدم رموز JSON Web ترميز Base64URL (متغير آمن لعناوين URL) لأقسام الرأس والحمولة.

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

متى لا يجب استخدام Base64

• الملفات الكبيرة. زيادة الحجم بنسبة 33% مؤلمة حقًا مع الملفات الكبيرة. صورة 10 ميغابايت تصبح 13.3 ميغابايت بـ Base64. استخدم الرفع المتعدد الأجزاء بدلاً من ذلك.
• الأمان. Base64 ليس تشفيرًا. يمكن عكسه بسهولة تامة. لا تستخدمه أبدًا لـ "إخفاء" كلمات المرور أو البيانات الحساسة. يمكن لأي شخص فك ترميز cGFzc3dvcmQ= إلى password في ثوانٍ.
• الصور الكبيرة المضمنة. للصور فوق ~5 كيلوبايت، ملف منفصل مع تخزين HTTP المؤقت المناسب سيكون أفضل أداءً من URI بيانات Base64.

المتغير الآمن لعناوين URL

يستخدم Base64 القياسي + و /، اللذين لهما معنى خاص في عناوين URL. متغير Base64URL يستبدلهما بـ - و _. ستراه في JWT وفي أي مكان تظهر فيه بيانات Base64 في عناوين URL.

أمثلة كود سريعة

إليك كيفية ترميز وفك ترميز Base64 في أكثر اللغات شيوعًا:

لاحظ أن دالة btoa() في JavaScript في المتصفح تعمل فقط مع سلاسل ASCII. إذا كنت بحاجة لترميز نص يونيكود، يجب أن تمر عبر TextEncoder أولاً — هذا يوقع الكثير من المطورين.

الأخطاء الشائعة مع Base64

إليك الأخطاء التي أرى المطورين يقعون فيها أكثر:

1. افتراض أن Base64 هو تشفير. لا أستطيع التأكيد على هذا بما فيه الكفاية. لقد رأيت قواعد كود إنتاجية تشفر مفاتيح API وكلمات المرور بـ Base64، معتقدة أنها "محمية". أي شخص بوحدة تحكم المتصفح يمكنه فك ترميزها فورًا. إذا كنت بحاجة لحماية البيانات، استخدم تشفيرًا حقيقيًا (AES، RSA) أو تجزئة (bcrypt، argon2).

2. عدم التعامل مع الحشو بشكل صحيح. بعض التطبيقات تزيل علامات = الختامية، مما قد يسبب فشل فك الترميز في المحللات الصارمة. إذا كنت ترسل Base64 بين أنظمة، اتفق على ما إذا كان الحشو مضمنًا أم لا.

3. استخدام Base64 القياسي في عناوين URL. حرفا + و / في Base64 القياسي سيكسران عناوين URL. استخدم دائمًا المتغير الآمن لعناوين URL (Base64URL) عند تضمين بيانات مشفرة في معاملات الاستعلام أو أجزاء المسار.

4. ترميز ملفات كبيرة بـ Base64 في حمولات JSON. ملف 5 ميغابايت يصبح حوالي 7 ميغابايت بعد ترميز Base64، وكل هذه السلسلة يجب أن تكون في الذاكرة. لأي شيء أكبر من بضعة كيلوبايت، استخدم multipart/form-data بدلاً من ذلك.

مرجع سريع لمجموعة أحرف Base64

حالة استخدام واقعية: تضمين الخطوط في CSS

أحد الاستخدامات الشائعة لـ Base64 التي قد لا تفكر فيها هو تضمين الخطوط المخصصة مباشرة في ملفات CSS. هذا يتجنب طلب HTTP إضافي لملف الخط:

هذه التقنية تعمل بشكل جيد لخطوط الأيقونات الصغيرة (أقل من 10-15 كيلوبايت). لملفات الخطوط الأكبر، من الأفضل تقديمها بشكل منفصل حتى يتمكن المتصفح من تخزينها مؤقتًا بشكل مستقل.

Base64 مقابل مخططات الترميز الأخرى

Base64 ليس الطريقة الوحيدة لتمثيل البيانات الثنائية كنص. هناك عدة بدائل، ولكل منها نقطة قوتها. دعنا نقارن الرئيسية.

الترميز السداسي عشري (Base16): أبسط نهج — كل بايت يصبح حرفين سداسيين (0-9، A-F). فـ Hi يصبح 4869. بسيط جدًا ومقروء للبشر، لكن المخرجات أكبر بنسبة 100% من المدخلات (ضعف الحجم). ترى النظام السداسي في كل مكان: رموز الألوان (#FF5733)، تجزئات SHA، عناوين MAC، ومخرجات التنقيح.

Base32: يستخدم 32 حرفًا (A-Z و 2-7). المخرجات أكبر بحوالي 60% من المدخلات. ربما رأيته دون أن تدرك — تلك الرموز المكونة من 6 أرقام من Google Authenticator وتطبيقات TOTP/2FA الأخرى تستخدم أسرارًا مشفرة بـ Base32 تحت الغطاء. وهو أيضًا غير حساس لحالة الأحرف، مما يجعله رائعًا للحالات التي يحتاج فيها المستخدمون لكتابة البيانات المشفرة يدويًا.

ASCII85 / Base85: يستخدم 85 حرف ASCII قابل للطباعة، منتجًا مخرجات أكبر بحوالي 25% فقط من المدخلات. هذا أكثر كفاءة من Base64. يستخدم Git متغيرًا من Base85 في تنسيق الترقيعات الثنائية (packfiles)، وملفات Adobe PostScript وPDF تستخدم ترميز ASCII85 داخليًا. العيب؟ يستخدم أحرفًا مثل { و } والاقتباسات التي يمكن أن تسبب مشاكل في JSON وXML وعناوين URL.

إليك مقارنة لترميز نفس المدخلات بحجم 100 بايت:

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

Base64 في تدفقات المصادقة

أحد أكثر استخدامات Base64 انتشارًا (وأكثرها سوء فهم) هو مصادقة HTTP الأساسية. عندما ترسل اسم مستخدم وكلمة مرور عبر Basic Auth، يقوم المتصفح بدمجهما بنقطتين وترميز النتيجة بـ Base64.

إليك ما يحدث تحت الغطاء عند تسجيل الدخول باسم المستخدم admin وكلمة المرور secret123:

يستقبل الخادم هذا الرأس، ويفك ترميزه بـ Base64، ويقسم عند النقطتين، ويتحقق من بيانات الاعتماد. بسيط، أليس كذلك؟ لكن إليك النقطة الحرجة: هذا ليس آمنًا بدون HTTPS. سلسلة Base64 هذه يمكن عكسها بسهولة — أي شخص يعترض الطلب يمكنه فك ترميز YWRtaW46c2VjcmV0MTIz والحصول على كلمة مرورك في أقل من ثانية. مواصفة RFC 7617 لمصادقة Basic تحذر صراحة من هذا.

يظهر Base64 أيضًا في سياقات مصادقة أخرى. رموز الوصول والتحديث في OAuth 2.0 غالبًا ما تكون مشفرة بـ Base64 (رغم أن هذا تفصيل تنفيذ وليس متطلبًا). العديد من مفاتيح API من خدمات مثل AWS وStripe وGoogle Cloud هي سلاسل مشفرة بـ Base64. مرة أخرى، الترميز هو للنقل الآمن — وليس للأمان. أرسلها دائمًا عبر HTTPS وخزنها بشكل آمن.

معرفات URI للبيانات بالتفصيل

ذكرنا معرفات URI للبيانات بإيجاز سابقًا، لكنها تستحق نظرة أعمق. معرف URI للبيانات يتيح لك تضمين محتوى الملف مباشرة في HTML أو CSS أو JavaScript — دون الحاجة لطلب HTTP خارجي. الصيغة الكاملة هي:

mediatype هو نوع MIME قياسي، وعلامة ;base64 تخبر المتصفح أن البيانات مشفرة بـ Base64 (بدونها، يُفترض أن البيانات نص مشفر بعنوان URL)، و هو المحتوى الفعلي.

إليك أمثلة لأنواع وسائط مختلفة:

صورة PNG (الأكثر شيوعًا):

SVG مضمن (لا حاجة لـ Base64!):

لاحظ أن SVG هو نص بالفعل، لذا يمكنك ترميزه بعنوان URL بدلاً من ترميزه بـ Base64. هذا أصغر فعليًا لأنك تتخطى نفقات 33% الإضافية. المطورون الأذكياء يستخدمون هذه الحيلة لأيقونات SVG البسيطة.

مستند PDF:

ملف صوتي:

الآن، بخصوص حدود المتصفح. رغم أن مواصفة معرف URI للبيانات على MDN لا تحدد حجمًا أقصى، إلا أن المتصفحات تفرض حدودها الخاصة. Chrome يحد معرفات URI للبيانات بحوالي 2 ميغابايت في سياقات التنقل (مثل الإطارات والصفحات العلوية). Firefox أكثر سخاءً. بالنسبة لصور خلفية CSS والصور المضمنة، الحد العملي هو صبر المستخدمين — سلسلة Base64 بحجم 500 كيلوبايت في ملف CSS صالحة تقنيًا لكنها ستدمر أوقات التحميل تمامًا.

تأثير الأداء: عندما يضر Base64

دعنا نتحدث عن أرقام حقيقية، لأن "33% نفقات إضافية" تبدو مجردة حتى ترى التأثير في الممارسة.

تكلفة عرض النطاق: صورة 50 كيلوبايت تصبح ~67 كيلوبايت بعد ترميز Base64. هذا 17 كيلوبايت إضافية لكل صورة. اضرب ذلك في صفحة بها 20 أيقونة مضمنة وأنت ترسل 340 كيلوبايت من البيانات غير الضرورية. للمرجع، هذا أكثر من HTML بالكامل لمعظم صفحات الويب.

استخدام الذاكرة: عندما تشفر صورة بـ Base64 وتضمنها في HTML أو CSS، يجب الاحتفاظ بسلسلة الترميز بالكامل في الذاكرة كجزء من DOM أو ورقة الأنماط. ثم يفك المتصفح ترميزها إلى ثنائي، لذا لفترة وجيزة تحتفظ بكلا الإصدارين المشفر والمفكك. لصورة 1 ميغابايت، هذا حوالي 2.33 ميغابايت فقط للسلسلة المشفرة، بالإضافة إلى 1 ميغابايت للثنائي المفكك — أكثر من 3 أضعاف حجم الملف الأصلي.

وقت التحليل: سلاسل Base64 داخل HTML أو CSS يجب تحليلها كجزء من تلك المستندات. معرف URI للبيانات الكبير يجعل ملف CSS أو مستند HTML بالكامل أبطأ في التحليل. وفقًا لـ دليل تحسين الصور في web.dev، يجب أن تكون الصور المضمنة عمومًا أقل من 2-4 كيلوبايت لتوفير فائدة أداء صافية.

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

إليك معيارًا تقريبيًا للمنظور:

القاعدة العامة: ضمّن بـ Base64 أي شيء أقل من 2-4 كيلوبايت. قدم كل شيء آخر كملف منفصل. مع HTTP/2 وHTTP/3، تكلفة الطلبات الإضافية ضئيلة، لذا أصبح الحد أقل حتى على مر السنين.

Base64 في لغات البرمجة المختلفة

غطينا JavaScript وPython سابقًا. إليك كيفية التعامل مع Base64 في لغات شائعة أخرى — كل منها بضعة أسطر فقط:

لاحظ أن كل لغة تحتوي على Base64 في مكتبتها القياسية — لا حاجة لحزم خارجية. هذا دليل على مدى أساسية هذا الترميز. لاحظ أيضًا أن Ruby لديها strict_encode64 (بدون فواصل أسطر) و encode64 (يُدخل فواصل أسطر كل 60 حرفًا، وفقًا لمعيار MIME الأصلي). معظم الاستخدامات الحديثة تريد الإصدار الصارم.

تاريخ Base64

لم يظهر Base64 من العدم. قصته مرتبطة بتاريخ البريد الإلكتروني، وفهمها يفسر الكثير من قرارات التصميم.

في الأيام الأولى للإنترنت، صُمم البريد الإلكتروني (SMTP) للتعامل فقط مع نص ASCII بـ 7 بت — 128 حرفًا وهذا كل شيء. كان هذا مناسبًا للنص الإنجليزي، لكنه عديم الفائدة تمامًا لإرسال الصور أو المستندات أو حتى النص بلغات غير إنجليزية. ببساطة لم تكن تستطيع إرسال بيانات ثنائية عبر البريد الإلكتروني.

ظهرت أول مواصفة رسمية لـ Base64 في RFC 1421 عام 1993، كجزء من معيار Privacy Enhanced Mail (PEM). كانت الفكرة بسيطة: تحويل البيانات الثنائية إلى مجموعة فرعية من ASCII تنجو من أي نظام نقل نصي دون تلف.

ثم جاء RFC 2045 عام 1996، الذي عرّف MIME (Multipurpose Internet Mail Extensions). وحّد MIME كيفية عمل مرفقات البريد الإلكتروني، وكان Base64 ترميزه الأساسي للمحتوى الثنائي. لهذا لا تزال ترى رؤوس Content-Transfer-Encoding: base64 في رسائل البريد الإلكتروني الخام اليوم.

تم تحسين الترميز مرة أخرى في RFC 4648 (2006)، الذي أصبح المرجع النهائي. قدم هذا الـ RFC أيضًا المتغير الآمن لعناوين URL (Base64URL) وأوضح الحالات الحدية حول الحشو. صفحة مسرد Base64 على MDN هي نقطة بداية جيدة إذا أردت استكشاف المواصفة دون قراءة RFCs الخام.

ما يثير الاهتمام هو أن Base64 وُلد من قيد — بريد إلكتروني 7 بت — لم يعد موجودًا. SMTP الحديث يدعم النقل 8 بت والثنائي. ومع ذلك، عاش Base64 أطول بكثير من غرضه الأصلي، ووجد حياة جديدة في واجهات الويب وJWT ومعرفات URI للبيانات وسياقات لا حصر لها. إنه أحد تلك التقنيات التي حلت مشكلة بشكل جيد لدرجة أن الناس يستمرون في إيجاد مشاكل جديدة لها لحلها.

جربه بنفسك

هل تريد رؤية Base64 عمليًا؟ الصق أي نص أو ملف في Base64 Encoder الخاص بنا لرؤية المخرجات المشفرة فورًا. هل تحتاج لفك ترميز شيء؟ Base64 Decoder يتولى ذلك. وإذا كنت تعمل مع صور مشفرة بـ Base64، أداة Base64 to Image الخاصة بنا تتيح لك معاينتها مباشرة في المتصفح.