Base64 ترميز وفك

Base64 هو نظام ترميز يحوّل البيانات الثنائية (Binary) إلى نص ASCII قابل للقراءة. كل ثلاث بايتات من البيانات الأصلية تتحوّل إلى أربعة أحرف من أبجدية محدّدة مكوّنة من 64 رمزاً فقط — وهذا هو سبب التسمية.

المعيار الرسمي موثّق في RFC 4648، وهو امتداد لمعايير قديمة تعود إلى RFC 1521 من 1993 لتوصيل المرفقات في البريد الإلكتروني (MIME). اليوم يُستخدم في كل تطبيقات الويب تقريباً: JWT، Data URI، رفع الصور، OAuth، PEM certificates، حتى QR زاتكا.

البيانات الثنائية (صور، فيديو، ملفات تنفيذية) تحتوي بايتات بقيم 0-255، بعضها أحرف تحكّم (control characters) أو غير قابلة للطباعة. كثير من الأنظمة القديمة — البريد الإلكتروني خصوصاً — صُمّمت لنقل نص ASCII بسيط فقط (7-bit safe). محاولة إرسال صورة عبر SMTP خامة يكسرها لأن بعض البايتات تُفسَّر كأوامر بروتوكول.

الحلّ: نُحوِّل البيانات إلى نص يستخدم فقط أحرف A-Z، a-z، 0-9، +، /. هذه الأحرف آمنة في أي بروتوكول نصّي. النتيجة: حجم أكبر بنسبة 33% تقريباً (4 أحرف لكل 3 بايتات)، لكن نقل موثوق 100%.

خوارزمية Base64 بسيطة جداً. تأخذ ثلاث بايتات (24 بت) وتُقسّمها إلى أربع مجموعات من 6 بتات. كل مجموعة 6 بتات يمكنها تمثيل قيمة من 0 إلى 63 — وهذه القيمة تُترجَم إلى حرف من الأبجدية.

مثال عملي: ترميز كلمة Hi!

الأحرف الثلاثة في ASCII: H=72، i=105، !=33. بالنظام الثنائي: 01001000 01101001 00100001. نقسمها إلى مجموعات 6-بت: 010010 000110 100100 100001. القيم العشرية: 18، 6، 36، 33. ومن جدول الأبجدية: S، G، k، h. النتيجة: SGkh.

لاحظ: 3 بايتات أصلية = 4 أحرف Base64. هذا التضخّم الثابت 33% هو السعر الذي ندفعه مقابل أن نُمرّر بياناتنا الثنائية عبر قنوات نصّية بأمان.

الأبجدية القياسية في RFC 4648 §4:

• 0-25: الأحرف الإنجليزية الكبيرة A إلى Z.
• 26-51: الأحرف الصغيرة a إلى z.
• 52-61: الأرقام 0 إلى 9.
• 62: الرمز +
• 63: الرمز /
• علامة الـ padding: =

مجموع 64 حرف للترميز + علامة واحدة للحشو. لاحظ: أي حرف خارج هذه القائمة (مثل مسافة، فاصلة، أو حرف عربي) في سلسلة Base64 يعني أنّها معطوبة أو مرّت بترميز ثانٍ.

ماذا يحدث لو لم يكن طول البيانات الأصلية مضاعفاً للرقم 3؟ مثلاً: حرف واحد A = 1 بايت = 8 بتات. نحتاج 6-بت لكل حرف Base64، فماذا نفعل بالـ 4 بتات الناقصة؟

الحلّ: نُكمل بأصفار حتى تصل المجموعة إلى 6 بتات، ونضيف = لكل مجموعة بايتات ناقصة. القاعدة: 1 بايت أصلي → XX==، 2 بايت → XXX=، 3 بايت → XXXX (بدون padding). أمثلة:

• A → QQ==
• AB → QUI=
• ABC → QUJD
• ABCD → QUJDRA==

أداتنا تتسامح مع غياب الـ padding عند فكّ الترميز وتُضيفه تلقائياً — كثير من المكتبات تُسقطه لتوفير حروف في الـ URL.

Base64 القياسي يستخدم + و /، لكنّهما حرفان لهما معنى خاص في عناوين URL: + يعني مسافة و / يُقسّم مسار العنوان. لو وضعت Base64 خام في URL، سيتعطّل.

الحلّ: Base64URL (موثّق في RFC 4648 §5). يستبدل:

• + → - (شرطة)
• / → _ (شرطة سفلية)
• علامات = تُحذَف عادةً (لأنّها أيضاً محجوزة)

