الخلاصة

  • لا يساوي Net-Unicode عبارة «UTF-8 صالح»: يضيف RFC 5198 التطبيع NFC، وحالة تخصيص نقاط الشفرة، ونهاية CRLF، وحدود المحارف الضابطة.
  • قد تتغير مكتبات النظام أو اللغة من دون تغيير كود التطبيق؛ لذلك يجب أن يربط السجل كل قرار بنسخة Unicode وبيانات NFC والمدخل والمخرج الفعليين.

برنامج واحد، عقدان نصيان

تثبت بصمة التطبيق ما نُشر من بايتاته، ولا تثبت كل ما استدعاه أثناء التشغيل. يلاحظ RFC 5198 أن التطبيقات تعتمد عادة على وظائف نظام التشغيل أو مكتبة اللغة للتحويل والتطبيع. ويمكن تحديث هذه الوظائف من دون تعديل كود التطبيق. بل قد لا يملك البرنامج وسيلة معقولة لمعرفة نسخة Unicode أو إجراء التطبيع المستخدم، ولا لضمان اتساقهما.

هذه ليست دعوى بأن NFC يتبدل عشوائياً. يستند RFC إلى ضمان الاستقرار: السلسلة الخالية من النقاط غير المخصصة والمطبّعة بالفعل تظل NFC في النسخ اللاحقة. الحد المتحرك هو مخزون المحارف. فالنقطة غير المخصصة تُطبّع إلى نفسها، ثم قد تدخل بعد تخصيصها لاحقاً في علاقة تطبيع. ويحظر Net-Unicode على المرسل إرسال نقطة غير مخصصة في النسخة التي يعتمد عليها.

لهذا يمكن لعقدتين تحملان الإصدار التطبيقي نفسه أن تختلفا: قاعدة قديمة ترفض النقطة، وقاعدة أحدث تقبلها. لا تشرح إشارة NFC=true أي قاعدة اتخذت الحكم.

ست طبقات داخل كلمة «صالح»

يفرض RFC 5198 ترميز RFC 3629 UTF-8، لكنه يضيف ملفاً للنص الشبكي. إن كان للبروتوكول مفهوم السطر، فلا ينتهي إلا بـ CRLF. يبقى CR NUL إرثاً غير مستحب وقد يتحول NUL إلى فاصل سلسلة. تُحظر محارف C1، ولا تحل IND أو NEL أو U+2028 أو U+2029 محل CRLF. ويحظر BOM في البداية.

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

حتى سجل التصحيحات يحافظ على السلطة. التصحيح 7531، وما يزال Reported، يعترض على وصف U+0080–U+009F بأنها ضمن ASCII، بينما يظل حظر C1 مستقلاً وصريحاً. أما التصحيح المتحقق 1402 فيغير إحالة تحريرية فقط. لا يجوز تحويل كل بلاغ إلى نص معياري جديد بلا بيان حالته.

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

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

يؤثر ترتيب العمليات أيضاً: التطبيع قبل التحقق من التوقيع ليس التحقق من البايتات الأصلية ثم التطبيع. وتغيير نهايات الأسطر يحرك المواضع، وإزالة BOM تحويل وليست مجرد ملاحظة. لا يستبدل RFC 5198 قواعد البروتوكولات التي عرّفت UTF-8 بدقة؛ يجب تسجيل الملف المطبق والترتيب الفعلي.

سجل يعيد القرار

يسجل الدليل نسخة التطبيق وبصمته، ثم صورة المضيف أو الحاوية، وruntime اللغة، ونسخة قاعدة Unicode، وتنفيذ NFC وبياناته. إن أخفت المنصة النسخة، فالقيمة الصحيحة هي «غير معروفة».

يربط سجل الرسالة بصمة البايتات بنتيجة UTF-8 وتسلسل النقاط وحكم مخصص/غير مخصص. وتبقى قرارات BOM والاستخدام الخاص وC0 وC1 وCR وLF وCR NUL وU+2028 وU+2029 منفصلة. كما تحفظ بصمتا ما قبل التطبيع ومخرج NFC.

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

المصادر

  1. RFC 5198 بصيغة HTML
  2. نص RFC 5198
  3. صفحة معلومات RFC 5198
  4. متتبع IETF لـ RFC 5198
  5. تاريخ RFC 5198
  6. مراجع RFC 5198
  7. تصحيحات RFC 5198
  8. RFC 3629 — UTF-8
  9. RFC 2277 — المحارف واللغات
  10. RFC 4690 — قضايا الأسماء المدولة
  11. RFC 3454 — Stringprep
  12. RFC 8264 — إطار PRECIS
  13. RFC 6365 — مصطلحات التدويل
  14. RFC 854 — Telnet
  15. RFC 698 — ASCII الموسع في Telnet
  16. ملحق Unicode رقم 15 — أشكال التطبيع
  17. سياسة استقرار Unicode
  18. Heng Lu — طبقات الواقع والقوة الرمزية
  19. Heng Lu — الحد الأدنى للمواصفة الأولية
  20. Heng Lu — أولوية الكود العامل