الخلاصة

  • ألزمت RFC 1922 كل سطر ISO-2022-CN يحتوي محارف صينية بأن يكرر تعيين مجموعة المحارف داخل السطر، وأن يعود عبر SI إلى ASCII قبل CRLF؛ فلم يعد السطر الحالي يرث حالة غير مرئية من سطر سابق.
  • أنشأت التعيينات وSI/SO والإزاحتان المؤقتتان SS2/SS3 نحو بايتين قواعد تفسير سباعية البت. صحة القواعد لا تثبت التسليم أو توافر الرسم أو هوية الكاتب أو فهم القارئ.
  • جعل معاملا charset-edition وcharset-extension اختلاف النسخ والإضافات الخاصة قابلاً للوصف. لكن الاسم لا يثبت وجود جدول التحويل عند الطرف الآخر ولا اعتماد البرمجيات للمواصفة.

نافذة التمرير لا تملك ذاكرة الرسالة كلها

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

صدرت RFC 1922 في مارس/آذار 1996 بوصفها وثيقة Informational، وجعلت حد السطر نقطة استعادة. يبدأ ISO-2022-CN في ASCII. إذا احتوى السطر صينية، أعاد السطر نفسه تعيين مجموعة المحارف المطلوبة. وقبل CRLF كان SI يعيد الحالة إلى ASCII. يبدأ السطر التالي من مرجع معروف.

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

التعيين يختار الجدول، والإزاحة تختار المدة

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

أما SS2 وSS3 فكانتا استعارة قصيرة. تسري كل واحدة على البايتين التاليين فقط—أي محرف صيني واحد—ثم تستأنف حالة SI/SO السابقة. إذا عامل المحلل تلك الاستعارة كتحول دائم، فسيفسد معنى بايتات صحيحة بعدها.

وسّع ISO-2022-CN-EXT المجموعات والمستويات المسجلة. واحتفظت القواعد بصيغ ذات محارف نهائية لم تكن ISO قد خصصتها بعد، لكنها حظرت استخدامها حتى يحدث التخصيص فعلاً. ترك مكان للمستقبل لا يمنح مورداً خاصاً حق وضع معنى عام فيه.

طبقة النقل لا تشهد للخط

بقي ISO-2022-CN وامتداده ضمن سبعة بتات، ولذلك لم يحتاجا عادة إلى Content-Transfer-Encoding لمجرد حماية البت الأعلى في مسار بريد قديم. لكن ذلك لم يحل مسائل وسم MIME، أو قانونية الحالة، أو دعم المستقبل للمجموعة.

كان CN-GB وCN-Big5 ثمانيي البت. عبر مسار سباعي البت كان يلزم Base64 أو Quoted-Printable؛ أما النقل الخام فاحتاج إلى تفاوض فعلي على 8BITMIME في SMTP. إذا قطع وكيل قديم البت الثامن، أمكن أن يعلن التسليم فيما يصل النص غير مقروء.

اسم charset يصرح بالتفسير المقصود، وترميز النقل يحمي التمثيل، و8BITMIME يثبت قدرة نقل محددة. لا واحد منها يصادق هوية المرسل، أو يضمن جدول المستقبل وخطه، أو يثبت الشكل الذي ظهر للإنسان.

سنة الإصدار تقيد الخطأ ولا تصنع اليقين

كانت لمعايير المحارف الصينية إصدارات مختلفة. يسجل charset-edition سنة الإصدار المطلوبة. يستطيع البرنامج الذي يفهمه اختيار الجدول المناسب؛ أما من لا يفهمه فيتجاهله وقد يعرض وفق إصدار أقدم مع عدد محدود من الأخطاء. السنة تساعد على التشخيص ولا تتحول إلى شهادة على الرسم.

يسمي charset-extension إضافات الموردين أو المجموعات المحلية، بقيم مسجلة أو أسماء خاصة تبدأ بـx-. يكشف الاسم أن الرسالة تعتمد على امتداد ما، لكنه لا يثبت ذلك الامتداد لدى المستقبل. وقد أقرت RFC بأن الامتدادات يمكن أن تضعف قابلية التشغيل البيني.

ظلت التحويلات بين Big5 وCNS 11643 مسؤولية الجداول والتنفيذ. يمكن لسلسلة قانونية أن تنتج رسماً مختلفاً بسبب إصدار أو خريطة أو خط. وقد توحي طريقة الترميز بتقليد شكلي، لكنها لا تثبت جنسية الكاتب أو مكانه أو سلطته.

خمسة وسبعون عموداً تحمي اقتباساً لم يحدث بعد

تستهلك سلاسل الهروب بايتات من دون أعمدة مرئية. ويستهلك المحرف الصيني عادة بايتين وعمودين. أوصت RFC بألا ينقسم البايتان بين سطرين، وبأن يبقى العرض قريباً من 75 عموداً كي يتسع السطر للرمز > الذي تضيفه الردود عند الاقتباس.

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

المصادر تصف آلية ولا تعدّ التركيبات

المصدر المركزي هو RFC 1922. وتقدم RFC 1468 وRFC 1557 سياق البريد الياباني والكوري سباعي البت. وتشرح RFC 1521 إطار MIME المعاصر، وتحدد RFC 1652 تفاوض 8BITMIME، ثم توضح RFC 2046 أنواع MIME لاحقاً. وتسجل RFC 3629 التقييس اللاحق لـUTF-8.

لا تقيس هذه السلسلة الاعتماد. أوصت RFC 1922 على الأقل بإرسال ISO-2022-CN واستقباله، وباستقبال أكبر عدد عملي من الترميزات الموصوفة. لم تثبت مطابقة منتج بعينه ولا انتقالاً آلياً بلا فقد إلى UTF-8. وقال قسم اعتبارات الأمن إن الأمن لم يُناقش.

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

لم تلغ RFC 1922 الحالة. جعلت زمنها ومكان إعادتها مرئيين، حتى لا يحكم هروب غائب سطراً حاضراً.