الميم

تعد امتدادات البريد الإلكتروني متعددة الأغراض ( MIME ) معيارًا يوسع تنسيق رسائل البريد الإلكتروني لدعم النص في مجموعات أحرف غير ASCII ، بالإضافة إلى مرفقات الصوت والفيديو والصور وبرامج التطبيقات. قد تتكون نصوص الرسائل من أجزاء متعددة، وقد يتم تحديد معلومات الرأس في مجموعات أحرف غير ASCII. عادةً ما يتم إرسال رسائل البريد الإلكتروني بتنسيق MIME باستخدام بروتوكولات قياسية، مثل بروتوكول نقل البريد البسيط (SMTP)، وبروتوكول مكتب البريد (POP)، وبروتوكول الوصول إلى الرسائل عبر الإنترنت (IMAP).

MIME هو معيار إنترنت . وهو محدد في سلسلة من طلبات التعليقات : RFC 2045 و RFC 2046 و RFC 2047 و RFC 4288 و RFC 4289 و RFC 2049. ويتم تحديد التكامل مع بريد SMTP الإلكتروني في RFC 1521 و RFC 1522 .

على الرغم من أن صيغة MIME مصممة بشكل أساسي لبروتوكول SMTP، فإن أنواع محتواها مهمة أيضًا في بروتوكولات الاتصال الأخرى . في بروتوكول نقل النص التشعبي (HTTP) لشبكة الويب العالمية ، تقوم الخوادم بإدراج حقل رأس MIME في بداية أي عملية إرسال عبر الويب. يستخدم العملاء نوع المحتوى أو نوع الوسائط الرأسية لتحديد تطبيق المشاهدة المناسب لنوع البيانات المشار إليها.

نشأ MIME من نظام Andrew Messaging System، والذي كان جزءًا من مشروع Andrew الذي تم تطويره في جامعة كارنيجي ميلون (CMU)، كبديل متعدد الأنظمة لتنسيق البيانات الخاص بـ Andrew. ^[1]

يشير وجود حقل الرأس هذا إلى أن الرسالة بتنسيق MIME. القيمة عادةً هي "1.0". يظهر الحقل على النحو التالي:

إصدار MIME: 1.0

وفقًا لما ذكره ناثانيال بورنشتاين، أحد مؤسسي MIME ، فقد تم تقديم رقم الإصدار للسماح بإجراء تغييرات على بروتوكول MIME في الإصدارات اللاحقة. ومع ذلك، اعترف بورنشتاين بوجود أوجه قصور في المواصفات التي أعاقت تنفيذ هذه الميزة: "لم نحدد بشكل كافٍ كيفية التعامل مع إصدار MIME المستقبلي... لذا إذا كتبت شيئًا يعرف 1.0، فماذا يجب أن تفعل إذا واجهت 2.0 أو 1.1؟ اعتقدت نوعًا ما أن الأمر واضح، لكن اتضح أن الجميع نفذوا ذلك بطرق مختلفة. والنتيجة هي أنه سيكون من المستحيل تقريبًا على الإنترنت تعريف 2.0 أو 1.1." ^[2]

يشير حقل الرأس هذا إلى نوع الوسائط لمحتوى الرسالة، والذي يتكون من نوع ونوع فرعي ، على سبيل المثال

نوع المحتوى: نص/عادي

من خلال استخدام نوع متعدد الأجزاء ، يسمح MIME لرسائل البريد الإلكتروني بترتيب أجزاء في بنية شجرية حيث تكون العقد الورقية أي نوع محتوى غير متعدد الأجزاء والعقد غير الورقية أي نوع من أنواع متعددة الأجزاء. تدعم هذه الآلية (على سبيل المثال لا الحصر):

