الخلاصة

  • وزعت RFC 1556 مسؤولية عرض النص ثنائي الاتجاه على ثلاثة نماذج: يرتب برنامج التأليف النص المرئي مسبقاً، أو تستنتج خوارزمية القارئ الترتيب الضمني، أو توجه أوامر مضمنة في النص الترتيب الصريح.
  • أثبت MIME إمكان نقل المحارف غير ASCII، لكنه لم يجعل تطابق المحارف دليلاً كافياً على تطابق ما يراه القارئ؛ يلزم حفظ نمط الاتجاه وسياق العارض إلى جانب الحمولة.
  • كانت الوثيقة Informational في ديسمبر 1993 ولم تكن Internet Standard. وتوضح مواصفات HTML وUnicode والبريد ذي UTF-8 اللاحقة استمرار الحد الفاصل، لا نسباً تقنياً مباشراً ولا انتشاراً لوسوم RFC 1556.

قد ينجح البريد ويفشل السطر

لنفترض أن نظام أرشيف يعرض إيصالاً مقنعاً: بصمة الملف قبل النقل وبعده واحدة، وفك Base64 أو Quoted-Printable أعاد كل قيمة إلى محرفها الصحيح. يفتح القارئ رسالة تمزج العبرية باسم لاتيني ورقم وتاريخ. لا توجد علامة تلف.

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

نشر Hank Nussbacher وثيقة RFC 1556، Handling of Bi-directional Texts in MIME، في ديسمبر 1993. يصنفها سجل RFC Editor وسجل IETF على أنها Informational، وتنص بنفسها على أنها لا تحدد معيار إنترنت.

اقترحت الوثيقة طريقة لوصف direction في نصوص MIME ثنائية الاتجاه. وكان وراء الاسم الصغير سؤال تشغيلي: هل وصلت البيانات بعد أن رتبها المؤلف للعرض، أم ينتظر من القارئ أن يستنتج الترتيب، أم تحمل البيانات أوامر يجب تنفيذها؟

ما ضمنه MIME وما تركه للعارض

أتاحت RFC 1521 وصف أجسام رسائل تتجاوز ASCII المسطح. يعلن الجزء نوع المحتوى وcharset، ثم يحمي transfer encoding قيمه أثناء المرور ببنية بريد قديمة. ويثبت سجل RFC 1521 هوية تلك الخطوة التاريخية.

ونقلت RFC 1522 الفكرة إلى مواضع محددة من الترويسة. يحول برنامج التأليف النص غير ASCII إلى encoded-word؛ ويتعرف القارئ الداعم عليه ويفك ترميزه ويعرض المحارف في المجموعة المسماة. أما صفحة معلومات RFC 1522 فتضعه في عقد ترويسات MIME.

تصف charset العلاقة بين القيم والمحارف، ويحمي transfer encoding هذه القيم في الطريق. لكن السطر الذي يجمع العربية أو العبرية باتجاهها الطبيعي من اليمين إلى اليسار مع الإنجليزية والأرقام لا يستخرج ترتيبه المرئي من أسماء المحارف وحدها. يمكن أن يكون فك الترميز كاملاً، ويبقى العرض ناقص العقد.

لهذا لم تكن RFC 1556 اعتراضاً على نجاح MIME. كانت تحديداً للمكان الذي يتوقف عنده ذلك النجاح.

سجل عبري مجاور كشف هشاشة السياق

قدمت RFC 1555، التي ألفها Nussbacher وYehavi Bourvine في الشهر نفسه، طريقة البريد العبري باستخدام MIME وISO-8859-8. ويسجلها RFC Editor أيضاً كوثيقة Informational.

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

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

وأشارت RFC 1555 إلى أن بعض إعدادات Listserv تختصر الترويسات عند التوزيع، وأن الأرشيفات قد تسقط ترويسات MIME كلها. تبقى المادة المشفرة، لكن مفتاح تفسيرها يختفي. هذه صورة مبكرة لفقدان السياق مع بقاء الحمولة.

حتى توقع البريد الشفاف بثمانية بتات لم يلغ المشكلة. قد تقل الحاجة إلى Base64 وQuoted-Printable، غير أن Content-Type والاتجاه سيبقيان ضروريين. توسيع الأنبوب لا يقرر اتجاه القراءة.

في الوضع المرئي، وقع القرار قبل الإرسال

جعلت RFC 1556 الوضع visual هو الافتراضي، من دون لاحقة جديدة لاسم ISO-8859. يعمل العارض باتجاه أساسي واحد من اليسار إلى اليمين ويعامل المادة كنص أحادي الاتجاه. على برنامج التأليف أن يخزن المحارف في الصف الذي يجب أن يظهر؛ لا توجد أوامر اتجاه ولا خوارزمية تعيد ترتيبها عند العرض.

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

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

