مختبر يعيد تركيب رسالة بريد متعددة الأجزاء: مشاريع تخرج هندسة البرمجيات

يظهر في صندوق بريد تجريبي نص HTML بلا البديل النصي، أو يظهر اسم مرفق غريب بعد فك الرسالة. مختبر مشروع تخرج هندسة البرمجيات ينشئ رسالة في الذاكرة ثم يمررها إلى parser ويقارن بنية الأجزاء قبل وبعد الترميز. تفرق RFC 2045 بين MIME headers وترميز المحتوى، وتعرف RFC 2046 media types مثل multipart/mixed وmultipart/alternative. لا يحتاج الفريق إلى إرسال رسائل؛ يمكن أن تكون كل التجربة fixtures محلية تمنع تسريب عناوين أو مرفقات.

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

مثّل الرسالة كشجرة أجزاء

لا تعرض البريد كسلسلة خام فقط. أنشئ شجرة فيها الرسالة الرئيسية، رؤوسها، Content-Type وboundary، وكل جزء فرعي مع نوعه وترميز نقله. في multipart/alternative قد يحتوي فرع نصاً plain وآخر HTML يمثلان المحتوى نفسه بدرجتين من العرض؛ أما multipart/mixed فيجمع أجزاء متفاوتة مثل body ومرفق. اكتب وصفاً واضحاً لهذا الفرق، ولا تفترض ترتيباً واحداً دائماً لكل برنامج بريد. خزن كل fixture كنص ثابت يمكن مراجعته في Git، مع إزالة بيانات شخصية أو نطاقات البريد الحقيقية. هذه البنية تعطي الطالب نقاطاً محددة لاختبار parser.

أنشئ الحالات عبر مكتبة موثوقة

استخدم package email من Python لتوليد أو تحليل الرسائل بدلاً من concatenation يدوي للرؤوس، وتراجع عن كتابة parser يدوي للـboundary. وثائق Python email تشرح message objects وسياسات parsing. اجعل fixture الأول رسالة نصية، والثاني نصاً وHTML، والثالث مرفقاً binary صغيراً، والرابع nested multipart. احفظ سياسة serialization ونسخة runtime؛ بعض التفاصيل تتغير بحسب EmailPolicy. إذا لم يستطع parser فهم رسالة معيبة، اعرض defect المسجل بدلاً من تجاهله بصمت.

تتبّع مرفقاً عربياً صغيراً

أنشئ رسالة فيها body عربي وملف نصي اسمه تقرير-مختبر.txt بمحتوى عربي قصير. بعد serialize ثم parse، افحص أن اسم الملف والبايتات وcharset بقيت كما قصد الفريق. لا تقارن النص المرئي فقط؛ قد تختلف طريقة ترميز الأحرف بينما تمثل المعنى نفسه. خزّن SHA-256 للبايتات قبل وبعد لتأكيد التطابق، واطبع أنواع الأجزاء. مثال صغير كهذا يكشف خطأ header encoding أو نقل newline من غير إنشاء مرفقات حقيقية. أضف حالة مرفق فارغ واسم طويل وحرفاً غير لاتيني.

ضع شرطاً واضحاً للتكافؤ

المقارنة round-trip لا تتطلب أن يطابق كل byte من الرسالة النصية؛ serializer قد يعيد طي الرؤوس أو اختيار boundary مختلفاً. قارن شجرة الحقول ونوع الجزء والمحتوى بعد فك transfer encoding واسم الملف المفسر. احتفظ بالرسالة الخام أيضاً لمراجعة الاختلافات. اكتب قواعد normalization محدودة ومعلنة، ولا تطبع header ثم تعتبره متكافئاً إن تغير المستلم أو نوع المحتوى. معيار القبول هو حفظ المعلومات المهمة حسب schema المشروع، لا مطابقة تنسيق كل برنامج بريد.

حالات فشل لا بد منها

اختبر boundary ناقصاً أو مكرراً داخل النص، header بلا قيمة مفهومة، transfer encoding غير معروف، base64 مبتور، nested multipart غير مغلق، ورسالة لا تملك MIME-Version. حدد هل parser يرفض أو يعيد defect أو يستعيد بعض المحتوى؛ لا تكتب متوقعاً عاماً وتخفي سلوك المكتبة. قارن الحالة الصحيحة بنسخة معطوبة واحدة في كل مرة، واترك اختلاف الرسالة raw واضحاً. اختبر مرفقاً كبيراً ضمن حد ذاكرة معلن، لا تحمل دفقاً مفتوحاً إلى الذاكرة بلا سقف. لا تفتح الملفات المستخرجة تلقائياً.

افصل التحليل عن العرض والتنفيذ

قد يحتوي HTML رسالة على صور remote وروابط أو script غير مرغوب. اعرضه كنص أو في sandbox مع تعطيل الشبكة والبرامج النصية، ولا تنفذ تعليمات من مرفق. استخدم أسماء ملفات محايدة واحفظ المرفقات مؤقتاً في مجلد اختبار. لا ترسل fixture عبر SMTP أو خدمة خارجية؛ المشروع يتعلم بنية MIME وليس تسليم البريد. لا تستنتج أن نجاح parser يعني أن كل عميل بريد سيعرض الرسالة بالطريقة نفسها، لأن سياسات العميل والتطهير والموارد البعيدة تختلف.

ناتج يصلح لمناقشة جامعية

يسلم الفريق حزمة fixtures، شجرة MIME قبل وبعد، اختلافات serialization، وعدداً من defects المتوقعة والمتحققة. يمكن بحث النطاق ضمن مشاريع التخرج وربطه بخدمة تطوير التطبيقات إذا صمم الفريق واجهة فحص. حد المشروع واضح: لا يقيس deliverability ولا spam ولا مصادقة SMTP. نجاحه أن يشرح كيف بنيت الرسالة، وكيف تغيرت أثناء التحويل، وما المعلومات التي تم الحفاظ عليها أو فقدها.