• رسائل نصية بسيطة باستخدام text/plain (القيمة الافتراضية لـ "Content-Type: ")
• نص بالإضافة إلى المرفقات ( أجزاء متعددة/مختلطة بجزء نصي/عادي وأجزاء أخرى غير نصية). تشير رسالة MIME التي تتضمن ملفًا مرفقًا بشكل عام إلى الاسم الأصلي للملف مع رأس "Content-Disposition"، بحيث يتم الإشارة إلى نوع الملف من خلال كل من نوع محتوى MIME وامتداد اسم الملف (عادةً ما يكون خاصًا بنظام التشغيل )
• الرد مع النص الأصلي المرفق ( متعدد الأجزاء/مختلط بنص /جزء عادي والرسالة الأصلية كرسالة /جزء rfc822 )
• محتوى بديل، مثل رسالة تم إرسالها بنص عادي وتنسيق آخر مثل HTML ( متعدد الأجزاء/بديل بنفس المحتوى في أشكال نص/نص عادي ونص /HTML )
• الصورة والصوت والفيديو والتطبيق (على سبيل المثال، image/jpeg ، audio/mp3 ، video/mp4 ، application/msword ، وغيرها).

لم تصف مواصفات MIME الأصلية سوى بنية رسائل البريد الإلكتروني. ولم تعالج مسألة أنماط العرض. تمت إضافة حقل رأس المحتوى في RFC 2183 لتحديد نمط العرض. يمكن أن يحتوي جزء MIME على:

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

بالإضافة إلى أسلوب العرض، يوفر حقل Content-Disposition أيضًا معلمات لتحديد اسم الملف وتاريخ الإنشاء وتاريخ التعديل، والتي يمكن أن يستخدمها وكيل مستخدم بريد القارئ لتخزين المرفق.

تم أخذ المثال التالي من RFC 2183، حيث تم تعريف حقل الرأس:

المحتوى-التوزيع: المرفق؛ اسم الملف=genome.jpeg؛
  تاريخ التعديل="الأربعاء، 12 فبراير 1997 16:29:51 -0500";

يمكن ترميز اسم الملف كما هو محدد في RFC 2231.

اعتبارًا من عام 2010، لم تتبع غالبية وكلاء مستخدمي البريد هذه الوصفة بالكامل. يتجاهل عميل البريد Mozilla Thunderbird المستخدم على نطاق واسع حقول ترتيب المحتوى في الرسائل ويستخدم خوارزميات مستقلة لتحديد أجزاء MIME لعرضها تلقائيًا. يرسل Thunderbird قبل الإصدار 3 أيضًا رسائل مؤلفة حديثًا مع ترتيب محتوى مضمّن لجميع أجزاء MIME. لا يدرك معظم المستخدمين كيفية تعيين ترتيب المحتوى على attachment . ^[3] يرسل العديد من وكلاء مستخدمي البريد أيضًا رسائل باسم الملف في معلمة الاسم لرأس نوع المحتوى بدلاً من معلمة اسم الملف لحقل الرأس Content-Disposition . لا يُنصح بهذه الممارسة، حيث يجب تحديد اسم الملف إما باستخدام المعلمة filename أو بكلا المعلمتين filename و name . ^[4]

في بروتوكول HTTP، عادةً ما يتم استخدام حقل رأس الاستجابة Content-Disposition: attachment كإشارة إلى العميل لتقديم نص الاستجابة كملف قابل للتنزيل. عادةً، عند تلقي مثل هذه الاستجابة، يطالب متصفح الويب المستخدم بحفظ المحتوى كملف، بدلاً من عرضه كصفحة في نافذة متصفح، مع اقتراح اسم الملف باسم الملف الافتراضي.

في يونيو 1992، قامت MIME (RFC 1341، والتي أصبحت قديمة منذ ذلك الحين بموجب RFC 2045) بتعريف مجموعة من الطرق لتمثيل البيانات الثنائية بتنسيقات أخرى غير تنسيق نص ASCII. حقل رأس MIME content-transfer-encoding: له أهمية من جانبين:

• يشير هذا إلى ما إذا كان قد تم استخدام مخطط ترميز ثنائي إلى نص فوق الترميز الأصلي كما هو محدد في رأس Content-Type أم لا :

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

تحدد قائمة ترميزات النقل الخاصة بـ RFC وIANA القيم الموضحة أدناه، والتي لا تراعي حالة الأحرف. تعني القيم "7bit" و"8bit" و"binary" أنه لم يتم استخدام ترميز ثنائي إلى نص أعلى الترميز الأصلي. في هذه الحالات، يكون حقل الرأس زائدًا عن الحاجة بالنسبة لعميل البريد الإلكتروني لفك تشفير نص الرسالة، ولكنه قد يظل مفيدًا كمؤشر لنوع الكائن الذي يتم إرساله. تخبر القيمتان " quoted-printable " و" base64 " عميل البريد الإلكتروني أنه تم استخدام مخطط ترميز ثنائي إلى نص وأن فك التشفير الأولي المناسب ضروري قبل أن تتمكن من قراءة الرسالة باستخدام ترميزها الأصلي (على سبيل المثال UTF-8).

• مناسب للاستخدام مع SMTP العادي:
  • 7 بت – ما يصل إلى 998 ثماني بتات لكل سطر من نطاق التعليمات البرمجية 1..127 مع السماح فقط بظهور CR وLF (الرموز 13 و10 على التوالي) كجزء من نهاية سطر CRLF. هذه هي القيمة الافتراضية.
  • quote-printable – يستخدم لترميز تسلسلات ثماني بتات عشوائية في شكل يلبي قواعد 7 بت. تم تصميمه ليكون فعالاً وسهل القراءة من قبل البشر عند استخدامه لبيانات نصية تتكون في الأساس من أحرف US-ASCII ولكنها تحتوي أيضًا على نسبة صغيرة من البايتات ذات القيم خارج هذا النطاق.
  • base64 – يستخدم لترميز تسلسلات ثماني بتات عشوائية في شكل يلبي قواعد 7 بت. مصمم ليكون فعالاً للبيانات غير النصية المكونة من 8 بتات والبيانات الثنائية. يستخدم أحيانًا للبيانات النصية التي تستخدم بشكل متكرر أحرفًا غير US-ASCII.
• مناسب للاستخدام مع خوادم SMTP التي تدعم امتداد 8BITMIME SMTP (RFC 6152):
  • 8 بت - ما يصل إلى 998 ثماني بتات لكل سطر مع السماح بظهور CR وLF (الرموز 13 و10 على التوالي) فقط كجزء من نهاية سطر CRLF.
• مناسب للاستخدام مع خوادم SMTP التي تدعم امتداد BINARYMIME SMTP (RFC 3030):
  • ثنائي - أي تسلسل من الثمانيات.

لا يوجد ترميز محدد مصمم صراحةً لإرسال بيانات ثنائية عشوائية عبر عمليات نقل SMTP مع امتداد 8BITMIME. وبالتالي، إذا لم يكن BINARYMIME مدعومًا، فإن base64 أو quote-printable (مع عدم كفاءتهما المرتبطة) لا يزالان مفيدين في بعض الأحيان. لا ينطبق هذا القيد على استخدامات أخرى لـ MIME مثل خدمات الويب مع مرفقات MIME أو MTOM .

منذ RFC 2822، تستخدم أسماء حقول وقيم رؤوس الرسائل المتوافقة أحرف ASCII؛ يجب أن تستخدم القيم التي تحتوي على بيانات غير ASCII صيغة الكلمات المشفرة MIME (RFC 2047) بدلاً من سلسلة حرفية. تستخدم هذه الصيغة سلسلة من أحرف ASCII تشير إلى كل من ترميز الأحرف الأصلي (" charset ") وترميز نقل المحتوى المستخدم لتعيين بايتات مجموعة الأحرف إلى أحرف ASCII.

النموذج هو: " ترميز =?مجموعة الأحرف النص المشفر ". ???=