إذن مالك القرار في visual هو composer، وعقد viewer أن يظل غير واع بالاتجاه.

في الوضع الضمني، أصبح السياق مدخلاً تنفيذياً

اقترحت RFC 1556 الاسمين ISO-8859-6-i وISO-8859-8-i للوضع implicit. تستنتج خوارزمية العرض الاتجاه من نوع المحارف ومواقعها بالنسبة إلى الجيران ومن الاتجاه الأساسي. ولأن التفاصيل معقدة أحالت الوثيقة المنفذ إلى ECMA TR/53.

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

الخوارزمية المشتركة تمنح قابلية تشغيل بيني أفضل، لكنها تضيف نتيجة يجب قياسها. إذا اختلف إصدار القواعد أو اتجاه الفقرة أو حدود markup أو موضع الالتفاف، يستطيع عارضان متطابقان في الحمولة أن ينتجا سطرين مختلفين.

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

في الوضع الصريح، حملت البيانات أوامر غير مرئية

خصصت الوثيقة ISO-8859-6-e وISO-8859-8-e للوضع explicit. تتخلل النص control sequences تعلن الاتجاه المطلوب. يستطيع المرسل أن يبدأ سياقاً أو يغيره بدلاً من الاعتماد كلياً على استنتاج العارض.

لكن الأمر غير المرئي يحتاج إلى حفظ وفهم. قد يحذفه منقح لأنه لا يرسم glyph، أو يحتفظ به محول كقيمة لا يعرفها القارئ، أو يمتد تأثيره بسبب نطاق لم يغلق كما ينبغي. بقاء جميع الحروف الظاهرة لا يثبت بقاء التعليمات التي ترتبها.

ذكرت RFC 1556 أن ECMA TR/53 عرف ثلاث وظائف تحكم جديدة وعدل 22 وظيفة قائمة في ECMA-48. يبين العدد أن الأمر لم يكن علامة RTL منفردة؛ فالاتجاه يغير حركة الموضع النشط والعلاقة بين مخزن البيانات وصفحة العرض.

في explicit يملك المرسل اختيار الأوامر، ويملك العارض تفسير حالتها. الخطأ في أي نصف يبقي الملف قابلاً للنقل ويجعل السطر غير موثوق.

نموذج ECMA لم يساو بين موضع البيانات وموضع الصورة

وصف ECMA جهازاً يستقبل graphic characters وcontrol functions وينتج صورة يقرأها إنسان وفق تقاليد الكتابة. فصل النموذج data component عن presentation component، وجعل لكل منهما موضعاً نشطاً يمكن أن يتحرك وفق قواعد مختلفة.

هنا يظهر الفرق بين الخط والترتيب. الخط يرسم شكلاً لمحرف. أما نموذج العرض فيقرر إلى جوار أي شكل يقع، وكيف يتحرك المؤشر، وأين يعمل backspace أو carriage return، وكيف يصبح تسلسل مخزن سطراً بصرياً.

ضغطت RFC 1556 هذا النموذج داخل تصريح MIME. كان على المستقبل أن يعرف هل وصل إليه صف مرئي جاهز، أم تسلسل ينتظر خوارزمية ضمنية، أم تيار يحوي أوامر صريحة. إذا فقد هذا الاختيار، دخلت بيانات صحيحة إلى آلة عرض خاطئة.

لا يلزم فقد حرف واحد كي يقع الفشل

يفشل السياق أولاً عندما يحول وسيط ISO-8859-8-i إلى ISO-8859-8 أو يحذف Content-Type. تحتفظ الرسالة بالمحارف وتفقد وصف الآلة التي ينبغي أن تقرأها.

ويفشل الترتيب مرتين عندما يعد composer صفاً visual ثم يفترض renderer أنه logical ويطبق implicit. القرار الصحيح محلياً يصبح نتيجة خاطئة عند جمعه بقرار سابق غير مرئي.

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

ويفشل السياق بين عارضين عندما يختلف base direction أو كسر السطر أو حدود markup أو إصدار الخوارزمية. يكون decoded sequence واحداً، وvisual sequence مختلفاً.

لا تقتصر العاقبة على الجمال. قد تنتقل علامة ترقيم إلى جهة رقم، أو يبدو معرف في ترتيب ويُنسخ بترتيب آخر، أو يلتصق رمز بعبارة غير المقصودة. النص المختلط يختبر ما إذا كان النظام يحفظ العلاقات، لا قائمة المحارف فقط.

