الخلاصة

  • يوثق draft-ietf-nfsv4-internationalization-17 مسارات مختلفة ومشروعة للتعامل مع أسماء NFSv4: مقارنة ثمانية البتات بوصفها بيانات معتمة، أو استخدام الوعي بـ Unicode والتكافؤ المعياري والتطبيع وقواعد حالة الأحرف. لا يستطيع العميل عادة استنتاج السياسة الكاملة من استجابة ناجحة.
  • قبل النسخ الاحتياطي أو التكرار أو التحول الاحتياطي أو النقل، ينبغي إعداد «إيصال تكافؤ فضاء الأسماء» يتضمن البايتات المرسلة، والأسماء المعادة، وبيئة الاختبار، ونتائج التصادم، وإشارات القدرات، وما ظل غير قابل للرصد.

نتيجة واحدة وأسباب متعددة

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

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

صدرت المراجعة 17 من مسودة تدويل NFSv4 في 11 سبتمبر 2026، بعد ملاحظات مرحلة IETF Last Call. الوثيقة نشطة على مسار Standards Track ومحالة إلى IESG، لكنها ما زالت Internet-Draft وليست RFC ولا دليلاً على تطبيق أي منتج للسلوك الموصوف.

تاريخ المسودة يفسر أهمية هذا التحفظ. يذكر تقرير المشرف أن نص التدويل في NFSv4.1 لم يُنفذ كما كان مخططاً. واتبعت التطبيقات الكبرى المذكورة نهج NFSv4.0 غير الواعي بـ UTF-8 على نطاق واسع، فيما بقيت الوظائف الواعية محدودة وتجريبية. لذلك تعتمد الصياغة الحالية بدرجة كبيرة على السلوك الفعلي. التنسيق هنا يبدأ مما تقارنه الأنظمة حقاً، لا مما كان يفترض أن تفعله.

حين تكون الهوية هي البايتات

في نظام ملفات غير واعٍ بـ UTF-8، يكون كل مكوّن من الاسم سلسلة معتمة من ثمانية البتات. وتتم المقارنة بايتاً ببايت. يسمح ذلك ببقاء أسماء أنشأتها ترميزات قديمة، وبسلاسل ليست UTF-8 صالحة. لكنه يعني أيضاً أن تمثيلين متكافئين معيارياً في Unicode يظلان اسمين مختلفين متى اختلفت البايتات.

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

أما الخادم الواعي بـ UTF-8 فلديه خيارات أكثر. يستطيع تحويل الاسم إلى صيغة تطبيع قبل التخزين، أو حفظ الشكل الوارد مع قبول الأشكال المتكافئة معيارياً أثناء البحث. ويمكنه تحويل متغيرات حالة الأحرف أو اعتبارها متساوية عند المقارنة. وقد تأتي السياسة الفعلية من الخادم، أو من نظام الملفات، أو من التهيئة المشتركة بينهما.

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

ما لا تقوله إشارة القدرة

توفر السمة fs_charset_cap معلومة محدودة. تستخدمها المسودة الحالية للدلالة على خادم لا يقبل إلا أسماء UTF-8. أما الاستخدام التاريخي لـ FSCHARSET_CAP4_CONTAINS_NON_UTF8 فبقي ملتبساً؛ لذا توصي المسودة بأن تقدم الخوادم متمم ذلك العلم وأن يتجاهله العملاء. وإذا لم تكن السمة مدعومة، يمكن لاختبار مضبوط باسم غير UTF-8 أن يكشف جانباً من سياسة القبول.

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

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

READDIR لا يسرد كل الأسئلة المقبولة

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

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

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

النقل يبدل صاحب الحكم

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

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

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

إيصال تكافؤ فضاء الأسماء

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

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

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

يسجل الإيصال ما إذا كانت كل صيغة قابلة للإنشاء، وهل يعيد LOOKUP مقبض الملف نفسه، وما الذي تعرضه READDIR، وما الذي تشير إليه fs_charset_cap، وهل تتغير النتيجة بعد تفريغ التخزين المؤقت السلبي أو تجاوزه. تُجرى اختبارات قابلة للمقارنة على المصدر والوجهة، ويصنف كل استنتاج إلى ملاحظة أو تصريح مورّد أو افتراض لم يختبر.

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

ولا ينبغي توسيع الاستنتاج. محتوى الرابط الرمزي معتم وفق قواعد أخرى، وأسماء النطاقات غير ASCII تتبع U-label، وأنواع السلاسل في NFS ليست متطابقة. الإيصال لا يمنح شهادة عامة لـ Unicode؛ بل يثبت علاقات محددة في بيئة محددة.

حد الدليل

يوضح RFC 6943 أن المقارنة غير المتسقة للمعرفات قد تسبب إيجابيات كاذبة وسلبيات كاذبة وحجب خدمة، وقد تؤدي في بعض الأنظمة إلى رفع صلاحيات. هذه ليست رواية عن حادثة NFS، ولا تدعي المسودة وقوعها. لكنها سبب كافٍ لإدخال تكافؤ الأسماء في مراجعة الأمن عندما تشارك المسارات في التفويض أو التنفيذ أو حفظ السجلات.

العبارة التي يمكن الدفاع عنها ضيقة: فضاء أسماء معين على جانب خادم عالج تسلسل بايتات بعينه، في وقت وتهيئة محددين. لم يثبت هوية عالمية للمحارف ولا علاقة مساواة قابلة للنقل ولا ضماناً بأن خادماً آخر سيكرر القرار. نجاح البحث واقعة؛ أما قابلية النقل فدليل مستقل يبنى عند الحدود.

المصادر