لماذا يجعل Base64 الملفات أكبر؟

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

لماذا يحتاج Base64 مساحة أكبر؟

3 بايتات هي 24 بتًا. يقسم Base64 تلك الـ24 بتًا إلى 4 مجموعات من 6 بتات. كل مجموعة تقابل محرف Base64 واحدًا، فتصبح 3 بايتات إدخال 4 محارف خرج. مخزّنة كبايت واحد لكل محرف ASCII، ذلك 4 / 3 ≈ 1.333 — زيادة بنحو 33.3%.

• 3 بايتات (24 بتًا)
• ↓
• تقسيم إلى 4 مجموعات من 6 بتات
• كل مجموعة → محرف Base64 واحد
• ↓
• 4 محارف (غالبًا 4 بايتات نص)

مثال بسيط يمكن التحقق منه

هذه الترميزات تطابق Base64 القياسي بالحشو.

Man

Man

Base64

TWFu

Man هي 3 بايتات UTF-8/ASCII. TWFu هي 4 محارف: 3 → 4.

Hello

Hello

Base64

SGVsbG8=

Hello هي 5 بايتات. SGVsbG8= هي 8 محارف، منها = واحد. على البيانات الصغيرة يجعل الحشو النسبة تبدو أكبر من 33%.

كيف تحسب حجم Base64؟

لـBase64 القياسي بالحشو، encodedLength = 4 × ceil(originalBytes / 3).

البايتات الأصلية	محارف Base64
1	4
2	4
3	4
4	8
5	8
6	8

بايت واحد أو اثنان ما زالا ينتجان 4 محارف. استخدم الصيغة، لا 33% ثابتًا.

ماذا يعني حشو «=»؟

علامة = تبيّن أن آخر كتلة من 3 بايتات لم تكن مكتملة. بايت إدخال واحد يستخدم محرفي =؛ بايتان يستخدمان واحدًا؛ 3 بايتات لا تستخدم شيئًا. الحشو ليس تشفيرًا ولا ميزة أمان.

هل يستخدم Base64URL مساحة أقل؟

Base64URL يغيّر + إلى - و/ إلى _، وترميز Base64 وفكّه يحذف = اللاحقة عند الترميز. قد يقصّر ذلك السلسلة بتلك المحارف =. بنية 3 بايتات → 4 محارف تبقى كما هي، فـBase64URL ليس تنسيقًا ثنائيًا أوفر مساحة.

لماذا قد تنمو المدخلات الصغيرة بأكثر من 33%؟

1 بايت → 4 محارف زيادة 300% في الطول. 2 بايت → 4 هي 100%. 3 بايتات → 4 نحو 33.3%. مع نمو n يقل أثر الحشو ويقترب الفائض من نحو 33%. Base64 ليس أكبر بنسبة 33% في كل حالة بدقة.

لماذا تكون Data URL بـBase64 أكبر أيضًا؟

تضيف Data URL بادئة مثل data:image/png;base64, قبل الحمولة. على ملف صغير قد تهيمن تلك البادئة على النسبة. يستطيع ترميز Base64 وفكّه إخراج Base64 خام أو Data URL؛ خرج Data URL يستخدم الأبجدية القياسية.

Base64 مقابل الثنائي: أيهما أصغر؟

الثنائي الخام أوفر مساحة للنقل والتخزين. Base64 أكبر، لكنه آمن كنص في JSON والبريد ومسارات النص فقط. ترميز من ثنائي إلى نص، لا ضغط.

هل يضغط Base64 الملفات؟

لا. Base64 ليس تنسيق ضغط. النص المرمّز أكبر عادة من البايتات الأصلية. إن طبّقت لاحقًا gzip أو Brotli على ذلك النص، قد ينكمش بعض التكرار—النتائج تعتمد على البيانات والضاغط. gzip لا يزيل فائض Base64 بالكامل.

ماذا يحدث إن ضُغط Base64 بـgzip؟

قد يقلّل ضغط HTTP بعض الأنماط المتكررة في نص Base64. JPEG أو PNG أو ZIP غالبًا تضغط ضعفًا حتى كبايتات خام، وBase64 ثم gzip ما زال يعتمد على الحالة. لا نسبة فائض عالمية بعد gzip.

هل تخزّن الملفات كـBase64؟

يستطيع Base64 وضع الثنائي في حقل JSON، أو أصل صغير مضمّن، أو واجهة نص فقط، أو نسخ ولصق، أو Data URL. للملفات الكبيرة ينمو التخزين والذاكرة وحجم الحمولة. ذلك ليس «لا تستخدم Base64 للملفات أبدًا».

لماذا يشيع Base64 في واجهات JSON؟

JSON بلا نوع ثنائي خام أصلي، لذا تضع الواجهات البايتات غالبًا في سلسلة Base64. للملفات الكبيرة قد يناسب أكثر multipart/form-data أو تخزين كائنات أو رفع ثنائي مباشر. لا خيار هو الأفضل دائمًا.

