صور Base64: فن تحويل البكسلات إلى نص عادي

في جملة واحدة

ترميز Base64 للصور هو طريقة لتحويل بيانات الصورة الثنائية إلى سلسلة من النص العادي، مما يتيح لك تضمين الصورة مباشرة في الكود بدلاً من ربطها بملف منفصل.

المشكلة التي يحلها

في الأيام الأولى للويب، كانت الأمور بسيطة: لديك ملف HTML الخاص بك، وإذا أردت صورة، كنت تستخدم وسم <img> للإشارة إلى ملف صورة منفصل، مثل logo.gif. كان المتصفح يقرأ ملف HTML، ويرى الوسم، ثم يقوم بـرحلة ثانية إلى السيرفر لجلب logo.gif. صفحة واحدة، طلبان.

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

هذه هي المشكلة الأساسية التي تحلها Data URIs وترميز Base64: مشكلة "الطلبات الكثيرة جدًا". ماذا لو، بدلاً من إخبار المتصفح "اذهب وجلب هذه الأيقونة من هناك"، يمكننا ببساطة أن نقول "الأيقونة موجودة هنا، داخل ملف CSS هذا"؟

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

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

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

من البكسلات إلى البايتات

أولاً، انسَ كلمة "صورة". فكر في "ملف". ملف PNG أو JPEG أو GIF على جهاز الكمبيوتر الخاص بك ليس مجموعة سحرية من الألوان. إنه تسلسل منظم للغاية من البايتات — تدفق من الأصفار والآحاد. تتضمن هذه البيانات الثنائية بيانات وصفية (مثل أبعاد الصورة)، ولوحات الألوان، وبيانات البكسل المضغوطة نفسها.

المشكلة هي أنه لا يمكنك ببساطة نسخ ولصق هذه البيانات الثنائية في ملف نصي مثل HTML أو CSS. للملفات النصية قواعد. بعض قيم البايت تعني "سطر جديد"، "نهاية الملف"، أو هي ببساطة غير صالحة وقد تكسر الكود. نحن بحاجة إلى طريقة لتمثيل بيانات الصورة الثنائية الخام باستخدام مجموعة "آمنة" فقط من الأحرف التي يفهمها كل نظام.

خدعة Base64 السحرية

هنا يأتي دور ترميز Base64. وظيفته هي تمثيل أي بيانات ثنائية باستخدام 64 حرفًا من أحرف ASCII الشائعة والآمنة للنقل. مجموعة الأحرف هي A-Z، a-z، 0-9، +، و /. هذا كل شيء.

العملية عبارة عن خدعة ذكية في التعامل مع البيانات الثنائية:

1. قراءة 3 بايتات: يقرأ المرمّز بيانات الصورة الثنائية 3 بايتات في كل مرة. البايت هو 8 بت، لذا لدينا 3 × 8 = 24 بت.
2. التقسيم إلى 4 أجزاء: يأخذ هذا الجزء المكون من 24 بت ويعيد تقسيمه إلى أربعة أجزاء من 6 بت (4 × 6 = 24 بت).
3. الربط بالأحرف: كل جزء من 6 بت يمكن أن يمثل رقمًا من 0 (000000) إلى 63 (111111). ثم يتم استخدام هذا الرقم كفهرس للبحث عن حرف في أبجدية Base64 المكونة من 64 حرفًا.

دعنا نرى ذلك بمثال نصي بسيط، لأن المبدأ متطابق. لنقم بترميز كلمة "cat":

الخطوة	الوصف	البيانات
1. ASCII الأصلي	قيم ASCII للأحرف 'c' و 'a' و 't'.	99, 97, 116
2. كـ 3 بايتات (24 بت)	التمثيل الثنائي 8 بت لكل حرف.	01100011 01100001 01110100
3. كـ 4 أجزاء من 6 بت	يتم إعادة تجميع الـ 24 بت.	011000 110110 000101 110100
4. القيمة العشرية	القيمة العشرية لكل جزء من 6 بت.	24, 54, 5, 52
5. حرف Base64	ابحث عن كل قيمة عشرية في جدول Base64.	Y, 2, F, 0

إذًا، النص "cat" يصبح السلسلة النصية "Y2F0" في Base64.

ماذا لو لم تكن البيانات من مضاعفات 3 بايتات؟ يضيف المرمّز أحرف حشو (=) في النهاية للإشارة إلى أن البيانات الأصلية لم تكن قابلة للقسمة تمامًا. علامة = واحدة تعني أن المجموعة الأخيرة كانت تحتوي على بايتين فقط؛ وعلامتان == تعنيان أنها كانت تحتوي على بايت واحد فقط.

