🖼️ تحويل الصور إلى Base64

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

تأخذ URI بيانات Base64 صورة كانت لتعيش عادة في ملف مستقل بذاتها، وتطويها داخل سلسلة نصية صغيرة بما يكفي لتناسب سمة HTML أو تصريح CSS أو حقل JSON. فبدلاً من أن يقوم متصفحك برحلة منفصلة إلى الخادم لجلب logo.png، تسافر الصورة مباشرة داخل المستند نفسه الذي يحتاجها. تبني هذه الأداة تلك السلسلة بالكامل على جهازك أنت، فتنتقل من ملف صورة إلى كود جاهز للصق خلال الوقت الذي يستغرقه السحب والإفلات.

سير العمل قصير عن قصد. أفلت ملف PNG أو JPG أو SVG أو WebP أو GIF في منطقة الإفلات أعلاه، أو انقر عليها لفتح نافذة اختيار الملفات المعتادة. بمجرد أن ينتهي المتصفح من قراءة الملف، تظهر معاينة فورية ويمتلئ مربع نتيجة Base64 تلقائياً، دون أي زر "تحويل" منفصل تنقر عليه ودون إعادة تحميل الصفحة.

1. اختر صورتك. اسحب ملفاً من سطح المكتب أو مدير الملفات إلى منطقة الإفلات، أو انقر عليها للبحث عن ملف. أي شيء يستطيع متصفحك عرضه كصورة، يمكنه ترميزه.
2. دع فك الترميز يحدث تلقائياً. تقرأ الأداة البايتات الخام لملفك باستخدام واجهة FileReader المدمجة في المتصفح، وتُرمّزها إلى سلسلة Base64 في اللحظة التي يُحمّل فيها الملف.
3. اختر صيغة الإخراج. استخدم القائمة المنسدلة صيغة الإخراج للتبديل بين سلسلة URI بيانات خام، أو تصريح CSS جاهز من نوع background-image، أو وسم HTML كامل من نوع img.
4. انسخ النتيجة أو نزّلها. انقر على نسخ الكود لأخذ النص بالضبط إلى الحافظة، أو على تنزيل النص إذا كانت السلسلة طويلة وتفضل حفظها كملف لاستخدامه لاحقاً.

بما أن العملية بأكملها تعمل كـ JavaScript داخل تبويب متصفحك الخاص، فلا توجد خطوة رفع، ولا قائمة انتظار على أي خادم، والحد الوحيد هو ذاكرة جهازك أنت.

فهم صيغة URI البيانات

تتبع كل سلسلة Base64 تنتجها هذه الأداة نفس النمط الذي يحدده مخطط URI البيانات: data:[نوع-mime];base64,[بيانات-مشفرة]. تخبر البادئة data: المتصفح أن هذا ليس رابطاً عادياً يشير إلى مكان آخر، بل هو المحتوى نفسه، يصل مضمناً. يخبر نوع MIME الذي يليها مباشرة، مثل image/png أو image/jpeg أو image/svg+xml أو image/webp، المتصفح تحديداً كيف يفسّر البايتات التالية، ليعرض ملف PNG كـ PNG وملف SVG كـ SVG بدلاً من التخمين من امتداد ملف لم يعد موجوداً أصلاً.

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

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

زيادة الـ 33%: لماذا تكون Base64 أثقل من الملف الأصلي

يجمّع ترميز Base64 البيانات الثنائية الأصلية في كتل من 3 بايت، ويحوّل كل كتلة إلى 4 أحرف نصية قابلة للطباعة. هذه النسبة، 3 إلى 4، تفرضها رياضيات الترميز نفسه، وليس صيغة الصورة أو إعدادات الضغط، وهي تعني أن كل سلسلة Base64 أثقل بنحو 33% من الملف الذي جاءت منه، قبل أي ضغط إضافي مثل gzip أو Brotli قد يطبّقه الخادم فوق ذلك.

عملياً، هذا يعني أن أيقونة بحجم 60 كيلوبايت تقترب من 80 كيلوبايت بعد الترميز، وأن صورة فوتوغرافية بحجم 300 كيلوبايت تتجاوز 400 كيلوبايت. بالنسبة لأيقونة صغيرة واحدة، يبقى هذا الفرق غير ملحوظ للمستخدم. لكن عند تكراره عبر صفحة مليئة بصور مصغّرة مضمّنة، أو تضمينه داخل ملف CSS يُرسل لكل زائر في كل تحميل صفحة، يتراكم هذا الوزن الزائد ليصبح مستنداً أثقل فعلياً من تقديم تلك الصور نفسها كملفات منفصلة.

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

متى يساعد تضمين الصورة (ومتى يضرّ) بالأداء

