8 بت نظيف

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

تاريخ

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

لا يمكن نقل الملفات الثنائية المكونة من ثماني بتات مباشرةً عبر قنوات بيانات ذات سبع بتات. وللتغلب على هذه المشكلة، تم ابتكار ترميزات لتحويل البيانات الثنائية إلى نص ، تستخدم فقط أحرف ASCII ذات سبع بتات . من هذه الترميزات : uuencoding و Ascii85 و SREC و BinHex و kermit و Base64 الخاص بـ MIME . لا تستطيع الأنظمة القائمة على EBCDIC التعامل مع جميع الأحرف المستخدمة في البيانات المشفرة بـ UUencoding، بينما لا تعاني ترميز Base64 من هذه المشكلة.

SMTP وNNTP

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

صُممت العديد من معايير بروتوكولات الاتصالات المبكرة، مثل RFC 780 و 788 و 821 و 2821 و 5321 (لبروتوكول SMTP ) و RFC 977 (لبروتوكول NNTP ) و RFC 1056 ، للعمل عبر روابط اتصال "ذات 7 بت". وتشترط هذه المعايير تحديدًا استخدام ترميز ASCII "يُرسل كبايت ذي 8 بت مع مسح البت الأعلى إلى الصفر"، وبعضها [ 1 ] يقيد صراحةً جميع البيانات بأحرف ذات 7 بت.   

خلال العقود القليلة الأولى من شبكات البريد الإلكتروني (من عام 1971 إلى أوائل التسعينيات)، كانت معظم رسائل البريد الإلكتروني عبارة عن نص عادي باستخدام مجموعة الأحرف الأمريكية ASCII ذات 7 بت. [ 2 ]

يُقيّد تعريف بروتوكول SMTP في RFC 788، كما هو الحال في سابقه RFC 780، رسائل البريد الإلكتروني عبر الإنترنت بأسطر (1000 حرف أو أقل) من أحرف ASCII الأمريكية ذات 7 بتات. [ 3 ] [ 4 ] [ 5 ] [ 6 ]

لاحقًا، أُعيد تعريف تنسيق رسائل البريد الإلكتروني لدعم الرسائل التي لا تقتصر على نص ASCII الأمريكي (الرسائل النصية التي تستخدم مجموعات أحرف أخرى غير ASCII الأمريكي، والرسائل غير النصية، مثل الصوت والصور). [ 6 ] يتطلب حقل رأس الرسالة Content-Transfer-Encoding=binary [ a ] نقلًا نظيفًا بـ 8 بت.

تنصّ RFC 3977 [ 7 ] على أن "بروتوكول NNTP يعمل عبر أي قناة بيانات ثنائية الاتجاه موثوقة بعرض 8 بتات"، وتُغيّر مجموعة الأحرف للأوامر إلى UTF-8 . مع ذلك، لا تزال RFC 5536 [ 8 ] تُقيّد مجموعة الأحرف بـ ASCII، بما في ذلك RFC 2047 [ 9 ] وRFC 2231 [ 10 ] اللتان تُشيران إلى ترميز MIME للبيانات غير ASCII.

يُضيف مجتمع الإنترنت عادةً ميزاتٍ جديدةً تدريجيًا ، مما يسمح بالاتصال ثنائي الاتجاه بين الأجهزة المُحدَّثة والأجهزة التي لم تُحدَّث بعد، بدلاً من اعتبار البرامج القديمة المتوافقة مع المعايير سابقًا معيبةً، والمطالبة بتحديث جميع البرامج في العالم إلى أحدث معيار. الطريقة المُوصى بها للاستفادة من روابط 8 بت النظيفة بين الأجهزة هي استخدام امتداد 8BITMIME الخاص ببروتوكول ESMTP ( RFC 1869 ) [ 11 ] [ 12 ] لمحتوى الرسائل، وامتداد SMTPUTF8 الخاص ببروتوكول SMTP [ 13 ] لرؤوس الرسائل. مع ذلك، تقوم بعض برامج نقل البريد ، ولا سيما Exim و qmail ، بإعادة توجيه البريد إلى خوادم لا تُعلن عن 8BITMIME دون إجراء التحويل إلى MIME ذي 7 بت (عادةً ما يكون تحويلًا قابلًا للطباعة ، "تحويل QP") المطلوب بموجب RFC 6152. في الواقع، لا يُسبب هذا النهج "الإرسال المباشر 8 بت" مشاكل في الممارسة العملية، لأن جميع خوادم البريد الإلكتروني الحديثة تقريبًا نظيفة 8 بت. [ 14 ]  