لماذا يُستخدم Base64 في البريد؟

يستطيع MIME استخدام Base64 ليسافر مرفق ثنائي كمحارف آمنة للنص. فائض الحجم نفسه ما زال ينطبق. تمثيل نقل، لا ملف أصغر.

متى يستحق الحجم الإضافي؟

قد يستحق الحجم الإضافي عندما يجب أن يقع الثنائي داخل نص، أو الحمولة صغيرة، أو واجهة تطلب Base64، أو تحتاج Data URL. للوسائط الكبيرة فضّل الثنائي الخام عندما يسمح النظام.

متى تتجنب Base64؟

تجاوزه للملفات الكبيرة، أو عرض نطاق ضيق، أو نقل متكرر، أو عندما يوجد مسار ثنائي أصلًا—ظرفي، لا «Base64 ممارسة سيئة».

أطوال Base64 بالحشو يمكنك التحقق منها

عدادات البايتات الأصلية وعدادات محارف Base64 القياسي بالحشو:

البايتات الأصلية	محارف Base64
1	4
2	4
3	4
10	16
100	136
1,000	1,336

كل الصفوف تتبع 4 × ceil(n / 3). هذه عدادات محارف Base64.

مثال: كم يصبح ملف من 1,000 بايت؟

4 × ceil(1000 / 3). ceil(333.333…) = 334، و4 × 334 = 1336. إذن 1,000 بايت تصبح 1,336 محرف Base64. مخزّنة كـUTF-8/ASCII، كل محرف عادة بايت واحد—لا تعامل 1,336 كعداد بايتات دقيق في الذاكرة.

هل قد يستخدم Base64 ذاكرة أكثر مما يوحي حجم الملف؟

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

دليل قرار بسيط للحجم

إن قبل النظام ثنائيًا خامًا، فضّله للحجم. إن سُمح بالنص فقط، قد يناسب Base64. للحمولة الكبيرة ابحث عن مسار رفع ثنائي. لنص آمن في URL فكّر في Base64URL—توسعة 3 إلى 4 تبقى.

• حاجة لإرسال بيانات ثنائية
• ↓
• هل الثنائي الخام مسموح؟ فضّل الثنائي للحجم
• حقل نص فقط؟ قد يناسب Base64
• حمولة كبيرة؟ ابحث عن مسار رفع ثنائي
• تحتاج نصًا آمنًا لـURL؟ فكّر في Base64URL
• ↓
• توقّع نحو 33% نصًا أكثر على المدخلات الكبيرة

رمّز أو فك Base64 في متصفحك

NEXNARA ترميز Base64 وفكّه يرمّز ويفك النص، ويستطيع تحويل ملف إلى Base64 أو Data URL وإعادة Base64 إلى ملف.

يستخدم النص بايتات UTF-8 ثم Base64—لا ASCII فقط. اختر Standard أو Base64URL. خرج الملف قد يكون Base64 خامًا أو Data URL (الأبجدية القياسية). يُرفض الإدخال غير الصالح. البايتات غير UTF-8 تحتاج إلى ملف، لا فكًا كنص.

الملفات فوق 10 MB قد تبطئ التبويب (تحذير). الملفات فوق 32 MB تُحظر.

الترميز والفك يحدثان في متصفحك. لا يُرسل الملف إلى خادم NEXNARA لهذه الأداة. الإعلانات وميزات الموقع الأخرى ما زالت تستخدم الشبكة.

الصق نصًا أو ملفًا في ترميز Base64 وفكّه وقارن البايتات الأصلية بطول المرمّز.

FAQ

لماذا يزيد Base64 حجم الملف؟

يقابل 3 بايتات (24 بتًا) بـ4 محارف (4 × 6 بتات). مخزّنًا كنص، ذلك نحو الثلث أكثر للمدخلات الكبيرة.

هل Base64 أكبر بـ33% دائمًا؟

لا. المدخلات الكبيرة تقترب من نحو 33.3%. المدخلات الصغيرة جدًا قد تنمو أكثر بسبب الحشو. استخدم 4 × ceil(n / 3).

كم أكبر Base64 من الثنائي؟

الطول القياسي بالحشو هو 4 × ceil(n / 3) محرفًا. بادئة Data URL تضيف المزيد.

هل ضغط Base64 يقلّل حجم الملف؟

Base64 لا يضغط. قد يقلّص gzip أو Brotli على النص المرمّز بعضه؛ لا يمحوان الفائض في كل حالة.

هل يستخدم Base64URL مساحة أقل؟

قد يحذف حشو =، فتكون السلسلة أقصر بـ0–2 محرف. بنية الترميز من 3 إلى 4 هي نفسها.

هل أستخدم Base64 للملفات الكبيرة؟

فقط إن احتجت نصًا. للنقل الكبير أو المتكرر غالبًا المسار الثنائي أصغر. Base64 ليس خطأ دائمًا في الواجهات.