• قد تكون مجموعة الأحرف عبارة عن أي مجموعة أحرف مسجلة لدى IANA . وعادةً ما تكون نفس مجموعة الأحرف الموجودة في نص الرسالة.
• يمكن أن يكون الترميز إما " Q" للإشارة إلى ترميز Q المشابه للترميز القابل للطباعة المقتبس ، أو " B" للإشارة إلى ترميز base64 .
• النص المشفر هو النص المشفر بتقنية Q أو base64.
• لا يجوز أن يزيد طول الكلمة المشفرة عن 75 حرفًا، بما في ذلك مجموعة الأحرف والترميز والنص المشفر والفواصل . إذا كان من المرغوب فيه ترميز نص أكثر مما يتناسب مع كلمة مشفرة مكونة من 75 حرفًا، فيمكن استخدام كلمات مشفرة متعددة (مفصولة بمسافة CRLF).

لا يجوز تمثيل رموز ASCII لعلامة الاستفهام ("؟") وعلامة التساوي ("=") بشكل مباشر لأنها تُستخدم لتحديد الكلمة المشفرة. ولا يجوز تمثيل رمز ASCII للمسافة بشكل مباشر لأنه قد يتسبب في قيام المحللات القديمة بتقسيم الكلمة المشفرة بشكل غير مرغوب فيه. ولجعل الترميز أصغر وأسهل للقراءة، يتم استخدام الشرطة السفلية لتمثيل رمز ASCII للمسافة مما يخلق التأثير الجانبي المتمثل في عدم إمكانية تمثيل الشرطة السفلية بشكل مباشر. ويفرض استخدام الكلمات المشفرة في أجزاء معينة من حقول الرأس قيودًا إضافية على الأحرف التي يمكن تمثيلها بشكل مباشر.

على سبيل المثال،

Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?=

يتم تفسيرها على أنها "الموضوع: مرحبًا، سيدي!".

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

تحتوي رسالة MIME متعددة الأجزاء على حدود في حقل الرأس Content-Type:؛ هذه الحدود، التي يجب ألا تظهر في أي من الأجزاء، توضع بين الأجزاء، وفي بداية ونهاية نص الرسالة، على النحو التالي:

إصدار MIME: 1.0 
نوع المحتوى: متعدد الأجزاء / مختلط ؛ الحدود = الحدود الخارجية  

هذه رسالة مكونة من أجزاء متعددة بتنسيق MIME.
--frontier 
نوع المحتوى: نص / عادي 

هذا هو نص الرسالة.
--frontier 
نوع المحتوى: تطبيق / دفق ثماني بتات ترميز نقل المحتوى: base64 
 

PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg 
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== 
--الحدود--

يتألف كل جزء من عنوان محتوى خاص به (صفر أو أكثر Content-من حقول العنوان) وجسم. يمكن تضمين محتوى الأجزاء المتعددة. Content-Transfer-Encodingيجب أن يكون نوع الأجزاء المتعددة دائمًا "7 بت" أو "8 بت" أو "ثنائي" لتجنب التعقيدات التي قد تفرضها مستويات متعددة من فك التشفير. لا تحتوي كتلة الأجزاء المتعددة ككل على مجموعة أحرف؛ يتم التعامل مع الأحرف غير ASCII في رؤوس الأجزاء بواسطة نظام Encoded-Word، ويمكن تحديد مجموعات الأحرف لأجسام الأجزاء إذا كانت مناسبة لنوع المحتوى الخاص بها.

ملحوظات:

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

يحدد معيار MIME أنواعًا فرعية مختلفة من الرسائل متعددة الأجزاء، والتي تحدد طبيعة أجزاء الرسالة وعلاقتها ببعضها البعض. يتم تحديد النوع الفرعي في Content-Typeحقل رأس الرسالة الإجمالية. على سبيل المثال، سيتم تعيين رسالة MIME متعددة الأجزاء باستخدام النوع الفرعي للتلخيص Content-Typeعلى أنها "multipart/digest".

