UTF-8(7)

الاسم
UTF-8 - ترميز يونيكود متعدد البايتات متوافق مع ASCII

الوصف
تشغل مجموعة محارف يونيكود 3.0 مساحة ترميز قدرها 16 بت. يتكون ترميز يونيكود الأكثر وضوحًا (المعروف باسم UCS-2) من تسلسل من كلمات بطول 16 بت. يمكن أن تحتوي هذه السلاسل -كجزء من العديد من محارف 16 بت- على بايتات مثل '\0' أو '/'، والتي لها معنى خاص في أسماء الملفات ومعاملات دالات مكتبة C الأخرى. بالإضافة إلى ذلك، تتوقع غالبية أدوات يونكس ملفات ASCII ولا يمكنها قراءة كلمات 16 بت كمحارف دون تعديلات جذرية. لهذه الأسباب، لا يعد UCS-2 ترميزًا خارجيًا مناسبًا ليونيكود في أسماء الملفات، وملفات النصوص، ومتغيرات البيئة، وما إلى ذلك. تشغل مجموعة المحارف العالمية (UCS) التابعة للمعيار ISO/IEC 10646، وهي مجموعة فائقة ليونيكود، مساحة ترميز أكبر -31 بت- ولترميز UCS-4 الواضح لها (تسلسل من كلمات 32 بت) المشكلات ذاتها.

لا يعاني ترميز UTF-8 ليونيكود و UCS من هذه المشكلات، وهو الطريقة الشائعة لاستخدام يونيكود في أنظمة التشغيل الشبيهة بيونكس.

  خصائص
يتمتع ترميز UTF-8 بالخصائص الجيدة التالية:

•   تُرمّز محارف UCS من 0x00000000 إلى 0x0000007f (محارف US-ASCII الكلاسيكية) ببساطة كبايتات من 0x00 إلى 0x7f (التوافق مع ASCII). وهذا يعني أن الملفات والسلاسل التي تحتوي فقط على محارف ASCII ذات 7 بتات لها الترميز نفسه في كل من ASCII و UTF-8.

•   تُرمّز جميع محارف UCS الأكبر من 0x7f كتسلسل متعدد البايتات يتكون فقط من بايتات في النطاق من 0x80 إلى 0xfd، لذا لا يمكن لأي بايت ASCII أن يظهر كجزء من محرف آخر ولا توجد مشكلات مع، على سبيل المثال، '\0' أو '/'.

•   يُحفظ ترتيب الفرز المعجمي لسلاسل UCS-4.

•   يمكن ترميز جميع رموز UCS الممكنة والبالغ عددها 2^31 باستخدام UTF-8.

•   لا تُستخدم البايتات 0xc0 و 0xc1 و 0xfe و 0xff أبدًا في ترميز UTF-8.

•   البايت الأول من تسلسل متعدد البايتات يمثل محرف UCS واحد غير تابع لـ ASCII يكون دائمًا في النطاق من 0xc2 إلى 0xfd ويشير إلى طول هذا التسلسل متعدد البايتات. جميع البايتات التالية في التسلسل متعدد البايتات تكون في النطاق من 0x80 إلى 0xbf. يتيح هذا إعادة مزامنة سهلة ويجعل الترميز عديم الحالة ومتينًا ضد البايتات المفقودة.

•   قد يصل طول محارف UCS المرمزة بـ UTF-8 إلى ستة بايتات، ومع ذلك لا يحدد معيار يونيكود أي محارف فوق 0x10ffff، لذا يمكن أن يصل طول محارف يونيكود إلى أربعة بايتات فقط في UTF-8.

  الترميز
تُستخدم تسلسلات البايتات التالية لتمثيل محرف. يعتمد التسلسل الذي سيُستخدم على رقم رمز UCS الخاص بالمحرف:

0x00000000 - 0x0000007F:
    0xxxxxxx

0x00000080 - 0x000007FF:
    110xxxxx 10xxxxxx

0x00000800 - 0x0000FFFF:
    1110xxxx 10xxxxxx 10xxxxxx

0x00010000 - 0x001FFFFF:
    11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

0x00200000 - 0x03FFFFFF:
    111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

0x04000000 - 0x7FFFFFFF:
    1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