هذه العملية تزيد من حجم البيانات بحوالي 33%، لأننا نستخدم 4 أحرف (4 بايتات) لتمثيل ما كان في الأصل 3 بايتات من البيانات.

غلاف Data URI

حسنًا، لدينا الآن سلسلة نصية عملاقة من نص Base64. المتصفح لا يعرف تلقائيًا أنها صورة PNG. يجب أن نخبره بما ينظر إليه باستخدام Data URI.

يحتوي Data URI على تنسيق محدد: data:[<MIME-type>][;base64],<data>

دعنا نحلل مثالًا حقيقيًا لنقطة حمراء صغيرة بصيغة PNG:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==

• data:: المخطط (scheme). هذا يخبر المتصفح "البيانات موجودة هنا، وليست في عنوان URL آخر".
• image/png: نوع MIME. هذا أمر حاسم. يخبر المتصفح "البيانات التي أقدمها لك هي صورة PNG. فك تشفيرها على هذا الأساس". يمكن أن يكون أيضًا image/jpeg، image/svg+xml، إلخ.
• ;base64: علامة اختيارية تشير إلى أن البيانات مشفرة بـ Base64.
• ,: فاصل.
• iVBORw0K...: بيانات الصورة الفعلية المشفرة بـ Base64.

عندما يرى المتصفح هذه السلسلة في خاصية src لوسم <img> أو في دالة url() في CSS، فإنه يفك تشفير سلسلة Base64 ليعيدها إلى البايتات الثنائية الأصلية ويعرض الصورة، كل ذلك دون إجراء أي طلب شبكة إضافي واحد.

قصص من الواقع

حالة أيقونات الواجهة المتقطعة

مطورة واجهات أمامية، لنطلق عليها اسم بريا، كانت تبني لوحة تحكم جديدة وأنيقة. كانت الواجهة مليئة بأيقونات SVG صغيرة وأنيقة: ترس للإعدادات، جرس للإشعارات، عدسة مكبرة للبحث. على شبكة Wi-Fi السريعة في مكتبها، كان كل شيء يبدو رائعًا.

ولكن عندما اختبرتها على اتصال 3G محاكى، كانت التجربة مزعجة. كان تخطيط الصفحة والنص يتم تحميلهما، ولكن لثانية أو اثنتين، كانت هناك مساحات فارغة حيث من المفترض أن تكون الأيقونات. ثم، كانت تظهر فجأة واحدة تلو الأخرى. كان المظهر يبدو رخيصًا ومكسورًا.

كانت المشكلة أن كل أيقونة من الأيقونات الـ 15 كانت background-image: url(...) منفصلة في ملف CSS الخاص بها، مما أدى إلى إطلاق 15 طلب HTTP فردي. كان حل بريا هو تحويل كل أيقونة SVG صغيرة إلى تمثيلها في Base64 وتضمينها مباشرة في ملف CSS.

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

مقترح المشروع القائم بذاته

أليكس، مستشار، كان بحاجة إلى إرسال مقترح مشروع لعميل رفيع المستوى. كان المقترح عبارة عن مستند HTML مع بعض الرسوم البيانية التي تم إنشاؤها كصور PNG وشعار الشركة. لم يستطع ببساطة إرسال مجلد من الملفات ويثق في أن العميل سيفتح ملف HTML بشكل صحيح. كان إرسال المرفقات في البريد الإلكتروني أمرًا غير عملي أيضًا، وبعض برامج البريد الإلكتروني تحظر الصور الخارجية افتراضيًا.

كان بحاجة إلى ملف واحد، مضمون. باستخدام سكربت، أخذ ملف HTML النهائي وصور الرسوم البيانية التي تم إنشاؤها، وقام بترميز كل صورة بـ Base64، واستبدل وسوم <img src="chart1.png"> بوسوم <img src="data:image/png;base64,...">.

كانت النتيجة ملف HTML واحد أكبر قليلاً. يمكنه إرفاق هذا الملف الواحد في بريد إلكتروني، ويمكن للعميل فتحه، سواء كان متصلاً بالإنترنت أم لا، ورؤية المقترح معروضًا بشكل مثالي مع جميع الرسوم البيانية والشعارات، دون أي مشاكل.

الدرس المستفاد: Base64 هي أداة رائعة لإنشاء مستندات محمولة وقائمة بذاتها. عندما تحتاج إلى حزم الصور في ملف واحد "يعمل فقط" في كل مكان، كما هو الحال في رسائل البريد الإلكتروني أو التقارير التي يتم إنشاؤها، فهذا هو الحل الأمثل.

