الخلاصة

  • وثّق RFC 1468 ملفاً تعريفياً ضيقاً من سبعة بتات: يبدأ النص في ASCII، وتختار أربع سلاسل هروب حالة أحادية البايت أو ثنائية البايت، وعلى كل سطر يستخدم JIS X 0208 أن يغادر الحالة الثنائية قبل CRLF.
  • كان إعلان ISO-2022-JP في MIME يحدد قاعدة فك الترميز المقصودة، لا يثبت سلامة بنية المتن أو حفظ المرحّلات للهروب أو تطابق المحارف المستعادة أو الصورة التي رآها القارئ.

في هذا الترميز، لا يكفي أن تسأل: ما قيمة هذا البايت؟ لا بد أن تسأل أيضاً: ماذا حدث قبله؟

نُشر RFC 1468 في يونيو/حزيران 1993، موثقاً ترميزاً بدأ في JUNET وكان مستخدماً في مجتمعات IP يابانية. أبقى الرسالة ضمن سبعة بتات، لكنه وضع آلة حالات صغيرة داخل النص. سلاسل لا تطبع شيئاً كانت تغيّر طريقة قراءة كل ما يليها.

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

أربع إشارات تغيّر معنى ما بعدها

يبدأ النص في ASCII. تعيّن ESC $ B ‏JIS X 0208-1983، وتعيّن ESC $ @ إصدار 1978؛ وبعد كل منهما يمثل المحرف ببايتين. تعيد ESC ( B الحالة إلى ASCII، بينما تختار ESC ( J المجموعة الرومانية من JIS X 0201.

ليست هذه الإشارات وصفاً جانبياً للبايتات. إنها أوامر داخل التدفق. زوج صالح في حالة JIS X 0208 لا يبقى المحرف نفسه بعد الرجوع إلى ASCII. لذلك يحتاج مفكك الترميز إلى الاحتفاظ بآخر تعيين صحيح؛ فالموضع الحالي لا يحمل معناه كاملاً وحده.

حتى الحالتان أحاديتا البايت ليستا متطابقتين. تختلف JIS X 0201 Roman عن ASCII في موضعي الشرطة المائلة العكسية/الين وعلامة التلدة/الخط العلوي. قد تخفي الخطوط هذا الفرق محلياً، لكنه يبقى جزءاً من العقد. كما يستبعد الملف مجموعة Kana من JIS X 0201. وجود «JP» في الاسم لم يكن إذناً باستخدام كل تمثيل ياباني معروف لدى جهاز بعينه.

وتستبعد الصياغة الرسمية ESC وSI وSO من المحارف العادية. فالبايت الذي يتحكم في الحالة لا يجوز أن يتحول، بحسب المصلحة، إلى نص عادي. ضيق الآلة هو الذي جعل الاسم مفيداً.

نهاية السطر حدّ لنفوذ الحالة

إذا احتوى السطر محارف JIS X 0208، وجب التحول إلى ASCII أو JIS X 0201 Roman قبل CRLF. يبدأ السطر التالي في الحالة الأحادية المختارة قبل نهاية سابقه، وينتهي النص كله في ASCII.

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

ليس ذلك تزامناً ذاتياً كاملاً. فالعودة إلى JIS X 0201 Roman تبقي فرق موضعين عن ASCII، كما تختلف البرامج في معالجة الهروب الناقص. لكن الحالة الثنائية لا تعبر حد السطر في الخفاء. صار CRLF حداً للتفسير، لا مجرد تنسيق.

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

سبعة بتات حلت سعة الطريق لا معنى الرسالة

يعرض RFC الصيغة Content-Type: text/plain; charset=iso-2022-jp. ولأن التمثيل من سبعة بتات أصلاً، فلا يحتاج إلى ترميز نقل إضافي لمجرد عبور أنظمة البريد القديمة.

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

وحذر النص من أن Base64 أو quoted-printable سيجعلان الرسالة غير مقروءة في برمجيات JUNET الجارية آنذاك. هذه ملاحظة زمنية. التحويل القابل للعكس لا يمحو البايتات حتماً؛ إنما يفشل التشغيل إذا لم تعرف البرمجيات الفعلية إزالة طبقة النقل قبل تطبيق charset. إمكان الورق ليس دليلاً على اعتماد الكود.

لاحقاً وصف RFC 2046 معامل charset بأنه حاسم لنص MIME، وأبقى قيود الأسطر. يختار الاسم العقد الذي يفترض تطبيقه، لكنه لا يقدم إيصالاً بأن كل برنامج طبقه.

شاشة المرحّل لم تكن سلطة تحرير

لاحظ RFC 1468 أن بعض الأنظمة لا تميز في العرض بين ESC ( B وESC ( J، أو بين ESC $ @ وESC $ B. ومع ذلك منع المرحّل من تغيير سلاسل الهروب.

المساواة البصرية المحلية ليست هوية قابلة للنقل. قد يكشف خط آخر الين حيث أظهر الأول شرطة عكسية، وقد يعامل محول لاحق إصداري JIS X 0208 على نحو مختلف. عدم استفادة المرحّل من الفرق لا يمنحه حق محوه قبل وصول الرسالة إلى غيره.

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

الحفظ الدقيق لا يوثق هوية المرسل ولا يثبت صدق عبارته. إنه واجب أضيق: ألا يستبدل الوسيط تفسيره المحلي بكائن المرسل.

للخط الواحد ثلاثة مقاييس

نصح RFC المستخدمين بنحو 75 إلى 80 عمود عرض لإتاحة مساحة لعلامات الاقتباس. في نموذجه يشغل محرف JIS X 0208 بايتين وعمودين، بينما تشغل سلسلة الهروب بايتات ولا تشغل أعمدة. ولا ينبغي شطر المحرف الثنائي عند الالتفاف.

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

يثبت تجزؤ المتن هوية تمثيل، لا شكل الخط. وتثبت لقطة الشاشة ناتج عرض محدداً، لا البايتات التي ولدته. لا تكتمل المراجعة إلا بربط الدليلين من دون دمجهما.

التسجيل يثبت الاسم لا التنفيذ

عرّف RFC 2978 charset بأنه طريقة لتحويل سلسلة ثمانيات إلى محارف، وتشمل طرق التبديل المعقدة في ISO 2022. ويجب أن يحدد التعريف المرتبط بالاسم التحويل كاملاً، من دون ملف خارجي خفي.

يسجل سجل IANA لمجموعات المحارف ‏ISO-2022-JP بالرقم 39 مع الإحالة إلى RFC 1468 وRFC 2237، ويسجل ISO-2022-JP-2 منفصلاً. يحمي هذا القاموس المشترك من تصادم الأسماء؛ لكنه لا يفحص رسالة ولا يعتمد مكتبة ولا يقيس الاستخدام الحالي.

وتصف بيانات RFC Editor الوثيقة بأنها Informational، لا Internet Standard. لا يلغي ذلك الأهمية التشغيلية التي دفعت إلى تدوينها، ولا يجعل سجل IANA كل نسخة تحمل الاسم مطابقة. الحالة التحريرية واستقرار الاسم والواقع التشغيلي ثلاث حقائق.

اتساع الآلة حصل على اسم جديد

قدّم RFC 1554 في ديسمبر/كانون الأول 1993 الامتداد التجريبي متعدد اللغات ISO-2022-JP-2. أضاف تعيينات صينية وكورية ويابانية تكميلية ولاتينية ويونانية، وأضاف نطاق حالة ثانياً يعاد بعضه عند السطر. تغيرت الآلة فتغير الاسم.

وفي 1997 عرّف RFC 2237 ‏ISO-2022-JP-1 لإضافة JIS X 0212 بواسطة ESC $ ( D. أبقى نهاية ASCII، وطلب استخدام ISO-2022-JP العادي إن لم تظهر محارف المجموعة التكميلية.

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

حدود الدليل تسبق عين القارئ

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

توضح كتابات Heng Lu هذه الحدود. يبين Minimum Initial Specification كيف تترك النواة الصغيرة قرار التنفيذ محلياً. ويفصل Running-Code Primacy بين نشر المواصفة وتشغيلها. ويرفض On Reality Layers اختزال الاسم والتمثيل والعرض واستجابة الإنسان إلى واقعة واحدة.

لم يصل RFC 1468 إلى نتيجة القارئ ولم يدّع ذلك. أعطى الاسم قاعدة، وأعطت سلاسل الهروب حالة، وحد السطر نطاقها، وحفظ المرحّل الكائن، ونفذ الطرف التفسير. نجح البريد الياباني عبر شبكة لا تقرأ اليابانية لأن سلطة كل طبقة بقيت محدودة.