الخلاصة

  • سجلت RFC 7763، وهي وثيقة معلوماتية من IETF صدرت في مارس 2016، نوع الوسائط text/markdown. يفرض التسجيل charset ويتيح variant الاختياري للإشارة إلى الصياغة التي قصدها الكاتب.
  • قيمة variant إشارة للمستقبل وليست أمراً يلزمه بتفسير معين. وثّقت RFC 7764 صيغاً متعددة، منها Original وGFM وCommonMark وPandoc.
  • تسجل IANA نوع الوسائط وتحتفظ بسجل مستقل لصيغ Markdown. الاسم المشترك يصف المحتوى، أما التطبيق فينفذ قواعد قراءته.

فاتورة الجدول المفقود

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

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

تشرح RFC 7764 كيف نشأت هذه المسافة. بدأت Markdown بصيغة كتابة اقترحها John Gruber بمساهمة Aaron Swartz في 2004، ثم صنعت البيئات المختلفة نسخها. تسرد الوثيقة Original وGFM وCommonMark وPandoc وغيرها. ويتضمن وصف GFM جداول وكتلاً برمجية محاطة بعلامات وروابط تلقائية. هذه قواعد تنفيذية؛ قد يكون الخط العمودي فاصلاً بين عمودين في نسخة، وعلامة مطبوعة في نسخة أخرى.

الاسم على الرسالة

حسمت RFC 7763 سؤالاً أول: كيف يعلن النظام أن النص القادم من عائلة Markdown؟ أجابت بتسجيل text/markdown. يستطيع خادم الويب أو رسالة البريد وضعه في Content-Type، بدلاً من ترك الطرف الآخر يخمن من امتداد .md. يشترط التسجيل charset لتحديد تحويل البايتات إلى أحرف قبل تطبيق قواعد الصياغة. لم يمنح RFC هذا النوع ترميزاً افتراضياً.

ثم جاء السؤال الثاني: أي Markdown؟ أضافت الوثيقة معاملاً اختيارياً هو variant. يمكن للمرسل كتابة Content-Type: text/markdown; charset=UTF-8; variant=Original ليعرض على الطرف الآخر العائلة واللغة المقصودة معاً. إذا غاب المعامل، يحدد السياق وبرنامج الاستقبال القراءة. وإذا حضر، يبقى تلميحاً؛ يجوز للمستقبل أن يعمل به، وتبقى لديه حرية اختياره العملي.

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

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

سجلان بلا آلة قراءة

تضع IANA text/markdown في سجل أنواع الوسائط، وتدرج Original وGFM وCommonMark وPandoc وغيرها في سجل مستقل للصيغ. إجراء تسجيل الصيغ مبني على أسبقية الطلب. يصبح لدى الأنظمة أسماء تتبادلها، لكن كل برنامج يحتاج إلى محلل ينفذ الصيغة التي يقول إنه يفهمها.

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

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