أخطاء ومصائد شائعة

• استخدامه للصور الضخمة. هذه هي الخطيئة الكبرى. هل تتذكر زيادة الحجم بنسبة 33%؟ تحويل صورة رئيسية بحجم 2 ميغابايت إلى كتلة نصية بحجم 2.66 ميغابايت داخل ملف HTML الخاص بك هو كابوس أداء. سيمنع صفحتك من العرض، ويضخم حجم مستندك، وسيكون أبطأ بكثير للمستخدم من مجرد تحميل الصورة بشكل طبيعي. استخدمه فقط للصور الصغيرة.
• تجاهل الجانب السلبي للتخزين المؤقت (caching). يتم تخزين ملف صورة منفصل (logo.png) مؤقتًا بواسطة المتصفح بعد الزيارة الأولى. إذا ظهر هذا الشعار على 100 صفحة من موقعك، فسيتم تنزيله مرة واحدة فقط. إذا قمت بتضمين هذا الشعار كـ Base64 في كل صفحة من صفحات HTML الـ 100 هذه، فسيتعين على المستخدم إعادة تنزيل تلك البيانات (الأكبر حجمًا) في كل مرة.
• نسيان صيغة Data URI الكاملة. لا يمكنك فقط وضع سلسلة Base64 في خاصية src. يجب عليك تضمين data:، ونوع MIME (image/png، image/jpeg، إلخ)، والبادئة ;base64,. بدون هذا السياق، ليس لدى المتصفح أي فكرة عما يجب فعله بسلسلة من الأحرف غير المفهومة.
• جعل ملف CSS الخاص بك غير قابل للقراءة. يمكن أن يصبح ملف CSS الذي يحتوي على بضع عشرات من الصور المضمنة كابوسًا للصيانة. يتضخم الملف بسلاسل نصية من آلاف الأحرف، مما يجعل من الصعب التمرير والعثور على قواعد التنسيق الفعلية. استخدمه بحكمة، وفكر في الاحتفاظ بسلاسل Base64 في ملف منفصل (مثل متغيرات Sass) إذا كنت تستخدم معالجًا مسبقًا.

لماذا يجب أن تضعه في اعتبارك

يجب أن تفكر في ترميز صورة بـ Base64 كلما كنت تتعامل مع صورة صغيرة وحاسمة تحتاج إلى أن تكون مرئية على الفور.

• أيقونات الجزء المرئي من الصفحة (Above-the-fold): الشعارات الصغيرة، أيقونات البحث، أو مفاتيح تبديل القائمة التي تعتبر ضرورية لتجربة المستخدم الأولية.
• أنماط خلفية CSS: الأنماط الصغيرة المتكررة حيث يبدو طلب HTTP إضافي مبالغًا فيه.
• المستندات القائمة بذاتها: عندما تقوم بإنشاء ملف HTML واحد يحتاج إلى أن يكون قائمًا بذاته دون أي تبعيات خارجية (رسائل بريد إلكتروني، تقارير، وثائق للاستخدام دون اتصال بالإنترنت).
• استجابات API: في بعض الأحيان، يكون من الأكثر كفاءة لـ API إرسال صورة مصغرة صغيرة مباشرة ضمن حمولة JSON بدلاً من إجبار العميل على إجراء طلب ثانٍ لها.

إنها أداة محددة لمهمة محددة: الفوز في المقايضة بين حجم الملف وعدد طلبات الشبكة. عند استخدامها بحكمة، فهي تقنية تحسين قوية.

للتعمق أكثر

• RFC 4648: The Base16, Base32, and Base64 Data Encodings - المواصفات الرسمية من IETF التي تحدد كيفية عمل Base64. إنها تقنية وموثوقة قدر الإمكان.
• RFC 2397: The "data" URL scheme - المواصفات الخاصة ببروتوكول data:، والتي تشرح الصيغة والمنطق وراءها.
• MDN Web Docs: Data URLs - الدليل الأساسي وسهل الفهم للمطورين من Mozilla، مع أمثلة واضحة ومعلومات عن توافق المتصفحات.
• Wikipedia: Base64 - نظرة عامة رائعة على تاريخ وحالات استخدام وتصميم نظام ترميز Base64.
• CSS-Tricks: When to Base64 Encode Images (and When Not To) - مقال عملي وكلاسيكي يناقش الإيجابيات والسلبيات في سياق تطوير الويب.