في البداية، حدد RFC أربعة أنواع فرعية: مختلطة ومختصرة وبديلة ومتوازية. يجب أن يدعم التطبيق المتوافق إلى حد أدنى الأنواع المختلطة والمختصرة؛ أما الأنواع الفرعية الأخرى فهي اختيارية. يجب أن تعامل التطبيقات الأنواع الفرعية غير المعترف بها على أنها "متعددة الأجزاء/مختلطة". ومنذ ذلك الحين، تم تعريف أنواع فرعية إضافية، مثل البيانات الموقعة وبيانات النموذج، بشكل منفصل في RFCs أخرى.

يتم استخدام multipart/mixed لإرسال ملفات ذات Content-Typeحقول رأسية مختلفة مضمنة (أو كمرفقات). عند إرسال صور أو ملفات أخرى سهلة القراءة، ستعرضها معظم برامج البريد الإلكتروني مضمنة (ما لم يتم تحديد ذلك صراحةً باستخدام Content-Disposition: attachment، وفي هذه الحالة يتم تقديمها كمرفقات). نوع المحتوى الافتراضي لكل جزء هو "text/plain".

تم تعريف النوع في RFC 2046. ^[5]

multipart/digest هي طريقة بسيطة لإرسال رسائل نصية متعددة. نوع المحتوى الافتراضي لكل جزء هو "message/rfc822".

تم تعريف نوع MIME في RFC 2046. ^[6]

يشير النوع الفرعي متعدد الأجزاء/البديل إلى أن كل جزء هو نسخة "بديلة" من نفس المحتوى (أو محتوى مشابه)، كل جزء بتنسيق مختلف يتم الإشارة إليه بواسطة عنوان "نوع المحتوى" الخاص به. ترتيب الأجزاء مهم. تنص RFC1341 على: بشكل عام، يجب على وكلاء المستخدم الذين يؤلفون كيانات متعددة الأجزاء/بديلة وضع أجزاء النص بترتيب تصاعدي للتفضيل، أي مع وضع التنسيق المفضل في النهاية. ^[7]

يمكن للأنظمة بعد ذلك اختيار "أفضل" تمثيل يمكنها معالجته؛ وبشكل عام، سيكون هذا هو الجزء الأخير الذي يمكن للنظام فهمه، على الرغم من أن عوامل أخرى قد تؤثر على هذا.

نظرًا لأن العميل من غير المرجح أن يرغب في إرسال نسخة أقل دقة من نسخة النص العادي، فإن هذا الهيكل يضع نسخة النص العادي (إذا كانت موجودة) أولاً. وهذا يجعل الحياة أسهل لمستخدمي العملاء الذين لا يفهمون الرسائل المتعددة الأجزاء.

في أغلب الأحيان، يتم استخدام multipart/alternative للبريد الإلكتروني الذي يحتوي على جزأين، نص عادي (text/plain) و HTML (text/html) . يوفر جزء النص العادي التوافق مع الإصدارات السابقة بينما يسمح جزء HTML باستخدام التنسيق والارتباطات التشعبية. تقدم معظم برامج البريد الإلكتروني خيارًا للمستخدم لتفضيل النص العادي على HTML؛ وهذا مثال على كيفية تأثير العوامل المحلية على كيفية اختيار التطبيق لجزء "الأفضل" من الرسالة لعرضه.

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

تم تعريف النوع في RFC 2046. ^[9]

يتم استخدام multipart/related للإشارة إلى أن كل جزء من الرسالة هو أحد مكونات كل مجمع. وهو مخصص للكائنات المركبة التي تتكون من عدة مكونات مترابطة - لا يمكن تحقيق العرض المناسب من خلال عرض الأجزاء المكونة بشكل فردي. تتكون الرسالة من جزء الجذر (افتراضيًا، الأول) الذي يشير إلى أجزاء أخرى مضمنة، والتي قد تشير بدورها إلى أجزاء أخرى. تتم الإشارة إلى أجزاء الرسالة عادةً بواسطة Content-ID . لا يتم تحديد بناء الجملة للمرجع ويتم تحديده بدلاً من ذلك بواسطة الترميز أو البروتوكول المستخدم في الجزء.

