حوّل النص إلى سلسلة Base64 قياسية أو فكّ تشفير Base64 الصحيح إلى نص. الأداة مناسبة للأجزاء الصغيرة عند العمل مع API و JSON والتهيئات و HTML وسجلات التتبع. صُمم Base64 لتمثيل البيانات الثنائية بأحرف نصية، وليس لحمايتها.
ماذا يفعل Base64
يخزن الحاسوب النصوص والملفات كمتتاليات من البايتات. لا تتعامل كل قنوات النقل بشكل مريح مع البايتات العشوائية، لذلك يحولها Base64 إلى مجموعة محدودة من أحرف ASCII القابلة للطباعة.
تستخدم الأبجدية القياسية ما يلي:
- الحروف اللاتينية
A–Zوa–z؛ - الأرقام
0–9؛ - الرموز
+و/؛ - علامة
=للإكمال في النهاية عند الحاجة.
مثال:
النص الأصلي: العربية
Base64: 2YHYp9mI2KfYqQ==
فك تشفير هذه السلسلة يعيد متتالية البايتات الأصلية، ثم تحاول الأداة عرضها كنص.
Base64 ليس تشفيرًا
يمكن لأي شخص أو برنامج فك تشفير سلسلة مشفّرة. لا يحتوي Base64 على مفتاح سري أو كلمة مرور أو آلية لتقييد الوصول.
لذلك لا يمكن استخدام Base64 كحماية لما يلي:
- كلمات المرور؛
- مفاتيح API والرموز المميزة؛
- البيانات الشخصية؛
- المستندات الخاصة؛
- معلومات الدفع؛
- أسرار التهيئة.
يغير الترميز تمثيل البيانات لكنه لا يجعلها سرية. مصطلح «فك تشفير Base64» غير دقيق تقنيًا: الصحيح هو «فك ترميز».
Base64 لا يضغط البيانات
تتحول كل ثلاثة بايتات أصلية عادةً إلى أربعة أحرف Base64. يمكن تقدير الحجم الدقيق للنتيجة دون فواصل الأسطر كالتالي:
4 × ceil(عدد البايتات الأصلية / 3)
بالنسبة للبيانات الكبيرة بدرجة كافية، يزيد الحجم بحوالي الثلث. بالنسبة للسلاسل القصيرة، قد تكون الزيادة النسبية أكبر بسبب التقريب وعلامات =.
لا يُستخدم Base64 لتوفير المساحة، بل عندما يلزم نقل البيانات بأمان عبر تنسيق نصي. إذا كان الحجم مهمًا، يُستخدم ضغط مناسب أولاً، ثم Base64، فقط عندما يتطلب النقل ذلك فعلاً.
لماذا ترميز النص مهم
يشفر Base64 البايتات، وليس الحروف المجردة. قبل الترميز، يجب تحويل النص إلى بايتات، غالبًا باستخدام UTF-8.
نفس السلسلة في UTF-8 أو UTF-16 أو أي ترميز آخر ستعطي نتائج Base64 مختلفة. عند فك التشفير، يجب أيضًا قراءة البايتات بالترميز الصحيح. إذا ظهرت أحرف غير مقروءة بدلاً من الأحرف العربية، فالسبب المحتمل هو عدم تطابق الترميز، وليس خطأ في خوارزمية Base64.
كيف يختلف Base64url عن Base64 العادي
في عناوين URL وملفات تعريف الارتباط وبعض الرموز المميزة، قد تكون الرموز + و / و = غير ملائمة. لذلك يعرّف RFC 4648 متغيرًا آمنًا لعناوين URL: Base64url.
| Base64 القياسي | Base64url |
|---|---|
+ |
- |
/ |
_ |
الإكمال = يُحتفظ به عادةً |
الإكمال غالبًا ما يُحذف إذا كان طوله معروفًا |
هذه متغيرات أبجدية مختلفة. لا يمكن دائمًا تمرير سلسلة Base64url كما هي إلى مفكك Base64 القياسي دون تحضير. عند الحاجة، تُستبدل الرموز ويُستعاد الإكمال المفقود إلى طول من مضاعفات الأربعة.
عادةً ما تُعرض أجزاء JWT عبر Base64url، وليس عبر Base64 القياسي. يسمح فك تشفيرها بقراءة محتوى الرأس والحمولة، لكنه لا يؤكد صحة الرمز: للتحقق من ذلك، يجب التحقق من التوقيع المشفر.
أين يُستخدم Base64 فعليًا
واجهات API النصية وتنسيقات البيانات
تتطلب بعض الواجهات إدراج بيانات ثنائية أو سلسلة خاصة داخل JSON أو XML أو رسالة نصية أخرى. يسمح Base64 بنقل البايتات دون تعارض مع أحرف التحكم في النقل.
MIME والبريد الإلكتروني
يمكن استخدام Base64 لتمثيل المرفقات والمحتوى في رسائل MIME. يحتوي تنسيق البريد الإلكتروني المحدد أيضًا على رؤوس وقواعد لتقسيم الأسطر، لذا فإن سلسلة Base64 وحدها لا تكفي لتشكيل بريد إلكتروني كامل.
Data URL
يمكن تضمين مورد صغير في HTML أو CSS:
data:image/png;base64,iVBORw0KGgo...
يُحدد نوع MIME قبل Base64. يزيد التضمين من حجم النص ويحرم المورد من التخزين المؤقت المنفصل العادي، لذا فهو غير مناسب لجميع الملفات.
المصادقة الأساسية HTTP
في رأس Basic Auth، يتم دمج اسم المستخدم وكلمة المرور وتشفيرهما باستخدام Base64. هذا لا يحمي بيانات الاعتماد بحد ذاته؛ يعتمد أمان النقل على HTTPS.
سجلات التتبع وتصحيح الأخطاء
يساعد فك التشفير في فهم محتوى جزء صغير من استجابة API أو سجل تتبع أو تهيئة. لكن لا يُمكن إدراج أسرار الإنتاج أو البيانات الشخصية في أدوات الطرف الثالث عبر الإنترنت.
لماذا لا تُفك تشفير السلسلة
الأسباب الأكثر شيوعًا:
- السلسلة مقتطعة؛
- استخدام رموز Base64url
-و_بينما يتوقع المفكك+و/؛ - غياب علامات الإكمال
=اللازمة؛ - وجود مسافات أو فواصل أسطر أو أحرف غريبة؛
- نسخ بادئة Data URL مع البيانات؛
- البايتات الأصلية ليست نصًا؛
- تطبيق ترميز نصي خاطئ بعد فك التشفير.
يختلف السلوك الصارم للمفككات: بعضها يتجاهل المسافات أو يستعيد الإكمال، بينما يرفض البعض الآخر السلسلة. للتكامل، استرشد بمتطلبات المكتبة والبروتوكول المستخدم.
النص والملفات مهمتان مختلفتان
هذه الأداة مصممة للنص. على الرغم من إمكانية تمثيل أي ملف تقنيًا في Base64، إلا أنه لملف كبير أو صورة أو أرشيف أو مستند، من الأكثر عملية استخدام مشفر ملفات أو مكتبة برمجية. قد تؤدي محاولة فتح بايتات ثنائية عشوائية كنص إلى نتيجة غير مقروءة أو فقدان البيانات عند النسخ.
الأمان عند استخدام المحول عبر الإنترنت
لا تُدرج كلمات مرور حقيقية أو مفاتيح خاصة أو رموز وصول أو ملفات تعريف ارتباط للمصادقة أو بيانات شخصية أو مستندات سرية. حتى عندما يُعلن أن المعالجة تتم في المتصفح، الممارسة الآمنة هي استخدام الأدوات المحلية للبيانات السرية واستبدال القيم بأمثلة اختبارية.
الأسئلة الشائعة
هل يمكن استعادة النص الأصلي من Base64؟
نعم، إذا لم تكن السلسلة تالفة، واستُخدم المتغير الصحيح من Base64، وتمثل البايتات الأصلية بالفعل نصًا بترميز معروف.
لماذا توجد علامة = واحدة أو اثنتان في النهاية؟
هذا هو الإكمال الذي يضبط المجموعة الأخيرة على الطول المطلوب. إنه ليس جزءًا من النص الأصلي.
لماذا يعطي برنامجان سلسلتين مختلفتين لنفس النص؟
قد يستخدمان ترميزات نصية مختلفة، أو Base64 أو Base64url، أو يتضمنان BOM، أو يعالجان سطر النهاية بشكل مختلف.
هل يمكن تخزين كلمة المرور في Base64؟
لا. Base64 قابل للعكس بسهولة وليس مصممًا لتخزين كلمات المرور بشكل آمن. لتخزين كلمات المرور على الخادم، تُستخدم خوارزميات خاصة لتجميع كلمات المرور مع الملح ومعاملات التكلفة المناسبة.
هل فك تشفير JWT يعني أن الرمز أصلي؟
لا. فك التشفير يعرض البيانات فقط. يتم تأكيد الأصالة والسلامة من خلال التحقق المستقل من التوقيع وفقًا لقواعد النظام.
الأدوات ذات الصلة: مولد كلمات المرور؛ معالج النصوص؛ Diffchecker.
المعيار الرسمي:
- RFC 4648 — Base-N Encodings: https://www.rfc-editor.org/rfc/rfc4648
