الخلاصة

  • فصل RFC 2070 ترميز البايتات الخارجي لمورد HTML ملموس عن طقم محارف المستند المجرد والثابت في UCS؛ وكانت قيمة charset في HTTP أو MIME تسمي خريطة فك الترميز.
  • كانت مراجع المحارف الرقمية تُحل داخل طقم المستند الثابت، ولذلك بقيت هوية الحرف واحدة مهما اختلف الترميز الخارجي الذي حمل الوسوم.
  • نجاح فك الترميز ليس إلا إيصالاً لمرحلة واحدة؛ أما تحليل SGML، ومعالجة اللغة والاتجاهين، وتوافر الخطوط، وإخراج الأشكال، وفهم القارئ فظلت حالات لاحقة ذات مسؤوليات مختلفة.

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

هذا هو الحد الحاسم في RFC 2070. البايتات من خصائص المورد الملموس، أما الرقم فمن خصائص المستند المجرد. ولو اختلط المستويان لاستطاع الخادم تغيير معنى المرجع بمجرد تبديل ترميز النقل. ثبّتت الوثيقة الوجهة، وحصرت التغير عند باب فك الترميز.

احتاج SGML إلى عالم من المحارف قبل أن يحلل البنية

كان HTML آنذاك تطبيقاً من تطبيقات SGML. ولم يكن طقم محارف مستند SGML قائمة بالبايتات المسموح بها في ملف واحد، بل ذخيرة محارف وأرقاماً يتعرف بها نوع المستند وحالاته إلى تلك المحارف. فُسرت DTD والوسوم وبيانات النص في فضاء رقمي واحد.

ضم أساس HTML 2.0 في RFC 1866 محارف Latin-1، وحاذى مواقعها مع ISO 10646، وأشار إلى ذخيرة أوسع مستقبلاً. وأكمل RFC 2070 الانتقال في ملف تدويل HTML 2.x باختيار Universal Character Set في ISO 10646:1993 مع تعديلاته. وعند صدوره، وصفه RFC بأنه مطابق موضعاً بموضع لـ Unicode 1.1.

لكن اتساع الذخيرة لم يجعل كل عدد صالحاً. فقد ترك إعلان SGML المواقع من 128 إلى 159 غير مستخدمة، ولذلك بقي ’ غير قانوني في ذلك النموذج حتى لو منحه برنامج لاحق مظهراً طباعياً. وعبارة «صفحة Unicode» قد تخفي ادعاءين: المحارف المجردة التي يستطيع HTML تسميتها، والترميز الخارجي الذي يسلسلها به مورد بعينه. ثبّت RFC الأول من دون أن يفرض تمثيلاً وحيداً للثاني.

اختار charset طريق الدخول ولم يغيّر المقصد

جاء الترميز الخارجي من سياق النقل أو التخزين. ففي HTTP كانت قيمة charset ضمن Content-Type في الاستجابة تحدد الترميز، وفي البريد أدت قيمة MIME المهمة نفسها مع قواعدها الافتراضية. وسجل RFC أنه لم تكن هناك آنذاك إشارة معيارية مماثلة في FTP أو أنظمة الملفات الموزعة.

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

رتب النموذج المرجعي المراحل هكذا: مورد ← مفكك ترميز ← مدير كيانات ← محلل SGML ← تطبيق ← عرض. يحول المفكك التمثيل الخارجي إلى طقم المستند، ثم تتعامل المراحل اللاحقة مع المحارف، وقد يحولها العرض مرة أخرى إلى تمثيل الجهاز. لم يكن ضرورياً أن يحتوي المتصفح وحدات تحمل هذه الأسماء حرفياً؛ المطلوب أن يحافظ سلوكه المرصود على الحد. كان الرسم عقداً للسلوك، لا جرداً لمكونات متصفحات 1997.

استقر المرجع الرقمي لأنه يأتي بعد فك الترميز

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