عادة ما تُطلق كل صورة يشار إليها عبر <img src="..."> أو url(...) في CSS طلب HTTP خاصاً بها. في اتصالات HTTP/1.1 القديمة، كانت المتصفحات قادرة على فتح عدد محدود فقط من الاتصالات المتزامنة لكل نطاق، فكانت صفحة تحتوي على عشرات الأيقونات الصغيرة تعاني حقاً من هذا العبء الإضافي للطلبات، وكان تضمين تلك الأيقونات كسلاسل Base64 يزيل هذه الرحلات الإضافية تماماً. هذه هي الحجة الأصلية لصالح التضمين، وتبقى صحيحة بالنسبة للرسومات الصغيرة والزخرفية التي تظهر مرة واحدة ونادراً ما تتغير.

تعدد اتصالات HTTP/2 وHTTP/3 الحديثة العديد من الطلبات عبر اتصال واحد، ما يضعف الحجة الأصلية بشكل كبير. لم يعد جلب عشرة ملفات خارجية صغيرة عبر HTTP/2 مكلفاً كما كان قبل عقد من الزمن، بينما لم تختفِ زيادة الـ 33% التي يفرضها Base64. هذا يعيد ترجيح الكفة نحو الملفات المرتبطة بالنسبة لمعظم الصور اليومية، ويحصر التضمين في الحالات التي لا يزال فيها تجنب ولو طلب واحد إضافي أمراً مهماً، مثل الرسومات الرئيسية أعلى الصفحة التي يجب أن تظهر في اللحظة التي يُحلّل فيها HTML، أو أدوات الملف الواحد التي لا يمكنها الاعتماد على طلب شبكة ثانٍ.

قاعدة عملية مفيدة: ضمّن ما هو صغير حقاً، الأيقونات، مؤشرات التحميل، الشعارات الدقيقة، عادة أقل من 5 إلى 10 كيلوبايت، واربط كل ما عدا ذلك. كما تؤخر الصورة المضمنة الكبيرة اللحظة التي ينتهي فيها المتصفح من تحليل مستند HTML أو CSS المحيط بها، لأنه يجب عليه قراءة السلسلة المشفرة بأكملها قبل المتابعة، ما قد يؤجل اللحظة التي يصبح فيها باقي الصفحة مرئياً.

استخدام صور Base64 في CSS

أشيع مكان تنتهي إليه صورة Base64 هو تصريح background-image في CSS، وهو بالضبط ما تنتجه صيغة إخراج CSS في هذه الأداة. عند اختيار تلك الصيغة، تُغلّف سلسلتك المشفرة داخل background-image: url('data:image/png;base64,...');، جاهزة للصق مباشرة في ورقة أنماط، أو كتلة <style>، أو سمة style مضمّنة.

يظهر هذا النمط باستمرار في تفاصيل بصرية صغيرة متكررة: نسيج ضوضاء خفيف خلف بطاقة، أيقونة مخصصة تحل محل علامة القائمة الافتراضية، حالة التحديد لمربع اختيار أو زر راديو، أو فاصل زخرفي بصيغة SVG بين أقسام الصفحة. وبما أن الصورة تسافر مع CSS نفسه، فلا يوجد شيء إضافي يحتاج المتصفح لجلبه بعد تحميل ورقة الأنماط، وهو أمر مهم للعناصر التي تظهر في اللحظة التي تُعرض فيها الصفحة، قبل أن يحين وقت وصول أي موارد مؤجلة التحميل.

المقابل هو أن CSS المليء بسلاسل Base64 الطويلة يصبح أصعب بكثير في القراءة والصيانة، وأن ورقة الأنماط المتضخمة تلك يجب تنزيلها وتحليلها بالكامل قبل أن يستطيع المتصفح تطبيق أي من الأنماط التي تليها. الاقتصار على استخدام صور Base64 في CSS للموارد الصغيرة حقاً، واستخدام مرجع عادي مثل url('/images/photo.jpg') لأي شيء أكبر، يحافظ على سرعة ورقة الأنماط والصفحة نفسها معاً.

صور Base64 في HTML وواقع قوالب البريد الإلكتروني

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

البريد الإلكتروني هو المكان الوحيد الذي يستحق فيه هذا النمط حذراً حقيقياً. يعرض Gmail وApple Mail عادة الصور المضمنة بـ Base64 دون مشاكل، لكن نسخ Outlook لسطح المكتب تستخدم محرك عرض Word بدلاً من محرك متصفح حديث، وغالباً ما يحذف هذا المحرك صور URI البيانات أو يرفض عرضها ببساطة. قد تبدو رسالة تسويقية مبنية على شعارات مضمّنة مثالية في صندوق وارد Gmail شخصي، بينما تُظهر أيقونة صورة معطلة لدى نسبة كبيرة من مستخدمي Outlook في بيئة العمل. بالنسبة لأي شيء يُرسل كبريد جماعي، تبقى الصورة المستضافة بشكل طبيعي مع سمة alt مكتوبة بعناية الخيار الآمن الافتراضي، ويُستحسن حفظ Base64 لصفحات HTML التي تتحكم أنت بالكامل في طريقة عرضها، مثل إشعار داخل تطبيقك الخاص، أو ملف PDF مُصدّر، أو إيصال قابل للطباعة.

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

