حين تحوّل صورة إلى Base64، تحصل على data URI، أي سلسلة نصية مثل data:image/png;base64,iVBORw0KGgo… يمكنك لصقها مباشرةً داخل سمة src في HTML أو داخل url() في CSS. يفكّها المتصفّح فوراً ويعرض الصورة دون تنزيل منفصل، فلا ملف تستضيفه ولا طلب إضافي.
فهل ينبغي أن تفعل ذلك؟ القاعدة المختصرة هي أن تضمّن الصورة بصيغة Base64 حين تكون صغيرة (أقل من نحو 2 كيلوبايت) ونادرة التغيّر وتريد توفير طلب HTTP واحد، كالأيقونات والشعارات الصغيرة. وفيما عدا ذلك، مثل الصور الكبيرة أو أي شيء يُعاد استخدامه عبر صفحات متعددة أو تريد أن يخزّنه المتصفّح مؤقتاً، أبقِه ملف صورة عادياً. والمأخذ أن Base64 يكبّر الملف بنحو 33%، وبمجرد أن يصبح النص مضمّناً داخل HTML أو CSS لم يعد قابلاً للتخزين المؤقت بمفرده.
إن أردت الأرقام الدقيقة لملف بعينه، فإنّ محوّل الصور إلى Base64 يجري الترميز داخل متصفّحك ويُظهر الزيادة الدقيقة في الحجم، حتى تقرّر بناءً على بيانات حقيقية لا على قاعدة تقريبية. يستعرض هذا الدليل ما هو data URI فعلاً، والحساب وراء ضريبة الحجم، ومصفوفة قرار توضّح متى يستحق التضمين، والحالات التي يتفوّق فيها الملف العادي.
ما الذي يُنتجه فعلاً “تحويل الصورة إلى Base64”: الـ data URI
تحويل صورة إلى Base64 لا يعطيك ملفاً. بل يعطيك سلسلة نصية واحدة طويلة تتّبع صيغة data URI المعرّفة في RFC 2397 (انظر مرجع عناوين data: لدى MDN للمواصفة الكاملة). تتكوّن السلسلة من ثلاثة أجزاء:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…
└──┬─┘ └───┬───┘ └─┬──┘ └─────────┬──────────┘
data: MIME type marker the encoded image bytesيُخبر نوع MIME المتصفّحَ بنوع الصورة التي يفكّها. والأنواع الشائعة للصور هي image/png وimage/jpeg وimage/gif وimage/webp وimage/svg+xml، وimage/x-icon للأيقونات المفضّلة. وتقول العلامة ;base64, إنّ الحمولة التي تليها بصيغة Base64 لا نصاً عادياً. وكلّ ما يلي الفاصلة هو الصورة، مُعاد التعبير عنها كأحرف ASCII قابلة للطباعة.
هذا الجزء الأخير مهمّ للخصوصية. يجري التحويل بالكامل داخل متصفّحك عبر دالّة readAsDataURL في واجهة FileReader، فلا يُرفع شيء إلى أي خادم. يمكنك إسقاط لقطة شاشة قبل الإطلاق أو مخطّطاً داخلياً أو عملاً فنياً لم يُنشر بعد داخل الأداة، وتشاهد علامة تبويب الشبكة (Network) تبقى فارغة. ولفهم الآلية الكامنة وراء كيفية تحوّل البايتات الخام إلى سلسلة ASCII تلك، يغطّي فهم Base64 الترميز من الأساس، ويمدّ الدليل الكامل لـ Base64 فكرة data URL نفسها لتشمل الخطوط وPDF وأنواع ملفات أخرى.
مثال واقعي: صورة PNG شفّافة بحجم 68 بايت
إليك أصغر حالة عملية، وهي صورة PNG شفّافة بأبعاد 1×1 حجمها 68 بايت على القرص، بوصفها data URI كاملاً:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAC0lEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg==الصق ذلك في شريط عنوان المتصفّح وسترى (حسناً، لن ترى، فهي شفّافة) صورة صالحة تُعرض دون أي نشاط شبكي. لاحظ الرمزين الأخيرين ==، فذلك حشو سنصل إليه لاحقاً. وهذا هو شكل Base64 النصّي نفسه مطبّقاً على بايتات صورة بدل نصّ. وإن كنت تحتاج فقط إلى ترميز سلاسل نصّية عادية أو فكّ ترميزها، فأداة ترميز/فكّ ترميز Base64 تتولّى تلك الحالة.
ضريبة الحجم البالغة 33% (ولماذا تتراكم)
يعمل Base64 في مجموعات ثابتة، فكلّ 3 بايتات ثنائية تصبح 4 أحرف ASCII. والأربعة على ثلاثة تساوي نحو 1.33، ومن هنا تأتي قيمة +33%. أضف بايتاً أو اثنين من الحشو إلى البادئة data:image/png;base64, فتصبح النفقة أعلى قليلاً للملفات الصغيرة جداً. وبمثال ملموس، تصبح صورة PNG بحجم 9 كيلوبايت نحو 12 كيلوبايت من النصّ.
ولماذا 3 إلى 4 بالضبط؟ يستخدم Base64 أبجدية من 64 حرفاً، هي A–Z وa–z و0–9 إضافةً إلى + و/. وأربعة وستون رمزاً تعني 6 بتّات من المعلومات لكلّ حرف، بينما تحمل البايتات الثنائية 8 بتّات لكلّ بايت. والمضاعف المشترك الأصغر للعددين 6 و8 هو 24 بتّاً، أي 3 بايتات أو 4 أحرف Base64، فيتقدّم المُرمِّز عبر الصورة 24 بتّاً في كلّ مرّة. وحين لا يكون طول الصورة مضاعفاً تامّاً للعدد 3، يحشو حرف = واحد أو اثنان المجموعةَ الأخيرة. هذا هو الحساب، وهو ثابت لا يقلّصه أي إعداد للمُرمِّز.
تلك الـ 33% هي التكلفة الظاهرة. أمّا التكلفة الخفيّة فهي أنّها تتراكم، وهو الجزء الذي تتجاهله معظم نصائح “ضمّنها وحسب”:
- يُعاد تنزيل الصورة كلّما تغيّر الملف الحاوي لها. ملف
logo.pngالخارجي مورد مستقلّ بذاته. ضمّنه داخلstyles.css، وعندها يُبطل كلّ تعديل على ورقة الأنماط، كتغيير لون أو إضافة قاعدة جديدة، صلاحيةَ المخزون المؤقت للصورة أيضاً، فيُعيد الزوّار تنزيل صورة كانت لديهم بالفعل. - لا يمكن تخزينها مؤقتاً بصورة مستقلّة. يُجلب ملف الصورة العادي مرّة واحدة ويُعاد استخدامه عبر كلّ صفحة وكلّ زيارة. أمّا data URI المضمّن فهو جزء من المستند، فيُرسَل مجدّداً مع كلّ صفحة تضمّنه ومع كلّ فقدان للمخزون المؤقت لذلك المستند.
- الـ CSS يحجب العرض. لن يرسم المتصفّح حتى يحصل على الـ CSS. احشُ data URI كبيراً داخل ورقة أنماط فتكون قد كبّرت مورداً يحجب العرض ويؤخّر أوّل رسم للصفحة بأكملها.
هل يلغي gzip أو brotli نسبة الـ 33%؟
جزئياً لا كلّياً. نصّ Base64 متكرّر بما يكفي ليضغطه gzip وbrotli جيداً، فيستردّان جزءاً كبيراً من التضخّم على الشبكة. لكنّ أمرين يظلّان صحيحين. أوّلاً، يبقى Base64 المضغوط عادةً أكبر قليلاً من النسخة الثنائية الأصلية المضغوطة، لأنّك سلّمت أداة الضغط نقطة انطلاق أقلّ كفاءة. وثانياً، وهو الأهمّ، لا يفعل الضغط شيئاً بشأن التخزين المؤقت أو حجب العرض. فـ data URI الأصغر على الشبكة ما زال يُعاد تنزيله مع ملفه الحاوي وما زال لا يمكن تخزينه مؤقتاً بمفرده.
بعبارة أخرى، الضغط ليس كإزالة تكلفة التضمين. وإن كان الفرق بين التصغير (minify) وgzip وbrotli غير واضح، فإنّ دليل تصغير الشيفرة يبيّن كيف تتراكم تلك الطبقات، ولماذا لا يصلح عصرُ البايتات إطلاقاً مشكلةَ التخزين المؤقت التي يخلقها التضمين.
متى تستخدم صورة Base64 (مصفوفة القرار)
يتلخّص القرار كلّه في حفنة من العوامل. وها هي جنباً إلى جنب:
| العامل | يميل نحو التضمين (Base64) | يميل نحو ملف عادي |
|---|---|---|
| الحجم | أقل من ~2 كيلوبايت (أخضر) | أكثر من ~10 كيلوبايت (أحمر)؛ 2–10 كيلوبايت مسألة تقدير (كهرماني) |
| إعادة الاستخدام | صفحة واحدة، موضع أو موضعان | مكرّر عبر صفحات كثيرة |
| تواتر التغيّر | لا يتغيّر تقريباً أبداً | يُعدَّل كثيراً |
| السياق | بريد HTML، أداة (widget) قائمة بذاتها أو bookmarklet، حمولة JSON/API، أيقونة حرجة فوق الطيّة تستحقّ توفير طلب واحد | صور المحتوى، الأصول المشتركة القابلة للتخزين المؤقت |
عتبات الحجم تلك ليست اعتباطية، فهي تعكس شارة إشارة المرور المدمجة في محوّل الصور إلى Base64: أخضر دون 2 كيلوبايت، كهرماني حتى 10 كيلوبايت، أحمر فوق ذلك. تقرأ الأداة ملفك الفعلي وتخبرك في أي خانة يقع.
قاعدة تقريبية بسيطة
إن كنت ستتذكّر سطراً واحداً، فليكن هذا: إذا كانت الصورة أقل من ~2 كيلوبايت ومستخدَمة في موضع أو موضعين فقط، يؤتي التضمين ثماره عادةً؛ وإذا تجاوزت ~10 كيلوبايت أو أُعيد استخدامها عبر صفحات، يفوز الملف العادي المخزَّن مؤقتاً دائماً تقريباً. ومنطقة 2–10 كيلوبايت الوسطى هي حيث توازن بين الطلب الموفّر والمخزون المؤقت المفقود في وضعك بعينه.
حالات ملائمة بالتفصيل
بضع حالات يكسب فيها Base64 أجره عن جدارة:
- بريد HTML. يحجب كثير من عملاء البريد الصور المستضافة خارجياً افتراضياً حمايةً للخصوصية، ما يكسر أي تخطيط يعتمد على شعار بعيد. أمّا data URI صغير مضمّن فيُعرض فوراً دون أي جلب من الخادم. اقصُر هذا على الشعارات والأيقونات، ولا تضمّن صورة فوتوغرافية داخل بريد.
- الأدوات القائمة بذاتها وbookmarklets. على الـ bookmarklet أو الأداة القابلة للتضمين أن تعمل بصفر اعتماديات خارجية. وتضمين أيقوناتها يبقي كلّ شيء في ملف واحد قابل للإسقاط.
- حمولات JSON وAPI. يكون شحن صورة مصغّرة داخل مستند JSON أو ملف إعداد أحياناً الخيار الأنظف، إذ تتمّ الرحلة في كائن واحد دون طلب ثانٍ يُوصَل.
- أيقونة حرجة فوق الطيّة. حين يكون شعار صغير جزءاً من أكبر رسم محتوى (LCP) وتريد حذف طلب واحد من المسار الحرج، يمكن أن يساعد التضمين. والتشديد هنا على كلمة الصغير.
ثمّة نمط يربط هذه الحالات: في كلّ منها يسافر الأصل مع شيء آخر، وإلّا لاحتاج إلى قناة توصيل خاصّة به. فالبريد لا يستطيع الاعتماد على شبكة توصيل المحتوى (CDN) لديك، وbookmarklet لا يملك ملفاً ثانياً ليجلبه، واستجابة JSON حمولة واحدة. في كلّ منها بديل التضمين ليس “ملفاً مخزَّناً مؤقتاً” بل “صورة مفقودة”، ما يغيّر الحساب كلّياً. وذلك هو الاختبار الحقيقي لملاءمة Base64: ليس “أهي صغيرة” فحسب، بل “أيُعدّ الملف المنفصل خياراً أصلاً هنا”.
متى لا تضمّن: التخزين المؤقت، والتحميل الكسول، ومؤشّرات Core Web Vitals
الوجه الآخر أطول، لأنّ التضمين يعطّل بهدوء عدّة أشياء يجيدها المتصفّح.
تفقد التخزين المؤقت المستقلّ. هذا أكثر ما يؤلم الزوّار العائدين. تستقرّ الصورة العادية في مخزونهم المؤقت بعد الزيارة الأولى وتُحمَّل فوراً بعدها. أمّا الصورة المضمّنة فلا تملك مدخل تخزين مؤقت مستقلّاً، إذ تركب مع المستند في كلّ مرّة، فيدفع الزائر المتكرّر تكلفة البايتات مرّة بعد مرّة.
تفقد التحميل الكسول. تتيح السمة loading="lazy" للمتصفّح تأجيل الصور التي تحت الطيّة حتى يمرّر المستخدم قريباً منها. أمّا data URI فيُحلَّل و”يُنزَّل” لحظة قراءة الـ HTML، فلا شيء يُؤجَّل. ضمّن عشرات الصور التي تحت الطيّة فتكون قد أرغمتها كلّها على التحميل الأوّلي.
تكبّر الموارد الحاجبة للعرض. كما سبق، يُضخّم data URI داخل CSS مورداً يحجب أوّل رسم. وكلّما كبرت ورقة الأنماط تلك، طالت مدّة بقاء الصفحة فارغة.
فك الترميز أغلى على الجوال. يُفكّ ترميز data URI من Base64 في كلّ مرّة يُحمَّل فيها مستنده، وعلى الهواتف الضعيفة يتراكم عبء CPU الإضافي هذا. والأسوأ أنّ البايتات لا تصل قطّ إلى المخزون المؤقت على قرص المتصفّح، فالصورة المضمّنة الثقيلة يُعاد فكّ ترميزها في كلّ زيارة بدل أن تُخزَّن وتُفكّ مرّة واحدة كما يحدث للملف العادي.
ثمّة كذلك سبب تاريخي لتحوّل هذه النصيحة. كانت الحجّة الأصلية للتضمين، التي رُفعت بصخب في عصر HTTP/1.1، هي تقليل الطلبات: كان كلّ اتصال يجلب مورداً واحداً في كلّ مرّة، فصفحة بها 40 أيقونة صغيرة تدفع 40 رحلة ذهاب وإياب. ثمّ غيّر HTTP/2 ذلك بمضاعفة طلبات كثيرة عبر اتصال واحد، ما جعل الملفات الصغيرة الإضافية رخيصة. فتبخّر معظم العائد الكبير للتضمين، أي تقليل الطلبات، بينما بقيت التكاليف من فقدان التخزين المؤقت وانعدام التحميل الكسول وكِبَر الملفات الحاجبة للعرض. وإن قرأت مقالات أقدم متحمّسة لقوالب Base64 sprites، فزِنها مقابل البروتوكول الذي يعمل عليه موقعك فعلاً اليوم.
زاوية Core Web Vitals
يقطع التضمين في اتّجاهين بشأن LCP (Largest Contentful Paint، أكبر رسم محتوى). فمع صورة صغيرة فوق الطيّة هي عنصر LCP، يمكن لإزالة طلب أن تقدّم LCP قليلاً. لكن ضمّن صورة كبيرة فتفعل العكس: تؤخّر المستند أو ورقة الأنماط التي تعيش فيها، مؤجّلاً LCP للصفحة بأكملها. وعتبة الحجم هي من تحسم الاتّجاه.
أمّا بالنسبة إلى CLS (التزحزح التراكمي للتخطيط)، فلا يغيّر التضمين شيئاً في القاعدة الأساسية: ما زالت الصورة تحتاج إلى width وheight صريحين (أو صندوق نسبة أبعاد) ليتمكّن المتصفّح من حجز مساحة قبل أن يرسمها. وdata URI دون أبعاد يزحزح التخطيط تماماً كما تفعل صورة بعيدة دون أبعاد.
غالباً ما تكون الرافعة الأفضل من التضمين هي تصغير المصدر. فضغط صورة قبل ترميزها يجعل كلّاً من الملف وأي data URI ناتج عنه أصغر. يغطّي دليل ضغط الصور في المتصفّح مقابل Node كيفية فعل ذلك في جانب العميل أو في خطوة بناء، ويساعدك WebP مقابل AVIF مقابل JPEG على اختيار صيغة صغيرة من البداية.
كيف تضمّن الصور في HTML وCSS وMarkdown وJSON
ما إن يصبح لديك data URI، فإليك كيف يندرج في كلّ سياق. هذه هي المقتطفات الأربعة الجاهزة للّصق التي يولّدها لك محوّل الصور إلى Base64.
في HTML، الصق الـ URI في أي src:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…" alt="logo">في CSS، لُفّه بـ url() من أجل background-image (هذا هو النمط القانوني لـ base64 image in CSS):
.icon {
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…");
}في Markdown، رابط صورة قائم بذاته لملفّات README ومشكلات GitHub ودفاتر العمل (notebooks) حيث لا يمكنك استضافة ملف:
في JSON، أصل مضمّن داخل حمولة API أو ملف إعداد:
{ "icon": "data:image/png;base64,iVBORw0KGgo…" }الأربعة جميعاً تعمل في أي مكان يُقبل فيه عنوان URL: img src وbackground في CSS وmask-image، وحتى <link> الخاص بالأيقونة المفضّلة. وكلّ متصفّح حديث يدعم نظام data:.
توليد هذه بسرعة
بناء هذه يدوياً عُرضة للأخطاء، فنوع MIME خاطئ واحد أو فاصل سطر شارد كافٍ ليفشل عرض الصورة بصمت. أسقِط ملفك في محوّل الصور إلى Base64 فيُنتج المقتطفات الأربعة جميعها بأزرار نسخ خاصّة بكلّ منها، إضافةً إلى الزيادة الدقيقة في الحجم لتعرف مسبقاً ما إن كان الأصل ينتمي إلى التضمين أصلاً.
SVG: الحالة الخاصّة التي يخسر فيها Base64 عادةً
يكسر SVG المنطق المعتاد، لأنّ SVG نصّ لا ثنائي. وُجد Base64 لجعل البيانات الثنائية آمنة نصياً، لكنّ SVG هو أصلاً نصّ XML. وترميزه بـ Base64 يضخّم سلسلة لم تكن تحتاج إلى ترميز ويجعلها غير قابلة للقراءة في الأثناء. فبالنسبة إلى SVG تحديداً، يكاد Base64 يكون دائماً الخيار الخاطئ.
قارن بين ثلاث طرق لتضمين الأيقونة نفسها:
/* 1. data URI بصيغة Base64 — يضيف ضريبة 33% إلى نص لم يكن يحتاجها */
.a { background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…"); }
/* 2. data URI مُرمَّز بصيغة URL — ترميز نسبي لحفنة أحرف، دون ضريبة 33% */
.b { background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'…%3C/svg%3E"); }
/* 3. <svg> مضمّن مباشرةً في الـ HTML — قابل للتنسيق الكامل بـ CSS */<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24">
<path d="M12 2 L22 22 H2 Z" fill="currentColor" />
</svg>الخيار 2 (الترميز بصيغة URL) عادةً أصغر من الخيار 1، ويبقى مقروءاً للبشر، ويُضغط أفضل. فأنت ترمّز نسبياً الأحرف التي قد تكسر الـ URI فقط، وهي < و> و# وعلامات الاقتباس، تاركاً ما عداها مقروءاً. ونهج مرمِّز/فاكّ ترميز URL موثّق في الأداة نفسها، ولا تلجأ إلى SVG بصيغة Base64 إلّا حين يطلب خطّ بناء ذلك تحديداً.
لماذا يتفوّق <svg> المضمّن غالباً على أيقونة PNG بصيغة Base64
إن كنت تختار بين أيقونة PNG مرمَّزة بـ Base64 و<svg> مضمّن، فإنّ الـ SVG يفوز عادةً على كلّ محور. فهو يتمدّد إلى أي حجم دون ضبابية، ولا يحمل ضريبة 33%، ويمكنك بخلاف أي data URI تنسيقه بـ CSS وتحريكه وإعادة تلوينه بـ currentColor. أمّا أيقونة PNG بصيغة Base64 فهي كتلة ثابتة الدقّة لا يمكنك لمسها بعد الترميز. احفظ Base64 النقطي (raster) للحالات التي تحتاج فيها فعلاً إلى صورة فوتوغرافية أو لقطة شاشة نقطية مضمّنة.
فكّ الترميز في الاتّجاه الآخر: من Base64 عودةً إلى صورة
المشكلة العكسية شائعة بالقدر نفسه: لديك سلسلة Base64 مسحوبة من استجابة API أو سطر سجلّ أو عمود قاعدة بيانات أو ورقة أنماط تنقّحها، وتحتاج إلى رؤية الصورة الفعلية.
تفصيلان يُعثّران الناس. الأوّل هو الفرق بين Base64 الخام وdata URI الكامل. يحمل data URI الكامل (data:image/png;base64,…) نوع MIME الخاص به، أمّا الحمولة المجرّدة (iVBORw0KGgo…) فلا تحمله. ولعرض حمولة مجرّدة فإنّك إمّا تضيف بادئة data: صحيحة في المقدّمة أو تدع أداة تستنتج الصيغة من البايتات الأولى، إذ تعني iVBORw0KGgo صورة PNG، و/9j/ صورة JPEG، وR0lGOD صورة GIF.
التفصيل الثاني هو التفاف الأسطر. غالباً ما يُلَفّ Base64 الوارد من البريد أو الأدوات الأقدم عند 76 حرفاً وفق RFC 2045. ويجب نزع تلك الأسطر الجديدة قبل فكّ الترميز، وإلّا فالسلسلة غير صالحة في سمة HTML أو في url().
في المتصفّح يمكنك تسليم data URI كامل مباشرةً إلى <img>:
<img src="data:image/png;base64,iVBORw0KGgo…" alt="decoded">وعلى الخادم، يعيد Node بناء الملف من الحمولة:
import { writeFileSync } from "node:fs";
const b64 = "iVBORw0KGgoAAAANSUhEUgAA…"; // الحمولة الخام، دون بادئة :data
writeFileSync("output.png", Buffer.from(b64, "base64"));ولمسار دون شيفرة، استخدم محوّل Base64 إلى صورة: الصق سلسلة (مع البادئة أو دونها، بكلّ فواصل أسطرها)، وعاينها، واقرأ أبعادها ونوع MIME الخاص بها، ونزّل صورة PNG أو JPG أو GIF أو SVG حقيقية. فهو ينزع المسافات البيضاء، ويتسامح مع بادئة مفقودة، ويكتشف الصيغة من البايتات السحرية تلقائياً.
ثمّة فحص تعقّل يستحقّ الإجراء على صورة مفكوكة الترميز، وهو النظر إلى أبعادها المُبلَّغ عنها. فإن سحبت سلسلة واحدة من ملف ضمّ عدّة سلاسل وكانت النتيجة 1×1، فالأرجح أنّك التقطت بكسل تتبّع بدل الأصل الذي أردته. وتذكّر أنّ فكّ الترميز ميكانيكي محض وبلا فقدان، فصورة PNG بصيغة Base64 تعود نفسَها بالضبط بايتاً ببايت دون أي إعادة ضغط. الشيء الوحيد الذي تغيّر على طول الطريق هو الحاوية: سلسلة نصية في طريق الخروج، وملف ثنائي في طريق العودة.
الأسئلة الشائعة
هل ينبغي أن أحوّل صوري إلى Base64؟
فقط حين يستحقّ الأمر، أي للأيقونات أو الشعارات الصغيرة (أقل من ~2 كيلوبايت) نادرة التغيّر حيث يهمّ توفير طلب HTTP واحد، وكذلك في بريد HTML والأدوات القائمة بذاتها وحمولات JSON. أمّا الصور الكبيرة أو أي شيء يُعاد استخدامه عبر صفحات فينبغي أن يبقى ملفات عادية دائماً تقريباً، حتى تحتفظ بالتخزين المؤقت والتحميل الكسول.
كم يُكبّر Base64 الصورة؟
نحو +33%. يرمّز Base64 كلّ 3 بايتات ثنائية بوصفها 4 أحرف ASCII، إضافةً إلى قليل من الحشو وبادئة data:. فصورة PNG بحجم 9 كيلوبايت تصبح نحو 12 كيلوبايت من النصّ. ولرؤية الزيادة الدقيقة لملفك عند تحويل صورة إلى Base64، تُبلِّغ الأداة عن الرقم الدقيق في شريط بياناتها الوصفية.
هل يجعل Base64 الصور تُحمَّل أسرع؟
مع أيقونة صغيرة جداً فوق الطيّة قد يفعل، بتوفير رحلة ذهاب وإياب لطلب واحد. أمّا مع الصور الأكبر أو المُعاد استخدامها فهو عادةً أبطأ: تفقد التخزين المؤقت المستقلّ، ولا يمكنك تحميله كسولاً، وتضمينه في CSS يكبّر مورداً حاجباً للعرض. والحجم هو العامل الحاسم.
هل يمكنني استخدام صورة Base64 في CSS؟
نعم: background-image: url("data:image/png;base64,…"). وهو مقبول للأيقونات الصغيرة جداً. لكن تذكّر فقط أنّ data URI يصبح جزءاً من ورقة الأنماط، فيُعاد تنزيل الملف بأكمله كلّما تغيّر الـ CSS، ولا يمكن تخزين الصورة مؤقتاً بمعزل عنه.
هل أستخدم SVG أم Base64 للأيقونات؟
فضّل <svg> مضمّناً أو data URI لـ SVG مُرمَّزاً بصيغة URL. فـ SVG نصّ يتمدّد بنظافة ولا يحمل ضريبة 33%، وهو عادةً أصغر من PNG بصيغة Base64 ويمكنك تنسيقه بـ CSS. ولا تلجأ إلى Base64 إلّا حين تحتاج تحديداً إلى أيقونة نقطية.
كيف أحوّل سلسلة Base64 عودةً إلى صورة؟
في المتصفّح، أسقِط URI كاملاً بصيغة data:image/…;base64,… في <img src>. وعلى الخادم، استخدم Buffer.from(b64, "base64") لكتابة الملف. الحمولة الخام تحتاج إلى إضافة بادئة data:، والسلاسل الملفوفة الأسطر تحتاج إلى نزع أسطرها الجديدة أوّلاً. وأداة Base64 إلى صورة تتولّى كلّ ذلك وتتيح لك تنزيل النتيجة.