تغيرت الأدوات اللاحقة ولم يختف الحد

أدخلت RFC 2070 عام 1997 دعماً دولياً في HTML، ومنه الخاصية DIR وعنصر التجاوز BDO. تثبت صفحة معلوماتها أنها وثيقة Web مستقلة؛ لا تثبت أن HTML ورث آلية RFC 1556 مباشرة.

تحدثت نسخة مبكرة من Unicode Bidirectional Algorithm عن تخزين Unicode بترتيب logical، وعن محارف تنسيق تؤثر في العرض لا في تفسير بقية النص. أما UAX #9 الحالية فقد تطورت وتحدد أيضاً كيف تستطيع higher-level protocols تعيين سياق الفقرة أو فرض اتجاه.

وفي 2012 سمحت RFC 6532 باستخدام UTF-8 مباشرة في قيم ترويسات البريد ضمن بيئة end-to-end داعمة، وفق سجلها. قللت هذه الخطوة طبقة ترميز، لكنها لم تجعل ترتيب الذاكرة هو ترتيب الشاشة.

هذه شواهد على بقاء الفصل بين repertoire والنقل والعرض. ليست سلسلة نسب، ولا دليلاً على أن لاحقتي -i و-e انتشرتا أو أصبحتا Unicode أو HTML أو SMTPUTF8.

ثلاث إيصالات بدلاً من لقطة واحدة

إيصال النقل يحتفظ بالـoctets الأصلية وبصمتها وtransfer encoding وتسلسل code points بعد الفك. وهو يجيب عما إذا تغيرت المادة في الطريق.

إيصال التفسير يحتفظ بـContent-Type وcharset ونمط الاتجاه والأوامر الصريحة واتجاه الفقرة وmarkup وstyle وإصدار renderer والخوارزمية. وهو يجيب عن القواعد التي ظن الطرف المستقبل أنها سارية.

إيصال العرض يسجل تقسيم الأسطر وresolved visual order ولقطة الشاشة ونتيجة النسخ واللصق أو round trip. وهو يجيب عما ظهر فعلاً في حالة محددة.

لا تكفي لقطة بلا مدخل، ولا بصمة بلا مخرج. ينبغي أن تجمع fixtures بين العربية أو العبرية واللاتينية والأرقام وعلامات الترقيم والمحارف المحايدة والسياقات المتداخلة وأحجام النوافذ. وعند تغيير العارض يجب حفظ النتيجتين حتى يفسر الفرق، لا إعادة كتابة الأرشيف بصمت.

الوثيقة المنشورة لم تكن واقعاً تشغيلياً

تقدم Running-Code Primacy لدى Heng Lu اختباراً معاصراً: الوثيقة أداة تنسيق، ولا تصبح وصفاً للواقع إلا عبر التنفيذ والتشغيل والاستخدام. نشر RFC 1556 يثبت وجود الاقتراح في السجل، لا أن برامج البريد طبقته.

وتسأل Minimum Initial Specification وLocalized Future Decision وVoluntary Adoption عن القاعدة المشتركة الدنيا القابلة للتحقق محلياً. يوضح هذا التاريخ أن تطابق المحارف وحده ليس invariant كافياً لنص ثنائي الاتجاه؛ يجب أن يدخل النمط والسياق وإجراء العرض في الإثبات.

أما منظور Reality Layers فيمنع إيصال التمثيل من الادعاء بأنه إيصال عرض. هذه مفاهيم لاحقة، لا وصف لنوايا Nussbacher أو ECMA، لكنها تضبط ما نستطيع استنتاجه الآن.

السؤال الأخير: من كان قد رتب النص بالفعل؟

في visual كان composer قد اتخذ القرار. في implicit ينتظر القرار خوارزمية renderer. وفي explicit أرسل الكاتب أوامر وعلى القارئ تنفيذها. النظام الذي لا يعرف أي حالة استلمها قد يطبق قاعدته بأمانة ويخطئ في معنى الرسالة.

ليست قصة RFC 1556 أن MIME عجز عن حمل العربية أو العبرية. لقد نجح MIME في الرحلة، وكشفت الوثيقة أن الرحلة لا تصدر شهادة قراءة.

تطابق التسلسل يثبت سلامة الوصول. وبقاء النمط والأوامر يثبت حفظ سياق التفسير. واختبار عارض مسمى يثبت نتيجة بصرية واحدة. حين تجتمع الإيصالات الثلاثة فقط يصبح قولنا «وصلت الرسالة كما ينبغي» أوسع من قولنا «وصلت البايتات».

المصادر