أحد الاستخدامات الشائعة لهذا النوع الفرعي هو إرسال صفحة ويب كاملة بالصور في رسالة واحدة. يحتوي الجزء الجذري على مستند HTML ، ويستخدم علامات الصور للإشارة إلى الصور المخزنة في الأجزاء الأخيرة.

تم تعريف النوع في RFC 2387.

multipart/report هو نوع رسالة يحتوي على بيانات منسقة ليتمكن خادم البريد من قراءتها. وهو مقسم بين نص عادي (أو أي محتوى آخر/نوع يمكن قراءته بسهولة) ورسالة/حالة تسليم، والتي تحتوي على البيانات المنسقة ليتمكن خادم البريد من قراءتها.

تم تعريف النوع في RFC 6522.

تُستخدم الرسالة متعددة الأجزاء/الموقَّعة لإرفاق توقيع رقمي برسالة. وهي تتألف من جزئين أساسيين فقط، جزء أساسي وجزء توقيع. ويُستخدم جزء الأساسي بالكامل، بما في ذلك حقول MIME، لإنشاء جزء التوقيع. وهناك العديد من أنواع التوقيع الممكنة، مثل "application/pgp-signature" (RFC 3156) و"application/pkcs7-signature" ( S/MIME ).

تم تعريف النوع في RFC 1847. ^[10]

تتكون الرسالة متعددة الأجزاء/المشفرة من جزأين. يحتوي الجزء الأول على معلومات التحكم اللازمة لفك تشفير الجزء الثاني من التطبيق/دفق الثمانية بتات. وعلى غرار الرسائل الموقعة، توجد تنفيذات مختلفة يتم تحديدها من خلال أنواع المحتوى المنفصلة الخاصة بها للجزء التحكمي. الأنواع الأكثر شيوعًا هي "application/pgp-encrypted" (RFC 3156) و"application/pkcs7-mime" ( S/MIME ).

نوع MIME المحدد في RFC 1847. ^[11]

يتم استخدام نوع MIME multipart/form-data للتعبير عن القيم المرسلة من خلال نموذج. تم تعريفه في الأصل كجزء من HTML 4.0، ويُستخدم بشكل شائع لإرسال الملفات باستخدام HTTP . وهو محدد في RFC 7578، الذي حل محل RFC 2388. مثال

تم تطوير نوع المحتوى multipart/x-mixed-replace كجزء من تقنية لمحاكاة الدفع والخادم عبر HTTP.

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

تم تطويره في الأصل بواسطة Netscape ، ^[12] ولا يزال مدعومًا بواسطة Mozilla و Firefox و Safari و Opera . يُستخدم عادةً في كاميرات IP كنوع MIME لتدفقات MJPEG . ^[13] كان مدعومًا بواسطة Chrome للموارد الرئيسية حتى عام 2013 (لا يزال من الممكن عرض الصور باستخدام نوع المحتوى هذا). ^[14]

يتم استخدام multipart/byterange لتمثيل نطاقات البايتات غير المتجاورة لرسالة واحدة، ويتم استخدامه بواسطة HTTP عندما يقوم الخادم بإرجاع نطاقات بايتات متعددة ويتم تعريفه في RFC 2616.

