أدوات المطور · التشفير ووحدة فك التشفير Base64
تاريخ قصير لـ Base64: من uuencode و PEM إلى الأبجدية الحالية
· خلفية
base64 ترميز
أبجدية Base64 هي سجل أحفوري لمشاكل النقل في الثمانينيات. يتبع هذا المنشور السلالة من uuencode عبر البريد المعزز للخصوصية إلى MIME وRFC 4648، ويشرح كل خيار من اختيارات التصميم.
لماذا لا تكون الأبجدية 0–63 ببساطة بترتيب واضح - السؤال الذي يعود بأربعة عقود إلى الوراء
لم يظهر Base64 بشكل كامل كمعيار. الأبجدية (A-Z، a-z، 0-9، +، /) عبارة عن سجل أحفوري لعقود من تجارب التشفير، تحاول كل منها حل المشكلة نفسها: كيفية تمثيل البيانات الثنائية كنص لا يزال موجودًا في البريد الإلكتروني في السبعينيات والثمانينيات، وUSENET، وأدوات Unix. وتمتد القصة إلى uuencode على نظام Unix، البريد المعزز بالخصوصية (RFC 1421) في 1993، MIME (RFC 2045) في 1996، وأخيرًا RFC 4648 في 2006 دمج كافة المتغيرات.
يشرح فهم هذا التاريخ سبب وجود أحرف معينة في الأبجدية ولماذا ترك RFC اختيارات معينة للمنفذين. uuencode، وهو اختصار لتشفير Unix-to-Unix، كان أول أداة لحل مشكلة النقل 7 بت على Unix. تم إنشاؤه في 1980، وقام بتشفير كل 3 bytes (24 bits) إلى 4 أحرف من أبجدية مكونة من 64 أحرف. كانت أبجدية uuencode هي ASCII 32 (مسافة) إلى ASCII 95 (الشرطة السفلية وعلامات الترقيم الأخرى)، وتم اختيارها لأن هذه الأحرف قابلة للطباعة على أي محطة طرفية. يوضح المستودع الأبجدية المطبقة حاليًا، لكنه لا يحتوي على دليل أرشيفي حول من اختار هذا الترتيب أو سبب فوز كل شخصية. ولذلك تم تضييق العنوان: يمكن فحص التصميم الحالي بدقة، في حين تتطلب الدوافع والتواريخ وثائق تاريخية أولية غير مدرجة هنا.
لماذا تبدو الأبجدية تاريخية - وهي حدود لا يوثقها هذا المستودع
ومع ذلك، فإن المسافة كحرف ترميز تمثل مشكلة: حيث تقوم برامج تحرير النصوص وأنظمة البريد بقص المسافات الزائدة، مما يؤدي إلى إتلاف الإخراج. لم تكن الأبجدية مثالية، لكنها عملت بشكل جيد بما فيه الكفاية لنقل الملفات من يونكس إلى يونكس. كان البريد المحسّن للخصوصية (RFC 1421، 1992) محاولة مبكرة لتوحيد معايير البريد الإلكتروني المشفر. لقد تضمن ترميز Base64 الخاص به (RFC 1341، لـ MIME، والذي RFC 1421 سبقت المواصفات ولكنه تأخر في الاعتماد).
RFC 1421 استخدم Base64 الحروف الأبجدية A-Z، a-z، 0-9، +، / (أبجدية Base64 الحديثة)، وأسطر ملفوفة في 64 أحرف. تجنبت هذه الأبجدية المسافات والأحرف الإشكالية الأخرى؛ كل حرف قابل للطباعة بشكل لا لبس فيه ولا يتم الخلط بينه وبين رموز التحكم أو الاختلافات الوطنية في مجموعة الأحرف. يتوافق طول سطر الأحرف 64 مع عرض المحطات الورقية في الثمانينيات وكان بمثابة حل وسط عملي لسهولة القراءة. ينتمي Uuencode إلى التاريخ المحيط به، إلا أن الأداة لا تقرأ الحروف الأبجدية الخاصة بها ولا تكتبها. إن التعامل معه على أنه Base64 قابل للتبديل سيكون خطأ في التنسيق. تقتصر المقارنة المفيدة هنا على المشكلة المشتركة المتمثلة في تمثيل البايتات بأحرف قابلة للطباعة.
الترميزات السابقة كسياق، وليس دليل تنفيذ
RFC 1421 لم يتم اعتماده على نطاق واسع للبريد الإلكتروني المشفر، ولكن الأبجدية Base64 الخاصة به ظلت موجودة. MIME (امتدادات بريد الإنترنت متعددة الأغراض، RFC 2045، 1996) اعتمدت الأبجدية RFC 1421 Base64 الأبجدية ولكن تم تغيير التفاف السطر من 64 إلى 76 حرفًا. لم يكن السبب تقنيًا ولكنه تاريخي: كانت كتل PEM (البريد المعزز للخصوصية) عبارة عن 64 حرفًا، واختار MIME حدًا مختلفًا قليلاً لتجنب الخلط مع PEM في التحليل الآلي.
MIME أصبح Base64 هو المعيار لمرفقات البريد الإلكتروني وهو متغير Base64 الأكثر استخدامًا اليوم. RFC 2045 قام أيضًا بتعريف قيم أخرى لترميز نقل المحتوى (7bit، 8bit، قابلة للطباعة)، مما يوفر خيارات لأنظمة البريد بناءً على نوع المحتوى. يتجنب اختيار الحروف الأبجدية الأحرف التي تختلف بين ASCII وEBCDIC (ترميز أحرف الحاسب المركزي IBM). الأحرف A-Z، وa-z، و0-9، و+، و/ هي نفسها في كلا الترميزين. يمكن التعرف على الكتل ذات النمط PEM لأن التسميات تحيط بالمواد المشفرة المغلفة. يمكن لـ ToolAcre معالجة نص Base64 المستخرج بعد إزالة تلك التسميات. لا يمكنها تحديد المواصفات الأرشيفية التي استخدمت اصطلاحًا معينًا لأول مرة، ولا تتظاهر هذه المقالة بأن الشجرة المصدر تجيب على هذا السؤال.
PEM درع ذو نمط حديث يمكن ملاحظته، دون المطالبة بقصة الأصل
تختلف الأحرف مثل القوس المفتوح وقوس الإغلاق بين ASCII وEBCDIC، لذلك تم استبعادها. كان هذا مهمًا في الثمانينيات وأوائل التسعينيات عندما كان نقل البيانات من الحاسب المركزي إلى نظام Unix أمرًا شائعًا. تتجنب الأبجدية أيضًا الخطوط المائلة العكسية والاقتباس المفرد والاقتباس المزدوج، والتي لها معنى خاص في سلاسل C وبناء جملة الصدفة. يمكن تضمين سلسلة Base64 في برنامج C أو برنامج نصي shell دون الهروب من كل حرف تقريبًا.
RFC 3548 (2006) ترميزات Base64 وbase32 وbase16 المدمجة. لاحظت أن MIME وPEM والتطبيقات الأخرى جميعها تستخدم مفاهيم متشابهة ولكن مع قواعد تعبئة وأبجدية مختلفة. RFC 4648 (2006، المنشور بجانب RFC 3548) هو المعيار الحالي، وهو يحدد خمس عائلات ترميز مع متجهات اختبار لكل منها. يشير RFC أيضًا إلى السجل: ما هي المستندات التي تحدد الترميزات، وما الذي تغير بين الإصدارات، ولماذا تم إجراء الاختيارات. إن خيار التفاف الأحرف 76 الخاص ببرنامج التشفير وإزالة المسافات البيضاء في وحدة فك التشفير يجعل العينات ذات الشكل MIME قابلة للاختبار. لا تثبت حقائق التنفيذ هذه التاريخ الكامل لمعايير البريد. إنها تُظهر سلوك التوافق الحديث الذي يمكن للقراء إعادة إنتاجه مباشرةً في اللوحة والاختبارات.
MIME التفاف بنمط كخيار تشفير، دون إعادة بناء سجل المعايير
يواجه معظم المطورين base64 وbase64url فقط في RFC 4648؛ تم توثيق التاريخ لأولئك الذين يحتاجون إلى تنفيذ المتغيرات الأقدم. يستبدل Base64url (RFC 4648 القسم 5) علامة الجمع بشرطة وشرطة مائلة بشرطة سفلية لتجنب الأحرف المحجوزة URL. يجب أن تكون السلسلة base64 التي تحتوي على + و / مشفرة بنسبة مئوية في URL (%2B و %2F)؛ يتجنب base64url ذلك.
JWT (JSON رمز الويب) يستخدم base64url بدون الحشو. تستخدم بعض التطبيقات base64url مع الحشو. يحدد RFC كلا المتغيرين؛ الأمر متروك للتطبيق الذي تختاره. هذا التباين هو السبب في أن وحدة فك ترميز JWT ووحدة فك ترميز Base64 للبريد الإلكتروني قد تنتج مخرجات مختلفة لنفس سلسلة الإدخال (يتوقع أحدهما base64url، والآخر يتوقع base64). نشأت الأبجدية وقواعد الحشو والتفاف الأسطر من القيود العملية للأنظمة الحقيقية. من الأفضل التعامل مع إمكانية النقل كقيد على أبجديات النقل بدلاً من السيرة الذاتية لكل رمز. تظل الحروف والأرقام مألوفة بصريًا عبر أنظمة النص الشائعة، بينما تختلف علامات الترقيم النهائية في الوضع الآمن URL. تم حذف الأساس المنطقي للاختيار التاريخي الدقيق دون وجود دليل أولي.
إمكانية النقل كقيد تصميم، وليس حسابًا تم التحقق منه لاختيارات الأحرف الفردية
تم اختيار مجموعة الأحرف 64 لقابلية التمثيل عبر الترميزات؛ تم إصلاح الأبجدية بواسطة RFC 1341 و 1421 و MIME؛ جاءت قاعدة الحشو من محاذاة 3 بايت؛ وجاء التفاف الخط من حدود نقل البريد الإلكتروني. قد يخترع التطبيق الذي يتجاهل هذا السجل ترميزًا جديدًا أو ينسى حالة حافة. تعد متجهات الاختبار RFC 4648 (foobar ينتج Zm9vYmFy) هي الطريقة للتحقق من أن التنفيذ يحترم المعيار.
توجد بدائل حديثة مثل Base85 (المستخدمة في بعض السياقات)، لكن Base64 يظل مهيمنًا بسبب الزخم التاريخي ولأنه جيد بما فيه الكفاية. Base64 ليس التشفير الأكثر إحكاما (base85 وbase91 أكثر كثافة)، لكنه بسيط وعالمي ومثبت. ما يمكن ذكره بحزم هو زوج الحروف الهجائية الحالي: ينتهي المعيار بعلامة زائد وشرطة مائلة؛ URL- بدائل آمنة للواصلة والشرطة السفلية. الحشو والتغليف هما خياران منفصلان. تغطي الاختبارات كلا الوضعين والحشوة المفقودة، مما يوفر أدلة قابلة للتكرار للسلوك الحالي بدلاً من التسلسل الزمني المستنتج.
ما يثبته المستودع بشأن المعايير الحالية والحروف الهجائية الآمنة URL
يعتبر حجم الحمل الزائد بنسبة 33 مقبولاً لمعظم الاستخدامات. الأبجدية مستقرة عبر التطبيقات. إن RFC واضح بدرجة كافية بحيث تكون الانحرافات عادةً متعمدة (مثل حذف الحشو أو التعامل مع المسافات البيضاء) وليس سوء فهم غير مقصود.
يشرح فهم تاريخ Base64 سبب ظهوره بهذه الطريقة. كانت أحرف الزائد والشرطة المائلة اختيارات متعمدة لتجنب الغموض في ترميزات الأحرف المختلفة. جاءت قاعدة الحشو من مجموعة 3 بايت. يستخدم Base85 وAscii85 أحجامًا وأبجديات مختلفة للمجموعات وهما خارج نطاق التنفيذ. فذكرهم لا يجعل هذه الصفحة محولة لهم. ستتطلب مقارنة كثافتها أو تاريخها مصادر ومتجهات اختبار تتجاوز ملفات Base64 التي تمت مراجعتها لهذه الوحدة.
الوجبات الجاهزة: تم اختيار كل حرف لسبب ما - كيف يقوم برنامج التشفير ووحدة فك التشفير Base64 بتنفيذ الأبجدية القياسية التي نتجت عن ذلك
جاء التفاف الخط من البريد الإلكتروني. تم اتخاذ كل قرار لحل مشكلة حقيقية باستخدام أنظمة حقيقية. اليوم، يتم استخدام Base64 في الغالب في السياقات (JWT، واجهات برمجة التطبيقات، معرفات URI للبيانات) حيث لا يهم التاريخ، ولكن يتم توريث قواعد الأبجدية والحشو من MIME وPEM إلى RFC 4648.
إن قراءة RFC مرة واحدة وترميز سلسلة اختبار في أداة التشفير وفك التشفير Base64 يربط المعيار الحالي بجذوره التاريخية. تكون الأبجدية القياسية الناتجة مرئية عندما يصل الإدخال إلى مؤشرات اثنين وستين أو ثلاثة وستين. استخدم نموذجًا ينتج تلك المواضع، وقم بالتبديل إلى الوضع الآمن URL، وقارن فقط علامات الترقيم التي تم تغييرها. توضح هذه التجربة الشكل الحالي دون الاعتماد على قصة غير مدعومة حول اختراعها.