تُملأ مواضع البتات xxx ببتات رقم رمز المحرف في التمثيل الثنائي، البت الأكثر أهمية أولاً (big-endian). يمكن فقط استخدام أقصر تسلسل ممكن متعدد البايتات يمكنه تمثيل رقم رمز المحرف.

يجب ألا تظهر قيم رموز UCS من 0xd800–0xdfff (بدائل UTF-16) بالإضافة إلى 0xfffe و 0xffff (لا-محارف UCS) في دفقات UTF-8 المتوافقة. وفقًا للمعيار RFC 3629 يجب عدم استخدام أي نقطة فوق U+10FFFF، مما يحد المحارف إلى أربعة بايتات.

  مثال
يُرمّز محرف يونيكود 0xa9 = 1010 1001 (علامة حقوق التأليف والنشر) في UTF-8 كـ

    11000010 10101001 = 0xc2 0xa9

والمحرف 0x2260 = 0010 0010 0110 0000 (رمز "لا يساوي") يُرمّز كـ:

    11100010 10001001 10100000 = 0xe2 0x89 0xa0

  ملاحظات التطبيق
على المستخدمين اختيار محلية UTF-8، على سبيل المثال باستخدام

    export LANG=en_GB.UTF-8

من أجل تفعيل دعم UTF-8 في التطبيقات.

يجب على برمجيات التطبيقات التي يجب أن تكون مدركة لترميز المحارف المستخدم أن تضبط المحلية دائمًا باستخدام، على سبيل المثال

    setlocale(LC_CTYPE, "")

ويمكن للمبرمجين حينها اختبار التعبير

    streq(nl_langinfo(CODESET), "UTF-8")

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

يجب على المبرمجين المعتادين على ترميزات البايت الواحد مثل US-ASCII أو ISO/IEC8859 أن يدركوا أن افتراضين كانا معمولاً بهما لم يعودا صالحين في محليات UTF-8. أولاً، البايت الواحد لا يقابل بالضرورة محرفًا واحدًا بعد الآن. ثانياً، بما أن محاكيات الطرفية الحديثة في وضع UTF-8 تدعم أيضًا المحارف الصينية واليابانية والكورية مزدوجة العرض بالإضافة إلى المحارف المركبة غير المتباعدة، فإن إخراج محرف واحد لا يقدم المؤشر بالضرورة بمقدار موضع واحد كما كان يفعل في ASCII. يجب استخدام دالات المكتبة مثل mbsrtowcs(3) و wcswidth(3) اليوم لعد المحارف ومواضع المؤشر.

تسلسل ESC الرسمي للتحويل من نظام ترميز ISO/IEC2022 (كما هو مستخدم مثلاً بواسطة طرفيات VT100) إلى UTF-8 هو ESC % G ("\x1b%G"). تسلسل العودة المقابل من UTF-8 إلى ISO/IEC2022 هو ESC % @ ("\x1b%@"). تسلسلات ISO/IEC2022 الأخرى (مثل تبديل مجموعتي G0 و G1) لا تنطبق في وضع UTF-8.

  الأمن
تتطلب معايير يونيكود و UCS أن يستخدم منتجو UTF-8 أقصر شكل ممكن، على سبيل المثال، إنتاج تسلسل من بايتين ببايت أول 0xc0 غير مطابق للمواصفات. أضاف معيار يونيكود 3.1 شرطاً يقضي بوجوب ألا تقبل البرامج المتوافقة الأشكال غير القصيرة في مدخلاتها. هذا لأسباب أمنية: إذا فُحصت مدخلات المستخدم بحثاً عن انتهاكات أمنية محتملة، فقد يفحص البرنامج نسخة ASCII فقط من "/../" أو ";" أو NUL ويغفل عن وجود طرق عديدة غير تابعة لـ ASCII لتمثيل هذه الأشياء في ترميز UTF-8 غير قصير.

  المعايير
ISO/IEC 10646-1:2000، يونيكود 3.1، RFC 3629، بلان 9.

انظر أيضًا
locale(1), nl_langinfo(3), setlocale(3), charsets(7), unicode(7)

ترجمة
تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي <zayed.alsaidi@gmail.com>

هذه الترجمة هي وثيقة مجانية؛ راجع رخصة جنو العامة الإصدار 3 (https://www.gnu.org/licenses/gpl-3.0.html) أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.

إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: kde-l10n-ar@kde.org.