الخلاصة

  • منحت RFC 3987 معرّفات الموارد الدولية (IRI)، التي يمكن أن تتضمن Unicode، موضعاً محدداً إلى جانب البرمجيات المعتمدة على URI. ويتوقف التحويل على مكوّن العنوان: فقد يحتاج المضيف الذي يمثل اسماً لنطاق إلى معالجة IDNA، بينما تُمثّل أحرف Unicode في المسار أو الاستعلام باستخدام UTF-8 والترميز بالنسبة المئوية.
  • تذكر RFC 3987 كلاً من Martin J. Dürst وMichel Suignard مؤلفَين؛ ويصف السجل الجامعي لـDürst دوره بأنه المؤلف الرئيسي لمواصفة IRI. يصل هذا المعيار بين الكتابات التي يقرأها الناس والبرمجيات الأقدم، لكنه لا يسجل اسماً ولا يثبت السيطرة على نطاق ولا يبرهن أن سلسلتين متشابهتين بصرياً تعرّفان المورد نفسه.

ما الذي يثبته العنوان، وما الذي لا يثبته؟

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

لهذا الغرض وُجدت معرّفات الموارد الدولية، أو IRI. تحدد RFC 3986 البنية العامة لمعرّفات الموارد الموحّدة (URI)، ويقتصر نطاق محارفها على جزء من US-ASCII. وفي يناير 2005 أضافت RFC 3987 عنصراً مكملاً قادراً على حمل Unicode، بدلاً من تغيير تعريف URI القديم ضمناً. يشرح مؤلفوها أن إنشاء عنصر بروتوكولي جديد يحافظ على تمييز واضح ويتجنب عدم التوافق مع البرمجيات القائمة. يستطيع المكوّن الذي يدعم IRI الاحتفاظ بالصيغة الأوسع؛ أما إذا لم يقبل مسار استرجاع المورد إلا URI، فيلزم تحويل IRI إلى صيغة URI المقابلة.

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

يبدأ الخلاف عند اسم المضيف، لا في كل العنوان

يظهر الفصل الأهم بعد //، في جزء السلطة من عنوان الويب. إذا كان المضيف اسماً لنطاق على طريقة DNS، فإن تحويل RFC 3987 لعام 2005 يطبق عملية ToASCII من IDNA على كل وسم تفصله نقطة. والنتيجة صيغة متوافقة مع ASCII تستطيع برمجيات عصر URI معالجتها. ويحوّل مثال RFC المضيف résumé.example.org إلى xn--rsum-bpad.example.org.

يوضح المثال ما تفعله Punycode وما لا تفعله. فهي ترمّز وسم نطاق إلى صيغة متوافقة مع ASCII؛ ولا تحوّل عنوان الويب كاملاً، ولا ينبغي تطبيقها على كل مكوّن غير ASCII. كما أن السابقة xn-- ليست شهادة صلاحية: تميز RFC 5890 بين وسم A صالح وفق IDNA وسلسلة لا تشبهه إلا ظاهرياً. لا تكفي الهيئة البصرية؛ بل يلزم التحقق وفق البروتوكول.

وتوجد حدود زمنية بين أجيال المعايير أيضاً. تستشهد RFC 3987 في تحويل المضيف بـRFC 3490، بروتوكول IDNA لعام 2003. أما إطار IDNA2008 اللاحق، بما فيه RFC 5890 وRFC 5891، فقد حدّث المصطلحات والقواعد البروتوكولية. وتشرح RFC 5895، وهي وثيقة معلوماتية، عمليات المواءمة التي قد تطبقها الواجهة على مدخل المستخدم قبل معالجة IDNA2008. وهي تقر بأن المواءمة المفيدة قد تختلف بحسب اللغة والتطبيق وطريقة الإدخال. لذلك ينبغي قراءة مثال RFC 3987 ضمن سياقه في عام 2005، لا بوصفه ضماناً أن كل متصفح اليوم يطبق تحويلاً موحداً.

المسار ليس وسم نطاق

إذا انتقلت الأحرف نفسها إلى المسار، اختلفت المعالجة. يمكن تمثيل مقطع مثل /研究 في URI بصيغة /%E7%A0%94%E7%A9%B6 بعد ترميز بايتات UTF-8 بالنسبة المئوية. لا تُستخدم Punycode للمسار. فقد يفسره خادم ويب أو إطار تطبيق أو مخزن ملفات أو موجّه خاص بالتطبيق؛ ولا يحل DNS كل مقطع من مقاطع المسار.