SVG وBase64: متى يساعد الترميز فعلاً

يحتل SVG موقعاً غير معتاد في هذا الحديث برمّته لأن ملف SVG هو نص عادي أصلاً، وليس بيانات ثنائية. هذا يعني أنه يمكن تضمينه داخل url() في CSS باستخدام ترميز URL العادي بدلاً من Base64، وغالباً ما يكون SVG مشفر بترميز URL أصغر حجماً من نفس الملف بعد تحويله إلى Base64، لأن ترميز URL يُفلت فقط حفنة من الأحرف الخاصة بدلاً من إعادة كتابة كل بايت ضمن أبجدية من 4 أحرف.

ومع ذلك، يثبت Base64 جدارته مع SVG في بعض الحالات المحددة. إنه الخيار الأبسط كلما كان السياق المحيط لا يتحمل علامات الاقتباس والرموز والأقواس الزاوية التي يحملها ترميز SVG الخام أو المشفر بـ URL، مثل داخل سلسلة JSON واحدة، أو عمود في قاعدة بيانات، أو قيمة خاصية CSS مخصصة يصبح فيها إفلات الأحرف أمراً مرهقاً. كما يعمل جيداً كسمة <img src="data:image/svg+xml;base64,...">'، وتنتج هذه الأداة بالضبط تلك الصيغة تلقائياً عند إفلات ملف SVG واختيار إخراج HTML.

ما لا يستطيع Base64 تقديمه لملف SVG هو الحفاظ على أكبر ميزاته: التنسيق الحي. يمكن لملف SVG مُلصق مباشرة داخل HTML كترميز <svg> مضمّن أن يتغير لون تعبئته باستخدام currentColor وCSS، وأن يستجيب لحالة :hover، وأن يُتحكم فيه عبر JavaScript، وكل ذلك يصبح مستحيلاً بمجرد تسطيحه إلى سلسلة Base64 معتمة. إذا كنت تحتاج أيقونة قابلة لتغيير السمة، احتفظ بترميز SVG مضمّناً. وإذا كنت تحتاج مرجع صورة قابل للنقل ومعتم، فترميزه بـ Base64 هو القرار الصحيح، وتنجز هذه الأداة هذا التحويل بعملية سحب وإفلات واحدة.

موازنات التخزين المؤقت للمتصفح

يحصل ملف صورة عادي مُشار إليه برابط على إدخال خاص به في ذاكرة التخزين المؤقت HTTP للمتصفح، تحكمه ترويسات Cache-Control التي يرسلها الخادم. زر عشر صفحات تشير جميعها إلى نفس /logo.png، وسيقوم المتصفح بتنزيل ذلك الملف مرة واحدة فقط بالضبط، ثم يعيد استخدام النسخة المخزنة مؤقتاً في كل صفحة لاحقة طالما سمحت ترويسة التخزين المؤقت بذلك، أحياناً لأشهر.

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

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

الاستخدامات الشائعة لهذا المحوّل من صورة إلى Base64

يستخدم المطورون الذين يبنون تطبيقات أحادية الصفحة أو لوحات تحكم داخلية Base64 لرسومات نائبة صغيرة وأيقونات حالة التحميل التي يجب أن تُعرض قبل أن تنتهي حزمة JavaScript الرئيسية من التنزيل، لأن URI بيانات مضمّنة تُرسم فوراً مع أول بايت من HTML، دون انتظار طلب ثانٍ.

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

يستخدم المصممون ومطورو الواجهات الأمامية صيغة إخراج CSS باستمرار لتفاصيل زخرفية صغيرة في الواجهة، وحالات مخصصة لمربعات الاختيار وأزرار الراديو، وقوامات خلفية خفيفة، وبدائل لخطوط الأيقونات، في الحالات التي يكون فيها المورد صغيراً بما يكفي بحيث لا تكاد زيادة الـ 33% تُلاحظ، بينما يُسرّع الطلب الموفَّر فعلياً ظهور أول محتوى مرئي للصفحة.

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

لماذا تعمل هذه الأداة بالكامل داخل متصفحك

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

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

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

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

أدوات تطوير ذات صلة

🔒 خصوصية محلية 100%

يتم فك تشفير وترميز كل صورة <strong>بالكامل داخل متصفحك</strong>. لا يُرفع أي شيء إلى أي خادم. تبقى صورتك على جهازك.