الخلاصة

  • يفصل RFC 2130 مجموعة المحارف المرمّزة CCS عن طريقة تحويل قيمها إلى ثمانيات CES، وعن صيغة تهيئتها للنقل TES. أما اللغة والإعدادات المحلية والثقافة والتخطيط البصري فتبقى مسائل مستقلة بعد وصول البيانات.
  • أوصى التقرير بتسميات MIME المسجلة وبـ ISO 10646 وUTF-8 افتراضياً في التصاميم الجديدة، مع الاعتراف بالتفاوض والتوافق والمجموعات الأخرى. إنه تقرير معلوماتي، لا بروتوكول جديداً ولا برهاناً على انتشار عالمي.

ما الذي ينبغي ألا يُترجم؟

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

انعقدت الورشة بدعوة من IAB في 29 فبراير و1 مارس 1996، ونُشر تقريرها في أبريل 1997 بتصنيف Informational. لم يضع معياراً جديداً للإنترنت. كانت تطبيقات البريد والأدلة والويب قد سلكت طرقاً مختلفة للتعامل مع النصوص الدولية. أراد المشاركون إطاراً يسمح بتسمية الخيارات بدل افتراض أن عبارة «مجموعة محارف» تكفي لوصف الرحلة كلها.

سبع طبقات ليست وعداً واحداً

تربط مجموعة المحارف المرمّزة CCS المحارف المجردة بأعداد صحيحة؛ ويحوّل مخطط الترميز CES تلك القيم إلى ثمانيات؛ ثم تغيّر صيغة النقل TES البيانات المرمّزة لكي تلائم قناة معينة. أمثلة هذه الوظائف هي ISO 10646 وUTF-8 وBase64 على التوالي. وفي MIME قد تجمع قيمة charset بين تعريف CCS وCES، بينما يصف Content-Transfer-Encoding التحويل الناقل. أقر التقرير بأن التسجيلات القائمة لا تفصل الطبقات دائماً، ودعا إلى توضيحها مستقبلاً.

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

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

اسم عام ليس مجلداً خاصاً

قسّم التقرير المسائل إلى آلية البروتوكول والمعرّفات والبيانات. واستند إلى RFC 1958 عند مناقشة الأسماء العامة الواسعة الظهور، ومنها أسماء DNS والعناصر النصية في البروتوكولات، التي أوصى ببقائها ASCII غير حساسة لحالة الأحرف. لا يصح نقل القيد نفسه تلقائياً إلى اسم مجلد خاص في صندوق بريد. والانتقال من بروتوكول قديم يعتمد ASCII إلى UTF-8 يستلزم تفاوضاً على النسخة أو مجموعة المحارف ومسار رجوع متوافقاً؛ لا يجوز إعادة تفسير البايتات القديمة بصمت. أما متن الرسائل وقواعد البيانات وصفحات HTML فتحتاج إلى معالجة مجموعات متعددة وسياق تطبيقي.

اقتراح ISO 10646 لمجموعة المحارف وUTF-8 لتمثيلها في البروتوكولات النصية الجديدة لا يلغي الافتراض القديم حيث يلزم التوافق. وقد تتطلب قناة سباعية البت تحويل نقل إضافياً؛ لم يقترح التقرير قيمة TES افتراضية عامة ولم يحظر مجموعات أخرى. يهتم RFC 2044 بصيغة بايتات UTF-8، و RFC 2066 بتفاوض Telnet، و RFC 2070 بفك ترميز HTML، و RFC 2152 ببريد السبع بتات. يضع RFC 2130 حدود ما تثبته هذه القرارات المختلفة، ولا يستبدلها بحل شامل.

المصادر وحدود الاستنتاج

تُستخدم ملاحظات Lu Heng عن الواقع والبرمجيات العاملة كعدسة تحريرية لاحقة، لا كشهادة على نيات المشاركين. لا تقدم هذه المصادر عدداً للنظم التي تبنت التوصيات ولا تقيس جودة قراءة مستخدم بعينه.