• RFC 1426، تمديد خدمة SMTP لنقل MIME 8 بت . J. Klensin ، N. Freed ، M. Rose ، E. Stefferud ، D. Crocker. فبراير 1993.
• RFC 1847، أجزاء متعددة للأمان لـ MIME: أجزاء متعددة/موقّعة وأجزاء متعددة/مشفرة
• RFC 3156، أمان MIME مع OpenPGP
• RFC 2045، MIME الجزء الأول: تنسيق نصوص الرسائل على الإنترنت
• RFC 2046، الجزء الثاني من MIME: أنواع الوسائط . ن. فريد، ناثانيال بورنشتاين . نوفمبر 1996.
• RFC 2047، الجزء الثالث من MIME: ملحقات رأس الرسالة للنصوص غير المكتوبة بصيغة ASCII . كيث مور . نوفمبر 1996.
• RFC 4288، MIME الجزء الرابع: مواصفات نوع الوسائط وإجراءات التسجيل .
• RFC 4289، الجزء الرابع من MIME: إجراءات التسجيل . ن. فريد، ج. كلينسين. ديسمبر 2005.
• RFC 2049، الجزء الخامس من MIME: معايير المطابقة والأمثلة . ن. فريد، ن. بورينستين. نوفمبر 1996.
• RFC 2183، توصيل معلومات العرض في رسائل الإنترنت: حقل رأس المحتوى والترتيب . Troost، R.، Dorner، S. وK. Moore. أغسطس 1997.
• RFC 2231، قيمة معلمة MIME وامتدادات الكلمات المشفرة: مجموعات الأحرف واللغات والاستمرارات . ن. فريد، ك. مور. نوفمبر 1997.
• RFC 2387، نوع المحتوى متعدد الأجزاء/المرتبط بـ MIME
• RFC 1521، آليات تحديد ووصف تنسيق نصوص رسائل الإنترنت
• RFC 7578، إرجاع القيم من النماذج: multipart/form-data

• 8 بت مايم
• الترميز الثنائي إلى نص
• تغليف الرسائل المباشرة عبر الإنترنت (DIME) - وهو بروتوكول تم استبداله الآن من قبل شركة Microsoft، وكان الغرض منه أن يكون بمثابة MIME مبسط، للاستخدام في المقام الأول في خدمات الويب .
• نوع الوسائط
• ربط الكائنات وتضمينها (OLE)
• إس/ميم
• بروتوكول نقل البريد البسيط (SMTP)
• صابون مع المرفقات
• يونيكود والبريد الإلكتروني
• ترميز Uuen
• نائب الرئيس التنفيذي

• هيوز، ل. (1998). بروتوكولات البريد الإلكتروني عبر الإنترنت، المعايير والتنفيذ . دار أرتيك للنشر. رقم ISBN 978-0-89006-939-4.
• جونسون، ك. (2000). بروتوكولات البريد الإلكتروني عبر الإنترنت: دليل للمطورين . أديسون ويسلي بروفيشنال. رقم ISBN 978-0-201-43288-6.
• Loshin, P (1999). Essential Email Standards: RFCs and Protocols Made Practical . John Wiley & Sons. ISBN 978-0-471-34597-8.
• Rhoton, J (1999). دليل المبرمجين للبريد الإلكتروني عبر الإنترنت: SMTP وPOP وIMAP وLDAP . Elsevier. ISBN 978-1-55558-212-8.
• وود، د. (1999). برمجة بريد الإنترنت . أوريلي. رقم ISBN 978-1-56592-479-6.

• أنواع الوسائط MIME – تتألف من قائمة أدلة أنواع المحتوى والأنواع الفرعية، والتي تحتفظ بها هيئة أرقام الإنترنت المخصصة .
• قائمة مجموعات الأحرف
• تكوين أنواع MIME الخاصة بالخادم بشكل صحيح
• وصف سهل المتابعة للرسائل متعددة الأجزاء من MH & nmh
• "رجال MIME: كيف غيّر اثنان من خبراء الإنترنت البريد الإلكتروني إلى الأبد". 1 فبراير 2011.
• أداة فحص PHP MIME المجانية عبر الإنترنت
• أداة التحقق من صحة البريد الإلكتروني MIME عبر الإنترنت مجانًا

Original text

Rate this translation

Your feedback will be used to help improve Google Translate