مثال: SGVsbG8/ بالقياسي تصير SGVsbG8_ بالـ URL-safe. JWT و OAuth و كل التوكينات الحديثة تستخدم Base64URL — لذلك تجد التوكين دائماً يبدأ بـ eyJ (لأنّ { بالـ Base64 = eyJ) ولا يحتوي + أو /.

أداتنا تدعم الوضعين — فعّل خيار URL-safe لو كنت تنشئ توكين أو رابط، وأبقه مغلقاً للترميز القياسي.

مشكلة شهيرة جداً: تكتب btoa("مرحبا") في وحدة تحكّم المتصفّح وتظهر رسالة InvalidCharacterError: The string contains characters outside of the Latin1 range. السبب؟ دالة btoa الأصلية مُصمَّمة لـ Latin1 فقط (بايتات 0-255)، والحرف العربي يحتاج بايتين أو ثلاثة في UTF-8.

الحلّ الصحيح في 2026:

• للترميز: حوّل النص إلى بايتات UTF-8 أولاً باستخدام TextEncoder().encode(str)، ثم رمّز البايتات.
• لفكّ الترميز: فُكّ Base64 إلى بايتات، ثم استخدم TextDecoder('utf-8').decode(bytes).

أداتنا تستخدم هذا النهج بالضبط — لذا مرحبا تُرمَّز بشكل صحيح إلى 2YXYsdit2KjYpw==. النصائح القديمة على Stack Overflow التي تستخدم unescape(encodeURIComponent(str)) تعمل لكنّها مُهملة (deprecated) ولا يجب استخدامها في كود جديد.

الـ Data URI (موثّق في RFC 2397) يسمح لك بتضمين ملف كامل مباشرة في HTML أو CSS بدون رفعه على خادم. الصيغة:

data:[MIME-type];base64,[Base64-string]

أمثلة:

• صورة PNG صغيرة: <img src="data:image/png;base64,iVBORw0K…" />
• SVG في CSS: background: url('data:image/svg+xml;base64,PHN2…');
• تنزيل PDF من جافاسكريبت: <a href="data:application/pdf;base64,JVBE…" download>

متى تستخدم Data URI؟

استخدمه لـ: أيقونات صغيرة (أقل من 4KB)، شعارات SVG، صور بريد إلكتروني (لأن المرفقات تُحجَب أحياناً)، توليد PDF/Excel ديناميكياً وعرض زرّ تنزيل فوري.

تجنّبه لـ: صور أكبر من 8KB (أبطأ من رابط عادي بسبب فقدان التخزين المؤقّت)، ملفات يُعاد استخدامها في صفحات متعدّدة، أي شيء يضرّ بـ Core Web Vitals (LCP خصوصاً).

JSON Web Token (JWT) هو معيار توكين مستخدم في تسجيل الدخول، OAuth، و APIs آمنة. أي JWT يتكوّن من ثلاثة أجزاء مفصولة بنقاط: HEADER.PAYLOAD.SIGNATURE. كل جزء مُرمَّز بـ Base64URL (لا Base64 القياسي).

مثال JWT حقيقي:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFobWVkIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

فُكّ ترميز الجزء الأول (eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9) بأداتنا — اختر فك الترميز، وستحصل على: {"alg":"HS256","typ":"JWT"}. لاحظ: المحتوى مكشوف تماماً — JWT يُوقّع لإثبات الأصل لا ليُخفي البيانات. لا تضع كلمات مرور أو أرقام بطاقات داخل JWT أبداً.

أول استخدام واسع لـ Base64 كان في بروتوكول البريد RFC 1521 سنة 1993. SMTP صُمّم لنقل نص ASCII 7-bit فقط، فأي مرفق (صورة، PDF، Word) يجب أن يُرمَّز قبل الإرسال. حتى اليوم، لو فتحت raw email تجد:

Content-Type: image/jpeg
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAYABgAAD…

هذا أيضاً سبب أن المرفقات الضخمة (5MB صورة) تصير 6.7MB في البريد. كل خادم بريد إلكتروني في العالم يفك Base64 ملايين المرّات يومياً منذ 30 سنة.

في فاتورة زاتكا الإلكترونية (Phase 1 و 2)، يُولَّد QR Code يحتوي 5 حقول TLV: اسم البائع، الرقم الضريبي، التاريخ، الإجمالي، VAT. هذه الحقول تُرمَّز بصيغة Tag-Length-Value (TLV) ثنائية، ثم تُحوَّل كاملاً إلى Base64 قبل وضعها في QR.

مثال: لو اسم البائع "متجر السلام" والرقم الضريبي 300012345600003، تُبنى البايتات TLV ثم تُرمَّز إلى نص Base64 طويل، وهذا النص هو ما يُقرأه تطبيق زاتكا. أي خطأ في الترميز يجعل QR غير صالح ويُرفَض من التطبيق.

أداة ZATCA XML Converter تستخدم نفس الخوارزمية تلقائياً.

الخطأ الأمنيّ الأشهر: ظنّ أن Base64 يُخفي البيانات. لا. Base64 ترميز (encoding) لا تشفير (encryption). أيّ شخص يرى نص Base64 يستطيع فكّه في ثانية باستخدام أداتنا أو وحدة تحكّم المتصفّح. لا يوجد مفتاح، لا كلمة سر، لا سرّ.

أمثلة على إساءة استخدام شائعة في 2024-2026:

• تطبيقات تحفظ كلمة المرور كـ Base64 في قاعدة البيانات ظنّاً أنّها "مشفّرة".
• مطوّرون يضعون Authorization: Basic dXNlcjpwYXNz في headers HTTP بدون HTTPS — أي شخص يلتقط الحركة يستخرج كلمة المرور فوراً.
• تطبيقات "تُخفي" مفاتيح API في كود الفرونت إند بـ Base64.

قاعدة ذهبية:لو رأيت Base64 في سياق "أمني"، فهو إمّا حامل لشيء مُشفّر فعلاً (مثل JWT الذي يستخدم HMAC-SHA256)، أو هو ثغرة أمنية. للأمان الفعليّ تحتاج AES، RSA، أو HMAC — لا Base64.

• خلط Base64 بـ Base64URL: لا تستطيع فكّ توكين JWT بمكتبة Base64 قياسية. تأكّد من تفعيل وضع URL-safe.
• نسيان padding: بعض المكتبات تحذف =، أخرى تشترطها. الحلّ: أضفها أو احذفها قبل التمرير.
• استخدام btoa مع نص عربي: سيرمي InvalidCharacterError. استخدم TextEncoder.
• نسخ Base64 من PDF أو Word: أحياناً تُضاف مسافات أو أحرف سطر جديد غير مرئية. أداتنا تتجاهل المسافات تلقائياً.
• توقّع أن Base64 يضغط البيانات: العكس صحيح — يكبّر الحجم 33%.
• استخدامه لإخفاء بيانات حسّاسة: راجع القسم السابق.

أداة arabtoolbox لترميز Base64 تعمل 100% في متصفّحك عبر JavaScript. لا توجد اتصالات بخوادم، لا تخزين، لا تسجيل لمدخلاتك أو ملفاتك. بعد إغلاق التبويبة لا يبقى أي أثر.

هذا مهمّ خاصةً عند ترميز:

• وثائق رسمية (عقود، شهادات، فواتير).
• توكينات JWT حقيقية (لا تلصقها في موقع أجنبي يحفظ السجلّات).
• محتوى تجاري حساس (مفاتيح API، PEM keys).

الأداة تعمل أوفلاين أيضاً — حمّل الصفحة مرّة، ثم اقطع الإنترنت، وستبقى تعمل.

هل Base64 أبطأ من الإرسال الثنائي المباشر؟ نعم. الحجم أكبر 33%، والترميز/فكّه يستهلك CPU. لكن في معظم التطبيقات الويب، الفرق غير ملحوظ — والفائدة (نقل آمن عبر بروتوكولات نصّية) تستحقّ.

ما الفرق بين Base64 و Base32 و Base16 (Hex)؟ الفرق في عدد أحرف الأبجدية. Base16 (الست عشري) يستخدم 16 رمزاً ويُضاعِف الحجم (200%). Base32 يستخدم 32 رمزاً ويُضخّم 60%. Base64 الأكثر كفاءة في النصوص بـ 33% فقط. Base32 يُستخدم في TOTP (المصادقة الثنائية)، Base16 في عرض الـ hashes.

هل أحتاج مكتبة خارجية لـ Base64 في 2026؟ لا. المتصفّحات الحديثة و Node.js تدعم btoa/atob و Buffer.from(str).toString('base64') طبيعياً. للنص متعدّد البايتات (عربي، إيموجي)، استخدم TextEncoder/TextDecoder كما تفعل أداتنا.

كم حجم القفز للحجم بعد الترميز؟ 33.33% بالضبط (4 أحرف لكل 3 بايتات)، زائد 1-2 حرف padding في النهاية. ملف 9KB يصير 12KB. هذا ثابت.

هل يمكن ترميز فيديو 50MB بـ Base64؟ تقنياً نعم، عملياً لا. ستحصل على نص 67MB في الذاكرة، أبطأ بكثير من مجرّد رفع الملف. للملفات الكبيرة استخدم FormData + multipart/form-data. أداتنا تحدّد الملفات إلى 5MB لمنع تجميد المتصفّح.

لماذا أرى Base64 في فواتير زاتكا والتوكينات الخليجية؟ لأنّ QR Codes و JSON tokens تحتاج نقل بيانات ثنائية في حقول نصّية. كل API حكوميّ حديث في الخليج (زاتكا، أبشر، نفاذ، UAEPass) يستخدم Base64 في مكان ما — عادةً لتوقيعات RSA أو حمولات JWT.

متى أستخدم Base64URL بدل Base64؟ في أي مكان قد يظهر فيه النص داخل URL، header HTTP، أو اسم ملف. JWT، OAuth tokens، query strings، JSON Web Keys (JWK). أبقِ Base64 القياسي لـ Data URIs و MIME emails.

الأداة في أعلى الصفحة تدعم: ترميز وفكّ النصوص العربية والإنجليزية، رفع الملفات حتى 5MB (صور، PDF، أيّ ملف) إلى Data URI، وضع URL-safe لـ JWT والروابط، عرض مباشر للأخطاء، نسخ بضغطة. كل شيء محلّي في متصفّحك — جرّبها فوراً.