مرمِّز base85: ثلاث صيغ جنبًا إلى جنب

ما هو base85؟

يحشر ترميز base85 البيانات الثنائية في نص قابل للطباعة مستعملًا 85 محرفًا مختلفًا. فكل أربعة بايتات تصير خمسة محارف، وهنا علة وجوده: إذ يحوّل base64 ثلاثة بايتات إلى أربعة، أي تضخّمًا بنسبة 33%، بينما يقف base85 عند 25%. هذا التوفير هو ما دفع PostScript وPDF إلى تبنّيه، ولهذا ما زال يظهر حيثما وجب على بيانات ثنائية أن تنجو من قناة نصية.

والمشكلة أن base85 ليس صيغة واحدة. فثلاثة أشياء على الأقل تحمل هذا الاسم، وليس فيها ما يقرأ ناتج الآخر. تستعمل Ascii85 المحارف الخمسة والثمانين ابتداءً من علامة التعجب، وهي ما ينتجه PostScript وPDF وبرنامج btoa الأصلي. أما Z85، التي يحددها معيار ZeroMQ، فتستعمل أبجدية مغايرة عن قصد، اختيرت ليكون الناتج آمنًا للّصق داخل الشيفرة المصدرية. وثمة صيغة ثالثة، وهي التي تعنيها معظم مكتبات البرمجة، تستعمل أبجدية RFC 1924.

ترمّز هذه الصفحة بايتاتك بالصيغ الثلاث معًا، حتى تُرى الفروق بدل أن تبقى نظرية، وهي تعمل في الاتجاه الآخر أيضًا: تعطيها نصًّا فتبيّن لك ماذا تظنه كل صيغة.

طريقة الاستخدام

1. أعطها بعض البايتات. بالنظام الست عشري أو كنص، أيهما أنسب. وتغطي الأمثلة متجه الاختبار الوارد في مواصفة ZeroMQ نفسها، وسلسلة من البايتات الصفرية، وبايتًا واحدًا، ولكل منها سلوك مختلف عبر الصيغ الثلاث.
2. قارن النواتج الثلاثة. تظهر معًا، مع تعريف موجز بكل صيغة. ولـ Ascii85 خياران يستحقان التجربة: محدِّدات Adobe، والاختصار الذي يكتب أربعة بايتات صفرية بحرف z واحد.
3. أو انتقل إلى قراءة نص. الصق نص base85، فتفكّه كل صيغة قادرة على ذلك، مع البايتات التي تنتجها كل واحدة. وحين تختلف صيغتان، فالنص نفسه لا يدلك على المصيبة منهما.

لماذا يخطر الخلط بين الصيغ

لا يحمل نص base85 أي علامة تدل على الصيغة التي أنتجته. فإن سلّمته إلى الفاكّ الخطأ حدث أحد أمرين: إما أن يرفضه، وإما أن يقبله ويعيد إليك بايتات أخرى دون أن يشتكي البتة.

وبالقياس على خمسة آلاف مدخل عشوائي، فإن فكّ ناتج Ascii85 بأبجدية RFC 1924 يعيد بايتات خاطئة بلا خطأ في نحو 16% من الحالات، ويخفق في الباقي. والاتجاه المعاكس يتصرف على النحو نفسه بنسبة 16.6%. أي أنك مرة من كل ستٍّ تقريبًا تحصل على فوضى معقولة المظهر بدل تحذير يخبرك أن شيئًا قد اختل.

وهذا عكس ما وجده هذا الموقع تمامًا في base58، حيث تحوي الأبجديتان المتنافستان المحارف الثمانية والخمسين نفسها بترتيب مختلف. فهناك يفكّ الخلط دائمًا في صمت، لأن كل محرف صالح في إحدى الأبجديتين صالح في الأخرى. أما صيغ base85 فتستعمل مجموعات محارف مختلفة فعلًا، فيولّد الخلط خطأً في أغلب الأحيان. وتلك الخمس مرات من كل ست التي يخفق فيها بصوت مسموع هي الصيغة تحميك؛ والمرة الباقية هي سبب وجوب تدوين الصيغة في موضع غير النص ذاته.

