Base64 أم Hex أم Binary: أي ترميز تستخدم؟

الترميز من المواضيع التي تبدو غامضة لأن الناس يخلطون بين الكلمات. شخص يقول "أرسلها binary"، وآخر يقول "حولها Base64"، وسجل الأخطاء يعرض قيمة طويلة بنظام hex، ثم يبدأ السؤال الحقيقي: كيف نكتب هذه البايتات حتى تنتقل بأمان من مكان إلى آخر؟

Base64 و Hex و Binary كلها تدور حول تمثيل البايتات. هي ليست تشفيرا. ليست ضغطا. ولا تجعل البيانات السرية آمنة. هي فقط تغير طريقة كتابة البيانات أو نقلها. ومع ذلك فالاختيار مهم جدا في واجهات API، الملفات، الصور، التوكنات، الهاشات، قواعد البيانات، البريد، الروابط، وسجلات التصحيح.

هذا الدليل يشرح الفرق بينها من زاوية عملية: الحجم، سهولة القراءة، أمان النقل عبر النص، التصحيح، والأخطاء الشائعة.

نفس البيانات بثلاث طرق

النص BuildQuill يتحول في الذاكرة إلى بايتات. يمكن عرض هذه البايتات كـ Hex:

4275696c645175696c6c

ويمكن عرضها كـ Base64:

QnVpbGRRdWlsbA==

ويمكن تخيلها كـ Binary bits:

01000010 01110101 01101001 01101100

المعنى الأصلي واحد. الاختلاف هو طريقة التمثيل. هل تريد أصغر حجم؟ هل تريد نصا آمنا داخل JSON؟ هل تريد قيمة سهلة المقارنة بالعين؟ الإجابة تحدد الصيغة.

Binary: البيانات كما هي

Binary أو البيانات الثنائية هي الشكل الحقيقي للملفات والبايتات. صورة PNG، ملف PDF، فيديو، ملف ZIP، أو مخرجات تشفير، كلها في النهاية بايتات. إذا كان الملف حجمه 1MB على القرص، فهو 1MB من البيانات الثنائية.

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

المشكلة أن ليس كل مكان يقبل bytes خام. JSON نص. XML نص. بعض قواعد البيانات أو الحقول تتوقع نصا. الروابط لها محارف محجوزة. البريد القديم كان نصيا. السجلات قد تكسر المحارف غير القابلة للطباعة. إذا مررت بيانات binary في قناة نصية بدون ترميز، قد تتلف أو ترفض.

لذلك نستخدم Base64 أو Hex عندما تحتاج البايتات أن تعيش داخل نص.

Binary مناسب للملفات، التخزين الثنائي، الشبكات، الأداء العالي، وأي قناة تعرف أنها تتعامل مع bytes حقيقية.

Hex: واضح للمطورين ومفيد للتصحيح

Hex أو النظام الست عشري يكتب كل بايت بحرفين من 0-9 و a-f. البايت 255 يصبح ff، والبايت 0 يصبح 00. القاعدة بسيطة جدا: كل بايت يساوي حرفين.

استخدم Hex عندما تحتاج رؤية دقيقة للبايتات، أو عندما تكون القيمة قصيرة: هاش، checksum، معرف قصير، لون في CSS، أو عينة من ملف أثناء التصحيح.

ميزة Hex أنه متوقع. إذا كانت البيانات 32 بايت، فالنتيجة 64 حرفا. إذا كان طول النص hex فرديا، فغالبا هناك خطأ. إذا ظهر حرف خارج النطاق المسموح، فالقيمة ليست Hex سليمة. هذا يجعل التحقق والتصحيح أسهل.

لهذا ترى SHA-256 غالبا بصيغة Hex:

2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

العيب هو الحجم. Hex يضاعف البيانات. ملف 5MB يصبح 10MB كنص Hex. هذا مقبول لهاش صغير، لكنه سيئ لملف كبير. Hex ممتاز عندما يريد الإنسان المقارنة أو الفحص، وليس عندما تريد نقل ملفات ضخمة.

Hex مناسب للهاشات، checksums، التصحيح، معرفات قصيرة، وعرض البايتات بطريقة مفهومة.

Base64: جسر البايتات داخل النص

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