الترتيب جوهري. على المستقبل أولاً أن يحول البايتات بطريقة صحيحة إلى محارف الوسم & و# والأرقام و;. بعد ذلك فقط يستطيع SGML التعرف إلى المرجع وحل رقمه. لا يصلح المرجع تدفقاً فُك ترميزه خطأ؛ بل يستقر بعد عبور الحد عبوراً صحيحاً.

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

كان لإشارة الترميز ترتيب في قوة الدليل

سجل RFC 2070 قيود النشر في 1997: كثيراً ما أغفلت الخوادم charset مناسبة، وأخطأت بعض المتصفحات في معالجة Content-Type يتضمنها. هذه ملاحظة تاريخية وليست إحصاءً لحصة المتصفحات اليوم.

أعطى الترتيب الأول لـ charset القادمة من مصدر المستند، ثم لإعلان META HTTP-EQUIV مبكر، وأخيراً لخاصية CHARSET الإرشادية في الرابط. وواجه META مشكلة بدء: لا يمكن للمحلل العثور عليه إلا إذا فُكت البايتات السابقة بما يكفي. لذلك وصف RFC الأسلوب بأنه غير مضمون، وقيد فائدته بالترميزات التي تكشف القيم المقابلة لـ ASCII على نحو مناسب في البداية.

فصل الترتيب السلطة عن سهولة الوصول. قد تظهر إشارة قريبة أولاً، لكنها لا تكتسب سلطة بيانات الاستجابة. وفي المقابل تظل العلامة ذات السلطة ادعاءً؛ فهي لا تثبت تشفيرياً أن الجسم يطابق الخريطة، ولا أن المفكك طبقها بأمانة.

قد يصل المحرف صحيحاً ثم يفشل على الشاشة

وسّع UCS ما يستطيع HTML تعريفه، لكنه لم يصنع خطوطاً. توقع RFC محارف يمكن للنظام تحليلها ولا يملك عرضها، ولم يفرض سلوكاً بديلاً واحداً. صندوق المحرف المفقود أو رقمه الست عشري سياسة عرض لا هوية جديدة.

أضافت اللغة والاتجاه حالتين أخريين. قد تؤثر LANG في اختيار الشكل وعلامات الاقتباس والوصل والربط والمسافات والنطق. وقد تغيّر DIR وBDO وخوارزمية Unicode ثنائية الاتجاه الترتيب المرئي اللازم لقراءة المعنى. تعمل هذه الأدوات على محارف سبق تحديدها؛ ولا تعيد تعريف البايتات الخارجية.

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

بقي الحد بعد انتقال السلطة على HTML

حين انتقلت مواصفات HTML إلى W3C، جعل RFC 2854 كلّاً من RFC 2070 ووثائق IETF الأقدم متقادمة. هذه حقيقة في الحوكمة وتسلسل الوثائق، وليست دليلاً على زوال حد فك الترميز. ظل تسجيل text/html اللاحق يصف charset بأنه الترميز المستخدم لتمثيل مستند HTML في صورة بايتات، وأكد HTML 4.01 أن طقم محارف المستند وحده لا يكفي لتفسير تسلسل بايتات متبادل.

يوفر تمييز Lu Heng اللاحق بين الحد الأدنى للمواصفة الأولية، والقرارات المستقبلية المحلية، والتبني الطوعي عدسة مفيدة للرجوع. فضاء الأرقام الثابت كان ثابتاً مشتركاً صغيراً، بينما بقي دعم المفككات ومعالجة الأخطاء والخطوط والعرض قرارات تنفيذ محلية. نشر القاعدة لا ينفذ تلك القرارات.

الدرس الباقي هو أن وصول المورد لا يجعله مستنداً بمجرد وصول بايتاته، وأن حل رقم المحرف لا يجعله شكلاً مرئياً. لكل انتقال دليله، ولا توسع أي طبقة نطاق سلطتها باستعارة إيصال الطبقة التي قبلها.

المصادر