للاستعلام والجزء اللاحق دلالات مستقلة أيضاً. فقد تكون علامة النسبة أو الشرطة المائلة أو علامة الاستفهام أو المربّع فاصلاً بنيوياً لا بيانات عادية، ولذلك يهم ترتيب التحليل والهروب. تُبقي RFC 3987 على بنية مكوّنات URI وتوسع في الوقت ذاته المحارف التي يمكن أن تظهر مباشرة في IRI. ليست القاعدة «استبدل كل محرف Unicode بطريقة كتابة ASCII»؛ فالمخطط والمكوّن هما ما يحددان العملية الملائمة.

لهذا توصي المواصفة بتأخير التحويل قدر الإمكان، إلى أن يصل المعرّف إلى مكوّن لا يستطيع معالجة IRI. وقد يؤدي التحويل المبكر إلى فقدان الصيغة المفهومة للقارئ قبل أن يتلقاها تطبيق آخر يدعم IRI. وإذا طبّع الخادم المسار أو فك ترميزه بترتيب مختلف، فقد يختلف نظامان في فهم المسار المطلوب. تصميم Dürst وSuignard يعالج وصلة بين الأنظمة، لا مجرد إظهار أحرف غير لاتينية في شريط العنوان.

صحة الترميز لا تعني تسجيل الاسم

تجيب IDNA عن سؤال محدود: هل يمكن تمثيل وسم وفق القواعد المنطبقة والتحقق منه؟ تفصل RFC 5891 بين تسجيل أسماء النطاقات الدولية والبحث عنها في DNS. وتقع معالجة المسجلين قبل وصول الطلب إلى مدير المنطقة خارج تعريف بروتوكول IDNA؛ أما السجل أو مدير المنطقة فيتحقق من السلسلة المحددة المقدمة للتسجيل. لذلك لا يثبت وسم A صحيح نحوياً أن الاسم سُجل أو فُوّض في DNS أو صار تحت سيطرة الخدمة التي يتوقعها القارئ.

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

وهذه مسألة أمنية كذلك. تحذر RFC 3987 من الانتحال البصري في المضيف والمسار معاً: قد تجعل المحارف المتشابهة بصرياً، أو اختلاف توقعات التطبيع، أو تباين معالجة العميل والخادم عنوانين متقاربين ظاهرياً يختاران موردين مختلفين. لا تقول المواصفة إن Unicode خطر في ذاته؛ بل تطلب من النظام أن يعرف المكوّن والتحويل اللذين يعتمد عليهما. ما يظهر على الشاشة دليل على طريقة العرض، لا شهادة هوية.

مساهمة Dürst بلا أسطورة المؤلف المنفرد

تذكر صفحة RFC اسمَي M. Dürst وM. Suignard مؤلفَين. ويصف السجل الرسمي لـDürst في جامعة Aoyama Gakuin دوره بأنه المؤلف الرئيسي لمواصفة IRI، كما يوثق عمله السابق في تدويل الويب واستخدام Unicode وتطبيع المحارف المركبة. ويذكر أيضاً قيادته نشاط التدويل في W3C خلال جزء كبير من الفترة التي تشكلت فيها RFC 3987. وتعرّفه الجامعة أستاذاً في كلية العلوم والهندسة لديها.

تدعم هذه الوقائع مساهمة مهمة، لا قصة اختراع فردي. وتكمن أهمية العمل في قرار معماري: بدلاً من مطالبة برمجيات URI بتخمين معنى محارف جديدة، يمنح IRI البرمجيات الداعمة تمثيلاً على مستوى المحارف ويحدد موضع الحاجة إلى التحويل. كانت مساهمة Dürst جزءاً من جهد أوسع لوضع المعايير، وRFC نفسها تنسب التأليف أيضاً إلى Suignard.

الربط بين هذا المقال و«الحق في السجلات الدقيقة» لدى Heng Lu محدود عمداً. تتناول الملاحظة 72 السجلات الإقليمية للإنترنت وموارد أرقام الإنترنت؛ فهي ليست سياسة DNS ولا تحكم أسماء النطاقات. والسؤال التحليلي المفيد هنا فقط هو: هل يصف السجل الحالة التي يدّعي وصفها بدقة؟ إن الصيغة المكتوبة بـUnicode، ووسم A، وتفويض DNS، ومفتاح المورد لدى خدمة ويب سجلات مترابطة لكنها تنتمي إلى طبقات مختلفة؛ ولا يغني أحدها عن سائرها.

المصادر