UTF-7
UTF-7 ( تنسيق تحويل يونيكود ذو 7 بتات ) هو ترميز أحرف قديم ذو طول متغير لتمثيل نصوص يونيكود باستخدام سلسلة من أحرف ASCII . كان الهدف منه في الأصل توفير وسيلة لترميز نصوص يونيكود لاستخدامها في رسائل البريد الإلكتروني عبر الإنترنت ، بحيث تكون أكثر كفاءة من دمج UTF-8 مع خاصية الطباعة المقتبسة .
لا يُعدّ ترميز UTF-7 (وفقًا لمواصفاته RFC) " تنسيق تحويل يونيكود "، إذ يقتصر تعريفه على ترميز نقاط الترميز في مجموعة نقاط الترميز الأساسية (أول 65536 نقطة ترميز يونيكود، والتي لا تشمل الرموز التعبيرية والعديد من الأحرف الأخرى). مع ذلك، إذا كان برنامج ترجمة UTF-7 يُحوّل من/إلى UTF-16، فإنه يستطيع (وربما يفعل) ترميز كل نصف بديل كما لو كان نقطة ترميز 16 بت، وبالتالي يستطيع ترميز جميع نقاط الترميز. من غير الواضح ما إذا كانت برامج UTF-7 الأخرى (مثل برامج الترجمة إلى UTF-32 أو UTF-8) تدعم هذه الميزة.
لم يكن ترميز UTF-7 معيارًا رسميًا لاتحاد يونيكود . ومن المعروف أنه ينطوي على مشكلات أمنية، ولذلك تم تعديل البرامج لتعطيل استخدامه. [ 1 ] وهو محظور في HTML 5. [ 2 ] [ 3 ]
تحفيز
يمنع معيار MIME ، المعيار الحديث لتنسيقات البريد الإلكتروني، ترميز الرؤوس باستخدام قيم بايتات تتجاوز نطاق ASCII. ورغم أن MIME يسمح بترميز نص الرسالة بمجموعات أحرف متنوعة (أوسع من ASCII)، إلا أن بنية الإرسال الأساسية ( SMTP ، معيار نقل البريد الإلكتروني الرئيسي) لا تضمن بالضرورة أن تكون خالية من الأخطاء (8 بت ). لذا، يجب تطبيق ترميز نقل محتوى غير بسيط في حال الشك. لسوء الحظ، يعاني Base64 من عيب يتمثل في جعل حتى أحرف ASCII غير قابلة للقراءة في برامج البريد الإلكتروني التي لا تدعم MIME. من جهة أخرى، ينتج عن دمج UTF-8 مع خاصية quoted-printable تنسيق غير فعال من حيث الحجم، إذ يتطلب من 6 إلى 9 بايتات للأحرف غير ASCII من BMP، و12 بايتًا للأحرف خارج BMP.
شريطة اتباع قواعد محددة أثناء التشفير، يمكن إرسال ترميز UTF-7 عبر البريد الإلكتروني دون استخدام ترميز نقل MIME أساسي ، ولكن يجب مع ذلك تحديده صراحةً كمجموعة أحرف نصية. إضافةً إلى ذلك، إذا استُخدم UTF-7 في رؤوس رسائل البريد الإلكتروني مثل "الموضوع:"، فيجب تضمينه في الكلمات المشفرة باستخدام MIME التي تُحدد مجموعة الأحرف. ولأن الكلمات المشفرة تُجبر على استخدام إما quoted-printable أو Base64 ، فقد صُمم UTF-7 لتجنب استخدام علامة = كحرف هروب لتجنب الهروب المزدوج عند دمجه مع quoted-printable (أو متغيره، ترميز RFC 2047/1522 "Q" للرؤوس).
لا يُستخدم ترميز UTF-7 عادةً كتمثيل أصلي داخل التطبيقات لصعوبة معالجته. ورغم ميزته في صغر الحجم مقارنةً بدمج UTF-8 مع كلٍ من quoted-printable أو Base64، فقد أوصى اتحاد البريد الإلكتروني للإنترنت ( الذي لم يعد موجودًا ) بعدم استخدامه. [ 4 ]
كما تم إدخال 8BITMIME ، مما يقلل الحاجة إلى ترميز محتويات الرسائل بتنسيق 7 بت.
استُخدم شكل مُعدَّل من ترميز UTF-7 (يُطلق عليه أحيانًا اسم "mUTF-7" [ 5 ] ) في بروتوكول استرجاع البريد الإلكتروني IMAP ، الإصدار 4 rev 1، لأسماء صناديق البريد "الدولية". [ 6 ] أما الإصدار التالي، IMAP الإصدار 4 rev 2، فيستخدم ترميز UTF-8 بدلاً من ذلك. [ 7 ]
وصف
طُرح ترميز UTF-7 لأول مرة كبروتوكول تجريبي في RFC 1642، وهو تنسيق تحويل آمن للبريد الإلكتروني لليونيكود . وقد أصبح هذا RFC قديمًا بعد صدور RFC 2152، وهو RFC إعلامي لم يُعتمد كمعيار. وكما ينص RFC 2152 بوضوح، فإنه "لا يُحدد أي معيار إنترنت". ومع ذلك، يُستشهد بـ RFC 2152 كتعريف لـ UTF-7 في قائمة مجموعات الأحرف الصادرة عن IANA. كما أن UTF-7 ليس معيارًا لليونيكود، إذ يقتصر معيار اليونيكود 5.0 على UTF-8 وUTF-16 وUTF-32. وهناك أيضًا نسخة مُعدلة، مُحددة في RFC 2060، والتي يُشار إليها أحيانًا باسم UTF-7.
يمكن تمثيل بعض الأحرف مباشرةً كبايتات ASCII مفردة. تُعرف المجموعة الأولى باسم "الأحرف المباشرة" وتحتوي على 62 حرفًا أبجديًا رقميًا و9 رموز. يُمكن تضمين الأحرف المباشرة بأمان. أما المجموعة الرئيسية الأخرى، والمعروفة باسم "الأحرف المباشرة الاختيارية"، فتحتوي على جميع الأحرف القابلة للطباعة الأخرى في النطاق U+ 0020 – U+007E باستثناء المسافة (حيث تم استبعاد الحرفين و نظرًا لإعادة تعريفهما في "متغيرات ASCII" مثل JIS-Roman ). يُقلل استخدام الأحرف المباشرة الاختيارية من حجم الملف ويُحسّن من سهولة قراءته، ولكنه يزيد أيضًا من احتمالية حدوث أخطاء بسبب عوامل مثل بوابات البريد المصممة بشكل سيئ، وقد يتطلب الأمر استخدام رموز هروب إضافية عند استخدامها في الكلمات المشفرة لحقول الترويسة.' ( ) , - . / : ?~ \ +\~
يمكن تمثيل المسافة، وعلامة الجدولة، وإرجاع المؤشر إلى بداية السطر، وتغذية السطر مباشرةً كبايتات ASCII مفردة. مع ذلك، إذا كان النص المُشفّر سيُستخدم في البريد الإلكتروني، فيجب توخي الحذر لضمان استخدام هذه الأحرف بطرق لا تتطلب تشفيرًا إضافيًا لنقل المحتوى ليكون مناسبًا للبريد الإلكتروني. يمكن تشفير علامة الجمع (+ +) على النحو التالي : .+-
يجب ترميز الأحرف الأخرى باستخدام UTF-16 (وبالتالي، سيتم ترميز U+10000 وما فوقها إلى صيغتين بديلتين)، ثم باستخدام Base64 المعدل . تُشير علامة إلى بداية هذه الكتل من ترميز UTF-16 المُرمّز باستخدام Base64 المعدل +. ويُشير أي حرف غير موجود في مجموعة Base64 المعدلة إلى نهايتها. إذا كان الحرف الذي يلي Base64 المعدل هو -( علامة ناقص ASCII )، فسيتم استهلاكه بواسطة وحدة فك الترميز، ويستأنف فك الترميز مع الحرف التالي. وإلا، يستأنف فك الترميز مع الحرف الذي يلي Base64.
أمثلة
Hello, World!يتم ترميز " " على النحو التالي "Hello, World+ACE-"1 + 1 = 2يتم ترميز " " على النحو التالي "1 +- 1 +AD0- 2"£1يتم ترميز الرمز " " كـ "+AKM-1". نقطة ترميز Unicode لعلامة الجنيه الإسترليني هي U+00A3، والتي تُحوّل إلى Base64 مُعدّل كما هو موضح في الجدول أدناه. يتبقى بتان، يتم ملؤهما بالأصفار.
| رقم سداسي عشري | 0 | 0 | أ | 3 | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| نمط البت | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 |
| فِهرِس | 0 | 10 | 12 | |||||||||||||||
| مُشفّر بصيغة Base64 | أ | ك | م | |||||||||||||||
خوارزمية التشفير وفك التشفير
التشفير
أولًا، يجب على المُشفِّر تحديد الأحرف التي سيتم تمثيلها مباشرةً بصيغة ASCII، والأحرف التي +يجب تهريبها باستخدام الفاصلة ( +-،)، والأحرف التي سيتم وضعها في مجموعات من أحرف Unicode. قد تكون تكلفة توسيع UTF-7 مرتفعة: على سبيل المثال، يبلغ حجم تسلسل الأحرف U+10FFFF U+0077 U+10FFFF تسعة بايتات في UTF-8، ولكنه يبلغ سبعة عشر بايتًا في UTF-7. (في أسوأ الأحوال، ينتج عن التعامل مع كل نقطة ترميز كتسلسل مستقل توسيعًا أقصى قدره خمسة أضعاف، كما هو الحال عند التشفير باستخدام الفاصلة @@( +AEA-+AEA-،). يجب تشفير كل تسلسل Unicode باستخدام الإجراء التالي، ثم إحاطته بالفواصل المناسبة.
باستخدام تسلسل الأحرف £† (U+00A3 U+2020) كمثال:
- عبّر عن أرقام يونيكود الخاصة بالحرف (UTF-16) بالنظام الثنائي:
- 0x00A3 → 0000 0000 1010 0011
- 0x2020 → 0010 0000 0010 0000
- قم بدمج التسلسلات الثنائية: 0000 0000 1010 0011 و 0010 0000 0010 0000 → 0000 0000 1010 0011 0010 0000 0010 0000
- أعد تجميع البيانات الثنائية إلى مجموعات من ستة بتات، بدءًا من اليسار: 0000 0000 1010 0011 0010 0000 0010 0000 → 000000 001010 001100 100000 001000 00
- إذا كانت المجموعة الأخيرة تحتوي على أقل من ستة بتات، فأضف أصفارًا لاحقة: 000000 001010 001100 100000 001000 00 → 000000 001010 001100 100000 001000 000000
- استبدل كل مجموعة من ستة بتات برمز Base64 المقابل لها: 000000 001010 001100 100000 001000 000000 → AKMgIA
فك التشفير
يجب أولاً فصل البيانات المشفرة إلى أجزاء نصية ASCII عادية (بما في ذلك + es متبوعة بشرطة) وكتل Unicode غير فارغة كما هو مذكور في قسم الوصف. بعد ذلك، يجب فك تشفير كل كتلة Unicode باتباع الإجراء التالي (باستخدام نتيجة مثال التشفير أعلاه كمثال لنا).
- عبّر عن كل رمز Base64 كسلسلة بتات يمثلها:AKMgIA → 000000 001010 001100 100000 001000 000000
- أعد تجميع البيانات الثنائية إلى مجموعات من ستة عشر بتًا، بدءًا من اليسار:000000 001010 001100 100000 001000 000000 → 0000000010100011 0010000000100000 0000
- إذا كانت هناك مجموعة غير مكتملة في النهاية تحتوي على أصفار فقط، فتجاهلها (إذا كانت المجموعة غير المكتملة تحتوي على أي واحدات، فإن الكود غير صالح):0000000010100011 0010000000100000
- كل مجموعة من 16 بت هي رقم Unicode (UTF-16) الخاص بالحرف ويمكن التعبير عنها بأشكال أخرى:0000 0000 1010 0011 ≡ 0x00A3 ≡ 163 10
علامة ترتيب البايت
علامة ترتيب البايتات (BOM) هي تسلسل بايتات خاص اختياري في بداية دفق أو ملف، يشير، دون أن يكون بيانات بحد ذاته، إلى الترميز المستخدم للبيانات اللاحقة؛ ويمكن استخدامه في حال عدم وجود بيانات وصفية تدل على الترميز. بالنسبة لنظام ترميز معين، فهي تمثل نقطة رمز يونيكود الخاصة بذلك النظام U+FEFF. [ 8 ]
على الرغم من أن ترتيب البايتات في ترميز UTF-7 عادةً ما يكون تسلسلًا ثابتًا من بايت واحد، إلا أنه قد يظهر أربعة اختلافات، وذلك لأن آخر بتين من البايت الرابع في ترميز UTF-7 U+FEFFينتميان إلى الحرف التالي ، مما ينتج عنه أربعة أنماط بتات محتملة، وبالتالي أربعة بايتات مختلفة محتملة في الموضع الرابع. انظر مدخل UTF-7 في جدول علامات ترتيب بايتات Unicode . [ 8 ]
حماية
يسمح ترميز UTF-7 بتمثيلات متعددة لنفس السلسلة النصية المصدرية. على وجه الخصوص، يمكن تمثيل أحرف ASCII كجزء من كتل Unicode. وبالتالي، إذا استُخدمت عمليات الهروب أو التحقق القياسية القائمة على ASCII على سلاسل نصية قد تُفسَّر لاحقًا على أنها UTF-7، فقد تُستخدم كتل Unicode لتمرير سلاسل نصية ضارة. وللحد من هذه المشكلة، ينبغي للأنظمة فك التشفير قبل التحقق، وتجنب محاولة الكشف التلقائي عن UTF-7.
يمكن خداع نظام الكشف عن ترميز الأحرف في بعض إصدارات متصفح إنترنت إكسبلورر لنظام ويندوز إن تي، بحيث يفسر الصفحة على أنها UTF-7. ويمكن استغلال ذلك في هجوم البرمجة النصية عبر المواقع ، حيث يمكن ترميز محددات وسوم HTML ، و، و ، على النحو التالي في UTF-7، وهو ما تسمح به معظم أدوات التحقق كنص عادي. [ 9 ]<>+ADw-+AD4-
يعتبر ترميز UTF-7 قديمًا، على الأقل بالنسبة لبرامج مايكروسوفت (.NET)، حيث تم تعطيل مسارات التعليمات البرمجية التي كانت تدعمه سابقًا عمدًا (لمنع المشكلات الأمنية) في .NET 5، في عام 2020. [ 1 ]
انظر أيضاً
مراجع
- 1 2 وارين، جينيفيف (1 نوفمبر 2020). "تغيير جذري: مسارات ترميز UTF-7 أصبحت قديمة" . مايكروسوفت ليرن . مايكروسوفت.
- ↑ "8.2.2.3. ترميز الأحرف" . معيار HTML 5.1 . اتحاد شبكة الويب العالمية (W3C).
- ↑ "12.2.3.3 ترميزات الأحرف" . معيار HTML الحي . WHATWG.
- ↑ "استخدام الأحرف الدولية في البريد الإلكتروني عبر الإنترنت" . اتحاد البريد الإلكتروني عبر الإنترنت . 1 أغسطس 1998. مؤرشف من الأصل في 7 سبتمبر 2015.
- ↑ "دليل التكوين" . وثائق دوفكوت . 8 فبراير 2023. القسم "إعدادات موقع البريد" . تم الاطلاع عليه في 28 فبراير 2023.
خزّن أسماء صناديق البريد على القرص باستخدام ترميز UTF-8 بدلاً من ترميز UTF-7 المعدل (mUTF-7).
- ↑ م. كريسبين (مارس 2003). بروتوكول الوصول إلى رسائل الإنترنت - الإصدار 4rev1 . مجموعة عمل الشبكة. doi : 10.17487/RFC3501 . RFC 3501 .مُلغى. القسم 5.1.3 "اتفاقية التسمية الدولية لصناديق البريد". أُلغي بموجب RFC 9051. تم تحديثه بموجب RFC 7817 و 8437 و 8474 و 4551 و 4469 و 5182 و 4466 و 5032 و 5738 . يُلغي RFC 2060.
في ترميز UTF-7 المُعدَّل، تُمثَّل أحرف US-ASCII القابلة للطباعة
،باستثناء
"&"، بنفسها... يُمثَّل الحرف "&" (0x26) بتسلسل الثمانيات "&-". جميع الأحرف الأخرى... مُمثَّلة في BASE64 المُعدَّل...
- ↑ ميلنيكوف، أليكسي؛ ليبا، باري (أغسطس 2021). بروتوكول الوصول إلى رسائل الإنترنت (IMAP) - الإصدار 4rev2 . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC9051 . ISSN 2070-1721 . RFC 9051 . المعيار المقترح. القسم 5.1. "تسمية صناديق البريد". يلغي RFC 3501. في IMAP4rev2 ،
يتم ترميز أسماء صناديق البريد باستخدام Net-Unicode (يختلف هذا عن IMAP4rev1).
- 1 2 هونرمان، توم (2 يناير 2021). "توضيح إرشادات استخدام BOM كتوقيع ترميز UTF-8" (ملف PDF) . اتحاد يونيكود . تم الاطلاع عليه في 17 يناير 2024 .
- ↑ سينغ، أ.؛ سينغ، ب.؛ جوزيف، هـ. (24 يناير 2008). "تحليل الثغرات الأمنية لبروتوكول HTTP". تحليل الثغرات الأمنية والدفاع عن الإنترنت . التطورات في أمن المعلومات. المجلد 37. نيويورك: سبرينغر. الصفحات 79-110 . doi : 10.1007/978-0-387-74390-5 . eISSN 2512-2193 . ISBN 978-0-387-74390-5.
- ترميز الأحرف
- تنسيقات تحويل يونيكود