وZ85 أشد الثلاث صرامةً وأقلها احتمالًا لقبول ما لا ينبغي. إذ تشترط مواصفتها أن يكون الطول الثنائي قابلًا للقسمة على أربعة والنصّي على خمسة، ولا تعرّف أي حشو، بل تترك ذلك للمستدعي. فهي ترفض ببساطة مدخلات كانت الصيغتان الأخريان ستحشوانها، ولهذا يُرمَّز أحد الأمثلة هنا بـ Ascii85 وبأبجدية RFC 1924 وترده Z85.

الصيغة التي ليست ما يقوله اسمها

تُسمّى الصيغة الثالثة عادةً base85 الخاصة بـ RFC 1924، والاسم مضلِّل. فوثيقة RFC 1924 تتناول عناوين IPv6. ويقول قسم الترميز فيها إن العنوان يُعامَل بوصفه عددًا صحيحًا واحدًا من 128 بتًا، ثم يُكتب ذلك العدد بالأساس 85 ويُمثَّل بخمسة وثمانين محرفًا من ASCII، فينتج عشرون رقمًا بالضبط. وهي لا تصف أي طريقة لترميز تدفق من البايتات، ولا يرد في الوثيقة كلها ذكر لمعالجة أربعة بايتات دفعةً واحدة.

أما ما تنفّذه المكتبات تحت ذلك الاسم فهو أبجدية الوثيقة مضافًا إليها تجميع Ascii85 رباعي البايتات. وهذا أمر معقول تمامًا أن يُبنى، وليس ما تنص عليه الوثيقة. ويطبّق الوضع الثالث في هذه الصفحة خوارزمية الوثيقة الحقيقية، فيمكنك ترميز عنوان فعلي والحصول على الأرقام العشرين التي تصفها.

وتستحق الوثيقة القراءة لذاتها. فهي مؤرخة في الأول من أبريل 1996، ومصنَّفة إعلامية، وتصرّح في سطورها الأولى بأنها لا تحدد أي معيار للإنترنت. ويستعرض قسمها عن سبب اختيار 85 الأساسَين 84 و94 قبل أن يحسم، ويوضح أن مجموعة المحارف اختيرت بعناية بالغة لتبقى علامات الترقيم متاحة لتحديد العناوين. واستخلص من التاريخ ما تشاء.

ما لا تستطيع هذه الأداة إخبارك به

لا تستطيع أن تخبرك بالصيغة التي أنتجت نصًّا وصلك من غيرك. وتلك هي المشكلة بعينها: فليس في الترميز ما يسجّل ذلك. وإن فُكَّ النص نظيفًا بصيغتين، عُرضت الإجابتان وكان الاختيار لك، مسترشدًا بمصدر النص لا بشيء في داخله.

والصيغ الثلاث هنا هي الشائعة الاستعمال، لا كل ما هو موجود. ولـ Ascii85 خاصةً لهجات: فقد كان لبرنامج btoa اختصار لأربع مسافات إلى جانب اختصار البايتات الصفرية، وبعض الأدوات تقطع الناتج عند عمود ثابت وبعضها لا يفعل. وهذه تنويعات داخل Ascii85 لا صيغ منفصلة، لكنها تكفي لأن يختلف تطبيقان على النص الدقيق.

كما أن base85 لا يناسب المواضع التي يجب أن ينجو فيها الناتج من رابط أو اسم ملف أو أمر صدفة. فكل الصيغ تستعمل علامات الترقيم بسخاء، والمحارف تختلف من واحدة إلى أخرى، فقد يحتاج نص آمن في سياق إلى هروب في سياق آخر. وهذه هي المشكلة التي جاءت Z85 لحلّها، ولهذا تستبعد أبجديتها علامتَي الاقتباس والشرطة المائلة العكسية التي كانت ستحتاج إلى هروب داخل سلسلة في الشيفرة.

لماذا هي مجانية؟

تحويل الأساس عمليةٌ حسابية، وهي تجري داخل متصفحك. لا خادم في المسار، فلا شيء يستوجب فاتورة ولا حساب يلزم إنشاؤه.

لا يُرفع أي شيء. فالبايتات التي تلصقها لا تغادر التبويب.