انظر أيضاً

ملحوظات

  1. لا يشير حقل رأس الصفحة Content-Transfer-Encoding=8BIT إلى 8 بت نظيف، لأن CRLF له أهمية خاصة.

مراجع

  1. RFC 780 : الملحقأ، RFC 788 : 4.5.2، RFC 821 : الملحقب، RFC 1056 : 4.      
  2. جون بيك. "شرح البريد الإلكتروني" . 2011.
  3. جوناثان ب. بوستل (نوفمبر 1981). "4.5.3. الأحجام". بروتوكول نقل البريد البسيط . IETF . doi : 10.17487/RFC0788 . RFC 788. الحد الأقصى للطول الإجمالي لسطر نصي، بما في ذلك <CRLF> ، هو 1000 حرف (ولكن لا يتم احتساب النقطة البادئة المكررة للشفافية).
  4. ج. فودروي (فبراير 1993). "2. المشكلة". انتقال بريد الإنترنت من Just-Send-8 إلى 8bit-SMTP/MIME . IETF . doi : 10.17487/RFC1428 . RFC 1428. يحدد بروتوكول SMTP، كما هو مُعرَّف في RFC 821 ، إرسال بريد الإنترنت بأحرف ASCII الأمريكية.
  5. دان سوغالسكي. "البريد الإلكتروني مع المرفقات" . "مجلة بيرل". صيف 1999. "عندما تم توحيد معايير البريد في عام 1982 بموجب RFC822، ... كانت القيود الوحيدة المفروضة على نص الرسالة هي مجموعة الأحرف (ASCII 7 بت) والحد الأقصى لطول السطر (1000 حرف)."
  6. 1 2 ن. فريد؛ ن. بورنشتاين (نوفمبر 1996). "ملخص". ملحقات البريد الإلكتروني متعددة الأغراض (MIME) الجزء الأول: تنسيق نصوص رسائل الإنترنت . IETF . doi : 10.17487/RFC2045 . RFC 2045. تُعيد ملحقات البريد الإلكتروني متعددة الأغراض ( MIME ) تعريف تنسيق الرسائل .
  7. سي. فيذر (أكتوبر 2006). بروتوكول نقل أخبار الشبكة (NNTP) . IETF . doi : 10.17487/RFC3977 . RFC 3977 .
  8. سي. ليندسي؛ دي. كون (نوفمبر 2009). ك. مورتشيسون (محرر). تنسيق مقالات Netnews . IETF . doi : 10.17487/RFC5536 . RFC 5536 .
  9. ك. مور (نوفمبر 1996). MIME (ملحقات البريد الإلكتروني متعددة الأغراض) الجزء الثالث: ملحقات رأس الرسالة للنصوص غير ASCII . مجموعة عمل الشبكة. doi : 10.17487/RFC2047 . RFC 2047 .مسودة معيار. تم تحديثها بواسطة RFC 2184 و 2231 . تلغي RFC 1590 و 1522 و 1521 .  
  10. ن. فريد؛ ك. مور (نوفمبر 1997). قيم معلمات MIME وامتدادات الكلمات المشفرة: مجموعات الأحرف واللغات والاستمراريات . IETF . doi : 10.17487/RFC2231 . RFC 2231 .
  11. ثيودور تسو ؛ كيث مور ؛ مارك كريسبين (12 سبتمبر 1994). "إرسال 8 بت في بروتوكول NNTP" . قائمة بريد IETF -SMTP . مؤرشف من الأصل في 20 مارس 2012. تم الاطلاع عليه في 3 أبريل 2010 .
  12. "أسئلة وأجوبة comp.mail.mime، الجزء 3: ما هو ESMTP، وكيف يؤثر على MIME؟"" . أسئلة وأجوبة يوزنت . 8 أغسطس 1997. مؤرشف من الأصل في 18 يناير 2012. تم الاطلاع عليه في 3 أبريل 2010. "
  13. ج. ياو؛ و. ماو (فبراير 2012). امتداد SMTP للبريد الإلكتروني الدولي . IETF . doi : 10.17487/RFC8531 . RFC 8531 .
  14. "امتداد 8BITMIME" .