استخدم Base64 عندما تحتاج وضع ملف أو bytes داخل JSON أو XML أو HTML أو CSS أو بريد أو متغير بيئة. مثلا: صورة صغيرة داخل data URL، شهادة داخل متغير بيئة، ملف داخل طلب JSON، أو مخرجات تشفير داخل نص.

Base64 منتشر لأنه يحل مشكلة حقيقية: كيف أضع بيانات binary في مكان يقبل النص فقط؟ الجواب غالبا Base64.

لكن Base64 ليس مريحا للعين. لا تستطيع قراءة قيمته وفهم المحتوى. تحتاج أداة لفك الترميز. كما أن له نسخا مختلفة. Base64 العادي يستخدم + و / وقد ينتهي بـ =. أما Base64URL فيستخدم - و _ وغالبا يحذف padding. لذلك قد تفشل أداة في فك قيمة JWT إذا تعاملت معها كـ Base64 عادي.

Base64 مناسب للبيانات الثنائية داخل النصوص، payload في JSON، مرفقات البريد، data URLs، الشهادات، والقيم التي يجب نقلها بأمان عبر قناة نصية.

مقارنة سريعة

القاعدة المختصرة: Binary عندما تسمح القناة بالبايتات، Base64 عندما تضطر لاستخدام نص، Hex عندما تريد رؤية البايتات ومقارنتها.

أمثلة عملية

إذا كنت ترسل صورة عبر API، الأفضل غالبا رفعها كملف binary أو إرسال رابط بعد رفعها إلى التخزين. إذا كان لا بد من وضعها داخل JSON، استخدم Base64. لكن انتبه للحجم، فالطلب سيكبر.

إذا كنت تعرض checksum لملف تحميل، استخدم Hex. الناس اعتادوا مقارنة SHA-256 و MD5 كقيم Hex، وهي أسهل في النسخ والمراجعة.

إذا كنت تخزن PDF في قاعدة بيانات، استخدم عمود binary أو blob إن وجد. لا تحوله إلى Base64 فقط لأنه يبدو كنص لطيف. ستدفع ثمنا في الحجم والمعالجة.

إذا كنت تتعامل مع JWT، تذكر أنه يستخدم Base64URL للأجزاء الثلاثة. وجود النقاط بين الأجزاء لا يعني أن التوكن مشفر. غالبا يمكن قراءة header و payload بعد فك Base64URL، لكن التوقيع هو الذي يثبت السلامة.

إذا كنت ترى قيمة طويلة لا تفهمها، افحص شكلها. هل هي Hex فقط وبطول زوجي؟ جرب Hex. هل تحتوي + أو / أو =؟ جرب Base64. هل تحتوي - و _ وبدون padding؟ جرب Base64URL.

الترميز ليس أمانا

هذه نقطة مهمة جدا. Base64 ليس تشفيرا. Hex ليس تشفيرا. Binary ليس تشفيرا. إذا حولت كلمة مرور إلى Base64، فأنت لم تحمها. أنت فقط جعلتها تبدو غير مفهومة لشخص لا يعرف Base64. أي شخص يستطيع فكها في ثانية.

التشفير يعني أن البيانات لا تقرأ بدون مفتاح. الهاش يعني بصمة باتجاه واحد. الضغط يعني تقليل الحجم. الترميز يعني تغيير طريقة التمثيل. لا تخلط بينها.

إذا طلبت خدمة "Base64 encode your API key"، فهي غالبا تريد جعله صالحا داخل header أو payload. هذا لا يعني أن المفتاح صار آمنا للنشر.

لماذا الحجم مهم؟

في القيم الصغيرة لا يهم كثيرا. لكن في الملفات الكبيرة يصبح الفرق واضحا. ملف 10MB يصبح تقريبا 13.3MB في Base64، و20MB في Hex. ثم تضعه داخل JSON، ثم تسجله في logs، ثم تمرره في الذاكرة، ثم ترسله عبر الشبكة. الزيادة الصغيرة تصبح عبئا.

لهذا لا يفضل إرسال ملفات كبيرة كـ Base64 داخل JSON إلا إذا كانت القيود تجبرك. استخدم upload مباشر أو تخزين ملفات عندما تستطيع.

نصائح لـ Base64

اعرف النوع المستخدم: عادي، URL-safe، مع padding أو بدونه. لا تكسر السطور إلا إذا كان النظام يتوقع ذلك. تحقق من صحة القيمة قبل فكها إذا كانت من المستخدم. ولا تستخدم Base64 لتخزين أسرار وكأنها مشفرة.

