الخلاصة

  • حدّد RFC 1740 في ديسمبر 1994 طريقة إرسال ملفات Macintosh عبر MIME. يجمع AppleSingle المحتوى والسمات في تدفق واحد، بينما يفصل AppleDouble معلومات الجهاز والموارد عن شعبة البيانات.
  • فضّل النص للغالبية التي تحتاج تغليفاً خاصاً صيغة multipart/appledouble: جزء application/applefile يحمل المعلومات الخاصة بالجهاز، وجزء بيانات يحمل نوع MIME المناسب لمحتواه.

الصورة وأيقونتها لا تسكنان البيت نفسه

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

استفاد Patrik Faltstrom وDave Crocker وErik E. Fair في RFC 1740 من البنية متعددة الأجزاء التي وصفها RFC 1521 لـMIME. يستطيع كل جزء في الرسالة إعلان نوع محتواه. أعطاهم ذلك وسيلة لخدمة قارئين مختلفين من الرسالة نفسها. قارئ Macintosh يحتاج الموارد مع البيانات. قارئ نظام آخر يريد أن يلتقط الصورة أو المستند بلغته المعتادة من دون تفكيك عبوة خاصة أولاً.

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

أما AppleDouble فيستخدم حجرتين. يحتوي الرأس على شعبة الموارد ومعلومات سطح المكتب، وتبقى شعبة البيانات منفصلة. يحمل multipart/appledouble جزأين بالضبط: الأول application/applefile، والثاني يصف البيانات بنوعها الملائم. في مثال RFC استُخدم image/gif، وعند غياب نوع مسجل مناسب يأتي application/octet-stream. يستطيع الحاسوب الآخر قراءة جزء البيانات كما يقرأ أي جزء MIME مألوف؛ ويستطيع Macintosh جمع الجزأين لاستعادة معلومات الملف.

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

احتفظ البريد القديم بشروطه عند حافة الظرف. قد يحتاج تدفق AppleSingle الثنائي أو رأس AppleDouble الثنائي إلى ترميز نقل؛ وذكر RFC أن Base64 هو الأكثر أماناً عند عبور قنوات مقيدة. وأوصى بوسيط name ليعرف المستلم اسم المرفق، لكن قواعد MIME الموروثة حصرت قيمته في US-ASCII ذي سبعة بتات. أمكن حفظ تفصيل معقد داخل الملف، بينما ظلت بطاقة اسمه تستخدم أبجدية أضيق. هذه مفارقة تقنية صريحة لا تحتاج زينة.

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

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