التطبيقات القادرة على معالجة معمارية 8 بت
التطبيقات القادرة على معالجة معمارية 8 بت يصف مصطلح (8-bit clean) الحواسيب القادرة على معالجة تشفيرات رموز 8 بت مثل سلسلة (ISO 8859) أو تشفير (UTF-8) الخاص بيونيكود.[1]
تاريخ عدل
حتى أوائل تسعينات القرن الماضي كان العديد من البرامج وقنوات نقل البيانات موجهة لمعالجة بعض الرموز، مثل (EXT) والذي يعد رمز تحكمي، والبعض الآخر افترض استمرار رموز 7 بت ذات القيم من 0 إلى 127، مثل نظام (ASCII) الذي يستخدم رموز 7 بت وحسب ويتجنب الـ 8 بت بغية تقليل تكاليف نقل البيانات، وفي الحواسيب وسلاسل البيانات التي تستخدم 8 بت بايت أدى هذا إلى ترك أعلى بت من كل بايت غير مستخدم كزوج ولا تابع لبت أخر ولا كبت متحكم في البيانات الوصفية. وتعد انظمة 7 بت وسلاسل البيانات غير قادرة على التعامل مع رموز أكثر تعقيدا على نحو مباشر مثل أبجدية بعض الدول غير الناطقة باللغة الإنكليزية كالابجدية العربية مثلاً.[2]
ولا يمكن نقل الملفات الثنائية المتكونة من ثمانية الحوسبة عبر قنوات نقل الـ 7 بت على نحو مباشر، وللتحايل على هذه العقبة ابتكر ما يعرف بتشفير النص الثنائي والذي يقتصر على استخدام رموز 7 بت الخاصة بنظام (ASCII)، ومن الامثلة على هذا التشفير لدينا (uuencoding) و (Ascii85) و (SREC) و (BinHex) و (kermit) و (MIME's Base64)، ولا تستطيع الانظمة المبنية على EBCDIC معالجة الرموز المستخدمة ببيانات Uuencoded، ولكن تلك المبنية على تشفير الاساس 64 لا تعاني من هذه المشكلة.
كيف تمكنت تطبيقات STMP وNNTP من معالجة معمارية 8 بت عدل
تاريخيا مختلف أنواع أجهزة الاعلام كانت قادرة على نقل الرسائل ولكن اقتصر بعضها على استخدام بيانات الـ 7 بت وحسب ولذلك حظيت رسائل الـ 8 بت بفرصة عالية لان تخرج مشوهه بعد عملية النقل بالقرن العشرين، ولكن لم تأبه بعض التطبيقات بالتثبيط العرفي لبيانات الـ 8 بت وسمحت بنقل بيانات البت ذات البايت العالي (بيانات 8 بت)، وأعتبرت هذه التطبيقات بأنها تطبيقات قادرة على معالجة معمارية 8 بت، وعموما تدعى بروتوكولات التواصل بأنها قادرة على معالجة معمارية 8 بت إذا عبرت خلال البت العالي من كل بايت على نحو صحيح أثناء عملية التواصل.
وصممت العديد من بروتوكولات التواصل الحديثة للعمل على خطوط تواصل 7 بت مثل RFC 780 و788 و821 و2821 و5321 الخاصة ببروتوكول نقل البريد البسيط (STMP) وRFC 977 و1056 الخاصة ببروتوكول نقل أخبار الشبكة (NNTP)، وتستلزم هذه البروتوكولات استخدام مجموعة رموز ASCII دون غيرها منقولة بصيغة 8 بت مع لزوم تصفير البت العالي وبعضها يقيد جميع البيانات برموز 7 بت.
وفي أول عقود شبكات البريد (من عام 1971 إلى بدايات تسعينات القرن الماضي) كانت اغلب الرسائل البريدية نصوص بسيطة التي تستخدم رموز US-ASCII ذات معمارية 7 بت.
ويحد بروتوكول RFC 788 رسائل الإنترنت على سطور تتكون من 1000 رمز أو اقل من رموز US-ASCII ذات معمارية 7 بت ولا يختلف بهذا عن سابقة بروتوكول RFC 780.
ولاحقا أعيد تعريف صيغة رسائل البريد الإلكتروني لدعم الرسائل التي تستخدم رموز غير تلك الخاصة بـ US-ASCII مثل الرسائل التي تحتوي أصوات أو صور.
وخُصِصَ بروتوكول RFC 3977 للعمل على أي قناة بيانات 8 بت ثنائية الاتجاه ويغير مجموعة الرموز لـ UTF-8، ولكن لايزال بروتوكول RFC 5536 منغلقا على مجموعة رموز ASCII بما يشمل بروتوكول RFC 2047 و2231 ويستخدم تشفير MINE لأي بيانات غير منحصرة على رموز ASCII.[3]
يزيد الإنترنت عموما من ميزاته على نحو دوري عن طريق إضافتها مما سمح بالتواصل بين الألات المتطورة والتي لم تتطور بعد بدلا من القول بأن المعايير المتوافقة مع البرامج القديمة أصبحت «متخلفة» ونلزم جميع البرامج حول العالم بالتطوير للمعايير الجديدة، وفي منتصف التسعينات احتج الناس عن طريق إرسال عبارة «أرسل 8 بت وحسب» لخوادم بروتوكول RFC 821 وقد يكون ذلك بسبب معرفتهم بأن عبارة «أرسل 8 بت وحسب» تصرح ضمنيا بأن نظام ISO 8859-1 أصبح «المعيار الجديد للتشفير» مما أرغم العالم أجمع على استخدام نفس مجموعة الرموز، وعوضا عن ذلك كانت الطريقة المقترحه لإستغلال التطبيقات القادرة على معالجة معمارية 8 بت عن طريق ربط الالات ببعضها البعض وجعلها تستخدم إضافة 8BITMIME لمحتوى الرسائل وإضافة SMTP لعناوين الرسائل، وعلى الرغم من هذا حولت بعض خوادم الرسائل (خصوصا خادمي Exim وqmail) الرسائل الاكترونية لخوادم لا تنشر بصيغة 8BITMIME بدون تحويلها لـ 7BITMIME وأغلب ما يحول النصوص المقتبسة والصالحة للطباعة وهي ضرورية لبروتوكول RFC 6152. ولم تسبب حملة «أرسل 8 بت وحسب» أي مشاكل عملية لانه فعليا كل خوادم الرسائل الاكترونية الحديثة قادرة على معالجة 8 بت.[4]
انظر أيضا عدل
مراجع عدل
- ^ RFC 780: Appendix A, RFC 788: 4.5.2., RFC 821: Appendix B, RFC 1056: 4.
- ^ Jonathan B. Postel (November 1981). "4.5.3. SIZES". SIMPLE MAIL TRANSFER PROTOCOL. doi:10.17487/RFC0788. RFC 788. The maximum total length of a text line including the <CRLF> is 1000 characters (but not counting the leading dot duplicated for transparency).
- ^ N. Freed; N. Borenstein (November 1996). "Abstract". Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. doi:10.17487/RFC2045. RFC 2045. Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages
- ^ Dan Sugalski. "E-mail with Attachments". "The Perl Journal". Summer 1999. "When mail was standardized way back in 1982 with RFC822, ... The only limits placed on the body were the character set (7-bit ASCII) and the maximum line length (1000 characters)."