نصائح لـ Hex

وحد حالة الأحرف. lowercase شائع، لكن uppercase صحيح أيضا. تحقق أن الطول زوجي. استخدم Hex للهاشات والقيم القصيرة. لا تستخدمه للملفات الكبيرة لأنه يضاعف الحجم.

نصائح لـ Binary

استخدم Binary عندما تكون القناة تدعمه. لا تعامل bytes عشوائية كأنها UTF-8. احتفظ بالمعلومات الإضافية مثل نوع الملف والاسم والحجم والهاش في metadata واضحة.

مشاكل واقعية في الترميز

أكثر مشكلة أراها مع Base64 هي نسيان النوع المستخدم. قيمة JWT مثلا ليست Base64 عادي دائما، بل Base64URL. الفرق صغير في الشكل، لكنه يكسر فك الترميز. إذا رأيت - و _ بدلا من + و / فانتبه. وإذا كانت القيمة لا تنتهي بـ =, فهذا لا يعني أنها خاطئة؛ بعض الأنظمة تحذف padding.

مشكلة أخرى هي ترميز النص قبل تحويله. النص ليس bytes حتى تختار encoding. النص العربي مثلا يجب أن يمر غالبا عبر UTF-8 قبل Base64. إذا استخدم طرف UTF-8 وطرف آخر UTF-16، ستحصل على قيم مختلفة رغم أن النص يبدو نفسه. لذلك عند توثيق API، لا تقل فقط "Base64 encode the value"، بل قل "encode the UTF-8 bytes as Base64".

في Hex، الخطأ الشائع هو فقدان الصفر الأول. البايت 0f ليس نفسه f عند تمثيل سلسلة bytes، لأن كل بايت يحتاج حرفين. لذلك يجب الحفاظ على الطول الزوجي. كذلك لا تجعل المقارنة تفشل بسبب uppercase و lowercase؛ حول القيم إلى شكل موحد قبل المقارنة.

في Binary، المشكلة تأتي عند تمريره في مكان نصي. قد يعمل في اختبار صغير لأن البيانات كانت حروفا عادية، ثم يفشل مع ملف حقيقي يحتوي bytes غير قابلة للطباعة. لا تعتمد على الحظ. إذا كانت القناة نصية، استخدم ترميزا نصيا واضحا.

كيف توثق قيمة مرمزة؟

التوثيق الجيد للترميز يجيب عن أربعة أسئلة. ما البيانات الأصلية؟ ما encoding النص قبل التحويل؟ ما صيغة الترميز؟ وهل توجد خطوة فك أو تحقق بعد الاستلام؟

مثال سيئ:

send file as base64

مثال أفضل:

Read the file bytes, encode them with standard padded Base64, and send the result in the "file_data" JSON field.

لو كانت القيمة داخل URL، اذكر Base64URL. لو كانت hash، اذكر هل هو Hex lowercase أو Base64. لو كانت قيمة سرية، اذكر أن الترميز لا يغني عن HTTPS ولا عن إدارة أسرار صحيحة.

هذه التفاصيل تبدو صغيرة، لكنها تمنع ساعات من رسائل "القيمة عندي مختلفة" و"الأداة لا تفك التوكن" و"الملف يصل تالفا". الترميز لا يكون صعبا عندما يكون العقد واضحا.

كيف تختار؟

اسأل: هل المستلم يقبل bytes مباشرة؟ إذا نعم، استخدم Binary. هل تحتاج وضع البيانات داخل نص مثل JSON أو XML؟ استخدم Base64. هل تريد أن يقارن المطورون القيمة أو يفحصوا البايتات؟ استخدم Hex. هل القيمة داخل URL؟ استخدم Base64URL أو ترميزا مناسبا للرابط.

قاعدة أخيرة قبل الإرسال

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

الخلاصة

Binary هو الشكل الحقيقي والأصغر. Hex هو الشكل الواضح للعين والمفيد للتصحيح والهاشات. Base64 هو الشكل العملي لنقل bytes داخل النصوص. لا تستخدم الترميز كبديل للأمان، ولا تستخدم صيغة كبيرة بلا سبب. اختر حسب القناة والمستلم وحجم البيانات.