كلمتان تظهران كثيرًا في أدوات المطورين: Base64 وURL Encoding. والخلط بينهما سهل لأن النتيجة في الحالتين قد تبدو كسلسلة غريبة من المحارف. لكن الاستخدام مختلف جذريًا: الأول طريقة لتمثيل بيانات ثنائية بنص، والثاني طريقة لتمثيل محارف داخل بنية URI/URL بصورة آمنة.
حوّل البايتات إلى نص
مفيد عندما تحتاج نقل بيانات ثنائية عبر قناة تتوقع نصًا، مثل تضمين بيانات صغيرة داخل بنية نصية أو بروتوكول يسمح بهذا التمثيل.
اجعل المحارف صالحة داخل جزء من الرابط
يستخدم لتمثيل بايتات ومحارف لا يمكن وضعها كما هي في موضع معين من URI، أو قد تحمل معنى خاصًا في ذلك الموضع.
ما الذي يفعله Base64 وURL Encoding؟
Base64 ليس تشفيرًا ولا حماية
RFC 4648 يعرّف Base64 ضمن مجموعة Base-N Encodings. الفكرة الأساسية أن البيانات الثنائية تُحوَّل إلى محارف من أبجدية محددة حتى يمكن تمثيلها كنص. لا توجد كلمة مرور، ولا سر، ولا مفتاح تشفير. أي شخص يملك السلسلة ويعرف أنها Base64 يستطيع فكها. [المصدر: IETF RFC 4648]
Hello
SGVsbG8=
التحويل السابق يغير طريقة التمثيل فقط. إذا فككت Base64 تحصل على البيانات الأصلية. لذلك وضع مفتاح API أو كلمة مرور في Base64 لا يجعلها سرية.
لماذا يزيد Base64 حجم البيانات؟
RFC 4648 يوضح أن Base64 يعمل على مجموعات من 24 بت، ثم يقسمها إلى أربع مجموعات من 6 بت، وكل مجموعة تمثل بمحرف من الأبجدية. عمليًا، كل 3 بايت من البيانات تتحول إلى 4 محارف Base64، مع padding عند الحاجة في نهاية السلسلة.
هذا يعني زيادة تقارب الثلث في الحجم قبل حساب أي تغليف إضافي. لذلك لا تستخدم Base64 لمجرد أن النتيجة “نص”. في ملف كبير أو صورة كبيرة قد تدفع تكلفة حجم بلا فائدة حقيقية.
وإذا وضعت السلسلة داخل JSON، فتذكر أن Base64 يغيّر تمثيل القيمة فقط؛ أما الأقواس والاقتباسات والفواصل فتبقى خاضعة لقواعد JSON. عند فشل التحليل راجع دليل أخطاء JSON الشائعة.
وماذا يفعل URL Encoding إذن؟
RFC 3986 يعرّف URI ويقسم المحارف إلى فئات، منها المحارف المحجوزة reserved والمحارف غير المحجوزة unreserved. صيغة percent-encoding تكتب البايت على شكل علامة % يتبعها رقمان سداسيان عشريان. [المصدر: IETF RFC 3986]
hello world
hello%20world
هنا لم نحول “ملفًا” إلى نص. نحن مثلنا المسافة بطريقة تصلح في موضع URL حيث وجودها الخام قد لا يكون مناسبًا.
ترميز الروابط عمليًا
لا ترمّز الرابط كاملًا بالطريقة نفسها
الرابط نفسه له بنية: scheme، host، path، query، fragment وغيرها. محرف مثل / له معنى بنيوي داخل المسار، و? يفصل query، و& قد يفصل معاملات داخل query.
إذا أخذت URL كاملًا وطبقت percent-encoding على كل شيء بلا فهم، قد تحول المحارف البنيوية نفسها إلى بيانات، فيتغير معنى الرابط. لهذا من الأفضل ترميز القيمة أو الجزء الذي يحتاج الترميز، لا العنوان كاملًا بطريقة عمياء.
WHATWG URL Standard يضيف قواعد عملية للويب الحديث
معيار WHATWG URL المستخدم كأساس لسلوك عناوين الويب الحديثة يعرّف مجموعات percent-encode مختلفة حسب السياق، مثل path وquery وfragment وuserinfo. وهذا مهم لأن المحرف الذي يحتاج ترميزًا في موضع قد لا يعامل بالطريقة نفسها في موضع آخر. [المصدر: WHATWG URL Standard]
النتيجة العملية: لا تحاول بناء نظام ترميز URL كامل يدويًا إذا كانت اللغة أو المنصة توفر API موثوقة للتعامل مع URLs ومكوناتها.
متى تستخدم كل طريقة؟
متى تستخدم Base64؟
مثل قيمة صغيرة تحتاج نقلها داخل تنسيق أو قناة نصية تسمح بBase64.
يمكن تضمين بيانات صغيرة داخل URL باستخدام مخطط data، وقد تستخدم Base64 حسب نوع البيانات. ليس هذا أفضل خيار لكل الملفات الكبيرة.
إذا كانت المواصفة تقول إن الحقل Base64، اتبعها. لا تختر Base64 بدلًا منهاج البيانات الذي يحدده البروتوكول.
ومتى تستخدم Percent-encoding؟
القيمة تحتاج تمثيلًا مناسبًا داخل query بدل وضعها خامًا في الرابط.
تعامل مع segment نفسه وفق API أو قواعد المنصة، لا مع الرابط كاملًا كسلسلة واحدة.
الترميز جزء من بناء الرابط الصحيح، لكنه ليس بديلًا عن التحقق من المدخلات أو اعتبارات الأمان.
Base64URL: قريب من Base64 لكنه ليس الشيء نفسه
RFC 4648 يحدد أيضًا أبجدية Base64 آمنة للأسماء والملفات وعناوين URL، تُعرف عادة بـBase64url. الفرق الأشهر أنها تستخدم - و_ بدل + و/ في المواضع المقابلة من الأبجدية.
وجود كلمة “URL” في الاسم لا يعني أن Base64url هو نفسه percent-encoding. Base64url ما زال Base64 بأبجدية مناسبة أكثر لسياقات معينة؛ أما percent-encoding فهو جزء من تمثيل محارف URI.
أمثلة وتركيبات شائعة
هل يمكن عمل URL Encoding ثم Base64؟
تقنيًا تستطيع تركيب تحويلات كثيرة فوق بعضها، لكن السؤال الصحيح هو: لماذا؟ إذا كانت المواصفة أو النظام يطلب تسلسلًا محددًا، طبقه بالترتيب المطلوب. أما تنفيذ encode فوق encode فقط لأن الناتج يبدو “أكثر أمانًا” فيخلق بيانات أكبر وتعقيدًا غير ضروري.
في التصحيح، هذه نقطة مهمة أيضًا. إذا استلمت سلسلة غريبة، لا تفترض أنها “مشفرة مرتين”. ابحث أولًا عن السياق: ما الذي كان متوقعًا في هذا الحقل؟ Base64؟ قيمة query؟ Base64url؟
مثال عملي: إرسال اسم ملف في query
لنفترض أن لديك قيمة مثل تقرير شهر 9.pdf وتريد وضعها كقيمة لمعامل في URL. هذه حالة بناء URL، وليست حالة Base64 بطبيعتها. استخدم أداة بناء URL أو API ترميز مناسبة لقيمة query.
تحويل الاسم إلى Base64 قد ينتج سلسلة قابلة للنقل، لكنه يغير شكل البيانات ويضيف خطوة فك لا يحتاجها الطرف الآخر إلا إذا كان البروتوكول مصممًا أصلًا على ذلك.
مثال آخر: صورة صغيرة داخل حقل نصي
هنا قد يكون Base64 منطقيًا إذا كانت الواجهة أو الصيغة تطلب تمثيل الملف داخل نص. لكن لا تحول صورة كبيرة إلى Base64 ثم تضعها في query parameter وتعتبر ذلك حلًا عامًا؛ الحجم يزيد والرابط قد يصبح غير عملي.
| الموقف | الأداة الأقرب | السبب |
|---|---|---|
| تمثيل ملف ثنائي داخل حقل نصي | Base64 عند طلبه | تحويل البايتات إلى أبجدية نصية. |
| قيمة بحث داخل URL | Percent-encoding / URL API | الحفاظ على بنية الرابط وتمثيل القيمة بأمان. |
| Token يستخدم Base64url حسب مواصفته | Base64url | أبجدية مناسبة لهذا السياق. |
| إخفاء كلمة مرور | لا هذا ولا ذاك | الترميز ليس تشفيرًا. |
| ضغط البيانات | لا هذا ولا ذاك | Base64 يزيد الحجم عادة، وURL encoding ليس ضغطًا. |
أخطاء شائعة مع النصوص
خطأ شائع: فك القيمة بعدد مرات غير معروف
في بعض المشاريع ترى شيئًا مثل “إذا فشل فك URL جرّبه مرة ثانية”. هذا مؤشر على أن مسار البيانات غير واضح. Double encoding يحدث أحيانًا عندما تطبق طبقتان الترميز على القيمة نفسها، ثم يضطر الطرف الآخر لفكها مرتين.
الأفضل أن تعرف عند أي حدود في النظام يحدث الترميز والفك، وأن تترك كل طبقة مسؤولة عن عملية واحدة مفهومة.
قرار سريع
- عندي بايتات وأحتاج تمثيلًا نصيًا؟ فكّر في Base64 إذا كان السياق يطلبه.
- عندي نص سيدخل في جزء من URL؟ استخدم URL API أو percent-encoding المناسب لذلك الجزء.
- أحتاج إخفاء سر؟ لا تستخدم أيًا منهما كحماية.
- أحتاج أصغر حجم ممكن؟ Base64 ليس أداة ضغط.
- رأيت Base64url؟ لا تساويه تلقائيًا مع URL encoding.
ماذا عن النص العربي؟
Base64 يعمل على البايتات، لذلك يجب أن تعرف كيف حُوّل النص إلى بايتات قبل Base64، وغالبًا يكون UTF-8 في تطبيقات الويب الحديثة. عند الفك تحتاج تفسير البايتات بالترميز نفسه حتى تستعيد النص صحيحًا.
وفي URL، النص العربي يمكن تمثيله ضمن البنية الحديثة وفق قواعد parsing وpercent-encoding التي تحددها المواصفات. لا تحتاج تحويل العربية إلى Base64 فقط لأنها ليست ASCII.
جرّب التحويل مع رؤية النتيجة مباشرة
في أدوات المطورين على تولاتي يمكنك استخدام Base64 وأدوات ترميز URL بصورة منفصلة. هذا يساعدك على رؤية الفرق بدل التعامل مع المصطلحين كأنهما عملية واحدة.
المصادر الرسمية المستخدمة
- IETF RFC 4648 — The Base16, Base32, and Base64 Data Encodings: المرجع الرسمي لـBase64 وBase64url وقواعد padding والأبجديات.
- IETF RFC 3986 — Uniform Resource Identifier (URI): Generic Syntax: المرجع الأساسي للمحارف المحجوزة وغير المحجوزة وpercent-encoding.
- WHATWG URL Standard: المعيار الحي لسلوك URL في الويب الحديث ومجموعات percent-encode حسب السياق.