🚀 بداية سريعة

أدخل نصًا (عاديًا أو سلسلة Base64) في الحقل
انقر “ترميز” أو “فك ترميز” لبدء المعالجة
المُدخل والنتيجة في الحقل نفسه؛ انسخ أو امسح بنقرة واحدة
للتحقق: رمّز ثم بدّل إلى “فك ترميز”

📌 سيناريوهات شائعة

عناوين URL/JWT: يُفضَّل استخدام صيغة URL‑safe (−/_); يمكن حذف «=» النهائي لتجنّب مشاكل الهروب
البريد/MIME: عند الحاجة إلى التفاف استخدم 76 خانة (CRLF) وفق MIME؛ وللويب لا تُضِف التفافًا. توفّر هذه الأداة التفاف 76 خانة وخيار LF/CRLF
نص متعدد الأسطر: فعّل الترميز سطرًا بسطر لترميز كل سطر على حدة
MIME/PEM: فعّل تقسيم 76 خانة؛ واستخدم LF عند الحاجة
Data URL: عند التضمين أنشئ data:[mime];base64,…؛ أداة الفك تستخرج تلقائيًا ما بعد الفاصلة
تحقق ذهابًا وإيابًا: رمِّز ثم فك الترميز فورًا للتأكد من التطابق

🎛️ معلمات الترميز والمتغيرات

إخراج URL‑safe
ترميز سطرًا بسطر (كل سطر مستقل)
تقسيم إلى كتل عرضها 76 حرفًا بأسلوب MIME (CRLF)
استخدام LF للفواصل (\n)
إكمال padding تلقائيًا: يجب أن يكون الطول من مضاعفات 4؛ الطول غير الصحيح يعطِي خطأ
تجاهل الفراغات: تُزال المسافات والأسطر أثناء فك الترميز

🧭 نصائح الاستخدام

استخدم UTF‑8 لتجنّب الرموز غير المقروءة
الوضع الافتراضي URL‑safe؛ عطّلْه للحصول على Base64 القياسي
عند التبادل بين الأنظمة أزِل المسافات والأسطر؛ أضفها للعرض فقط
تزداد البيانات ~33% بعد Base64؛ غير مناسب للملفات الكبيرة
Base64 القياسي للأنظمة القديمة: عطّل URL‑safe (ابقِ +/ و =)
الترميز سطرًا بسطر يُعيد ترميز Base64 الموجود؛ لتحويل الصيغة فقط عطّله قبل الترميز
تقسيم 76 خانة يؤثر على العرض فقط؛ أداة الفك تتجاهل الفواصل والمسافات

⚠️ القيود والتوافقية

النصوص الطويلة جدًا قد تؤثر على الأداء؛ يُفضّل تقسيمها
الثنائيات: الواجهة مخصّصة للنص؛ للثنائيات استخدم Data URL أو سطر الأوامر
حدود الذاكرة في المتصفح تقيد الحجم الأقصى

🔒 الخصوصية والأمان

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

❓ أسئلة شائعة

ما هو Base64؟ ولماذا «الترميز»؟

Base64 هو مخطط لتمثيل البيانات الثنائية كأحرف نصية قابلة للطباعة. ظهر أولًا في معيار MIME للبريد (التسعينيات، RFC 1521/2045) ثم وحّدته RFC 4648. الغاية ليست «التشفير»، بل حمل البايتات بثبات عبر قنوات نصية. آلية العمل: كل 3 بايت (24 بت) تُقسَّم إلى أربعة مقاطع من 6 بت وتُسند إلى 64 حرفًا A–Z وa–z و0–9 و+ و/. عند عدم اكتمال الثلاثيات يُستخدم «=» للمحاذاة. الحجم يزداد بنحو 33%. البدائل والاختيار: تُعرّف RFC 4648 صيغة URL‑safe (باستبدال + و/ بــ - و_) مع إمكانية حذف «=» النهائية. يُفضَّل استخدامها في URL/Cookie/JWT؛ وللتكامل مع أدوات قديمة/MIME استخدم الصيغة القياسية (مع +/ و=). هذه الأداة تعتمد URL‑safe افتراضيًا؛ والمُفكِّك يقبل الصيغتين. أمثلة: ??? → القياسي Pz8/، وURL‑safe هو Pz8_؛ ~~~ → القياسي fn5+، وURL‑safe هو fn5‑. Data URL: عند التضمين استخدم data:[mime];base64,…؛ وعند الفك استخرج الجزء بعد الفاصلة (تقوم الأداة بذلك تلقائيًا). محطات (موجز): 1993 RFC 1521 (MIME v1، Ned Freed & Nathaniel Borenstein) ← 1996 RFC 2045 (تحديث MIME) ← 2003 RFC 3548 (Simon Josefsson، تجريد Base16/32/64) ← 2006 RFC 4648 (Simon Josefsson، توحيد وتعريف Base64URL، إهمال 3548). وأيضًا: 1993 RFC 1421 (PEM، J. Linn) استخدم Radix‑64 (قرين Base64) لحمل الثنائيات في البريد. ملاحظة أمنية: Base64 تنسيق قابل للعكس؛ لا يوفّر السرية/السلامة. شفّر أولًا ثم رمّز.

هل Base64 آمن؟

لا. أي شخص يمكنه فك الترميز. للسرية، شفّر أولًا ثم رمّز

لماذا يظهر “تنسيق Base64 غير صالح”؟

تحقّق أن السلسلة تحتوي فقط A–Z و a–z و 0–9 و + و / و = وأن طولها صحيح

لماذا تختلف النتائج بين الأدوات؟

الاختلافات غالبًا من معالجة فواصل الأسطر، والإبقاء على padding '='، ومتغير URL‑safe (−/_)، وتفاصيل التنفيذ. استخدم UTF‑8، عطّل فواصل الأسطر، وحدد مسبقًا استخدام URL‑safe والإبقاء على padding

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

Base64 يمثّل 8 بتات عبر 6؛ الزيادة (~33%) من طبيعة الطريقة

هل تدعم الرموز الخاصة/الإيموجي؟

نعم مع UTF‑8. البيانات غير النصية قد تبدو رموزًا غريبة بعد فك الترميز