(والأمر لا يتعلق بالحجم)

إليوت رستي هارولد
تم النشر في 25/09/2013

خدمة خريطة الموقع جوجلأحدثت مؤخرًا ضجة كبيرة في مجتمع XML عندما بدأت في المطالبة بنشر جميع خرائط الموقع حصريًا بتنسيق UTF-8 Unicode. جوجل لا تسمح لك حتى باستخدام البديل ترميزات يونيكود(على سبيل المثال UTF-16)، ناهيك عن الترميزات غير Unicode مثل ISO-8859-1. مع نقطة فنيةهذا يعني بشكل أساسي أن Google تستخدم نوعًا من محلل XML غير المتوافق مع المعايير، نظرًا لأن توصية XML تنص على أن "جميع معالجات XML يجب أن تقبل ترميز UTF-8 وUTF-16 Unicode 3.1." ومع ذلك، هل هذه حقا مشكلة؟

UTF-8 متاح للجميع

يعد تعدد الاستخدامات هو السبب الأول والأكثر إلحاحًا لاختيار UTF-8. هذا التشفير قادر على العمل مع أي نظام كتابة مستخدم اليوم تقريبًا. لا تزال هناك بعض الفجوات، لكنها أصبحت نادرة بشكل متزايد ويجري حاليًا سدها. أنظمة الكتابة التي ظلت مكشوفة، في معظمها، لم يتم تنفيذها أيضًا في أي مجموعة أحرف أخرى، وحتى إذا تم تنفيذها، فهي غير متوفرة في XML. في أفضل سيناريويتم تنفيذها عن طريق اختراق الخطوط المبنية على مجموعات الأحرف أحادية البايت مثل Latin-1. سيظهر الدعم الحقيقي لأنظمة الكتابة النادرة هذه أولاً في Unicode (وربما حصريًا في Unicode وليس في أي مكان آخر).

ومع ذلك، هذه ليست سوى واحدة من الحجج لصالح Unicode. لماذا تختار UTF-8 بدلاً من UTF-16 أو ترميزات Unicode الأخرى؟ أحد الأسباب الأكثر وضوحًا هو الدعم الواسع النطاق أدوات. تقريبًا أي محرر مهم يمكن استخدامه مع XML يعمل مع UTF-8، بما في ذلك JEdit وBBEdit وEclipse وemacs وحتى ويندوز المفكرة(المفكرة). لا يوجد ترميز Unicode آخر يتمتع بمثل هذا الدعم الشامل للأدوات بين أدوات XML والأدوات المساعدة غير XML.

في بعض الحالات (مثل BBEdit وEclipse)، لا يكون UTF-8 هو مجموعة الأحرف الافتراضية. لقد حان الوقت لتغيير الإعداد الافتراضي - يجب أن تأتي جميع الأدوات مع UTF-8 كالتشفير الافتراضي. وإلى أن يحدث ذلك، سنظل في مستنقع من الملفات غير المتوافقة وظيفيًا والتي تفسد أثناء انتقالها عبر الحدود الوطنية والمنصية واللغوية. ومع ذلك، حتى يكون الترميز الافتراضي لجميع البرامج هو UTF-8، يمكنك بسهولة تغيير الإعدادات الافتراضية بنفسك. على سبيل المثال، في Eclipse، في لوحة General/Editors الموضحة في الشكل 1، يمكنك تحديد أن جميع الملفات يجب أن تكون بتشفير UTF-8. قد تلاحظ أن Eclipse "يريد" تثبيت MacRoman افتراضيًا؛ ومع ذلك، إذا سمحت بذلك، فلن يتم تجميع ملفاتك عند إرسالها إلى المبرمجين الذين يستخدمون أجهزة الكمبيوتر قيد التشغيل نظام مايكروسوفت® Windows® وأي أجهزة كمبيوتر خارج أمريكا وأوروبا الغربية.

الشكل 1. تغيير مجموعة الأحرف الافتراضية في Eclipse

بالطبع، لكي يعمل UTF-8، يجب على المطورين الذين تشارك الملفات معهم أيضًا استخدام UTF-8؛ ولكن هذا لا ينبغي أن يكون مشكلة. على عكس MacRoman، لا يقتصر UTF-8 على عدد قليل من أنظمة الكتابة ومنصة واحدة أقل استخدامًا. UTF-8 يعمل بشكل جيد لأي شخص والجميع. يختلف الوضع تمامًا مع MacRoman وLatin-1 وSJIS وغيرها من مجموعات الشخصيات الوطنية التقليدية المختلفة.

يعمل UTF-8 أيضًا بشكل أفضل مع الأدوات التي لا تتوقع بيانات متعددة البايت. تحتوي تنسيقات Unicode الأخرى (مثل UTF-16) عادةً على العديد من البايتات الخالية. تفسر العديد من الأدوات هذه البايتات على أنها نهاية الملف أو بعض المحددات الخاصة الأخرى، مما يؤدي إلى عواقب غير متوقعة وغير متوقعة وغالبًا ما تكون غير سارة. على سبيل المثال، إذا تم تحميل بيانات UTF-16 "ببساطة" في سلسلة C، فقد ينتهي الأمر بالسلسلة مقطوعة عند البايت الثاني من حرف ASCII الأول. تحتوي ملفات UTF-8 فقط على أصفار تحتاج في الواقع إلى أن تكون أصفارًا. بالطبع، لا يستحق اختيار هذه الأدوات البسيطة لمعالجة مستندات XML. ومع ذلك، غالبًا ما تنتهي المستندات بهذا الشكل أماكن غير عاديةالأنظمة التقليدية حيث لم يأخذ أحد في الاعتبار أو يفهم عواقب "سكب النبيذ الجديد في زقاق النبيذ القديمة". في الأنظمة غير المألوفة مع Unicode وXML، تقل احتمالية حدوث المشكلات عند استخدام UTF-8 مقارنة بالعمل مع UTF-16 أو ترميزات Unicode الأخرى.

ماذا تقول المواصفات

كان XML هو المعيار الرئيسي الأول الذي يدعم UTF-8 بشكل كامل، ولكنه كان مجرد بداية الاتجاه. توصي هيئات المعايير بشكل متزايد باستخدام UTF-8. على سبيل المثال، كانت عناوين URL التي تحتوي على أحرف غير ASCII تمثل مشكلة مستعصية على الإنترنت لفترة طويلة. قد يفشل عنوان URL الذي يتم تشغيله على جهاز كمبيوتر يحتوي على أحرف غير ASCII عند تحميله عليه منصة ماكوالعكس صحيح. تم حل هذه المشكلة مؤخرًا فقط عندما قام الكونسورتيوم في جميع أنحاء العالماتفق الويب (W3C) وفريق عمل هندسة الإنترنت (IETF) على أن جميع عناوين URL سيتم تشفيرها فقط بتنسيق UTF-8 وليس أي تشفير آخر.

كلا المنظمتين (W3C وIETF) مؤخراأصبحنا أكثر إصرارًا على اختيار UTF-8 بشكل عام، وأحيانًا باعتباره الترميز الوحيد. في الوثيقة نموذج شخصية W3C للعالم شبكة واسعة 1.0: الأساسيات(W3C Character Model for the World Wide Web 1.0: Basics) ينص على ما يلي: "عند الحاجة إلى أي ترميز أحرف لا لبس فيه، يجب استخدام ترميز الأحرف UTF-8 أو UTF-16 أو UTF-32. ترميز US-ASCII متوافق مع UTF-8 (سلسلة US-ASCII هي أيضًا سلسلة UTF-8، انظر )، لذلك يمكن استخدام UTF-8 إذا كان التوافق بين US-ASCII مطلوبًا." من الناحية العملية، يعد التوافق بين US-ASCII مفيدًا للغاية لدرجة أنه أصبح متطلبًا عمليًا. يشرح W3C بحكمة ما يلي: "في حالات أخرى، مثل واجهات برمجة التطبيقات، قد يكون UTF-16 أو UTF-32 أكثر ملاءمة. أسباب محتملةيتضمن اختيار أحد هذه الترميزات كفاءة المعالجة الداخلية وقابلية التشغيل البيني مع العمليات الأخرى."

يمكنني شراء الحجة حول كفاءة المعالجة الداخلية. على سبيل المثال، التمثيل الداخليخطوط لغة جافا™ يعتمد على UTF-16، الذي يعمل على تسريع الفهرسة بشكل كبير في السلسلة. لكن كود جافالا يُظهر أبدًا تمثيله الداخلي للبرامج التي يتواصل معها. بدلاً من ذلك، يتم استخدام java.io.Writer للاتصالات الخارجية، ويتم تحديد مجموعة الأحرف بشكل صريح. عند اتخاذ هذا الاختيار، يوصى بشدة باستخدام UTF-8.

تعتبر متطلبات IETF أكثر وضوحًا. في الوثيقة سياسة مجموعة الأحرف الخاصة بـ IETF(سياسة مجموعة أحرف IETF) تنص بوضوح على ما يلي:

يجب أن تكون البروتوكولات قادرة على استخدام مجموعة أحرف UTF-8 لجميع النصوص، والتي تتكون من مجموعة أحرف ISO 10646 المشفرة مع نظام ترميز أحرف UTF-8 المحدد في الملحق R (المنشور في التعديل 2).

قد تحدد البروتوكولات بالإضافة إلى ذلك كيفية استخدام مجموعات أحرف أخرى أو أنظمة ترميز أحرف أخرى لـ ISO 10646، مثل UTF-16، ولكن الفشل في استخدام UTF-8 يعد انتهاكًا لهذه السياسة؛ سيتطلب مثل هذا الانتهاك شكلاً من أشكال إجراءات الانحراف (القسم 9) مع وجود مبرر واضح ومقنع في وثيقة مواصفات البروتوكول قبل الدخول في مسار المعايير أو المضي قدمًا فيه.

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

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

اللغات الصينية واليابانية والكورية

أحد المفاهيم الخاطئة الشائعة هو أن UTF-8 هو تنسيق ضغط. وهذا خطأ جوهري. تشغل الأحرف الموجودة في نطاق ASCII فقط نصف المساحة في UTF-8 التي تشغلها في بعض ترميزات Unicode الأخرى، وخاصة UTF-16. ومع ذلك، تتطلب بعض الأحرف مساحة أكبر تصل إلى 50% ليتم ترميزها بتنسيق UTF-8، خاصة الأحرف الصينية واليابانية والكورية (CJK).

ولكن حتى عندما تقوم بتشفير XML CJK إلى UTF-8، فإن الزيادة الفعلية في الحجم عبر UTF-16 ربما لن تكون بهذه الأهمية. على سبيل المثال، مستند XML على صينىيحتوي على العديد من أحرف ASCII مثل<, >، &، =، "،"، ومسافة. تشغل كل هذه الأحرف مساحة أقل في UTF-8 مقارنة بـ UTF-16. يختلف المقدار الدقيق لنسبة الضغط أو التوسيع من مستند إلى آخر، ولكن على أية حال من غير المرجح أن يكون الفرق ملحوظًا جدًا.

أخيرًا، تجدر الإشارة إلى أن النصوص الإيديوغرافية مثل الصينية واليابانية تميل إلى أن تكون "اقتصادية" من حيث عدد الأحرف مقارنة بالنصوص الأبجدية مثل اللاتينية والسيريلية. يتطلب بعض الأعداد المطلقة الكبيرة من هذه الأحرف ثلاثة بايتات أو أكثر لكل حرف ليتم تمثيلها بشكل كامل من هذه الأنظمةحروف؛ وهذا يعني أنه يمكن التعبير عن نفس الكلمات والجمل باستخدام عدد أصغرأحرف أكثر من لغات مثل الإنجليزية والروسية. على سبيل المثال، الرسم الياباني للشجرة هو æ¨. (يبدو قليلا مثل الخشب). يحتل هذا الرسم البياني ثلاث بايتات في UTF-8، بينما تتكون الكلمة الإنجليزية "tree" من أربعة أحرف وتشغل أربعة بايتات. الرسم الياباني للبستان هو æ- (شجرتان بجانب بعضهما البعض). كما أنها تشغل ثلاث بايتات في UTF-8، في حين أن الكلمة الإنجليزية "grove" تتكون من خمسة أحرف وتشغل خمس بايتات. لا يزال حجم الرسم التوضيحي الياباني æ £® (ثلاث أشجار) ثلاثة بايت فقط. والكلمة الإنجليزية المكافئة "غابة" تأخذ ستة.

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

مصداقية

المثير الحقيقي هو أن UTF-8، حسب تصميمه، هو تنسيق أكثر موثوقية وأسهل في التفسير من أي ترميز نص آخر تم تطويره قبل UTF-8 أو بعده. أولاً، على عكس UTF-16، لا يعاني UTF-8 من مشكلات endianness. UTF-8 مع المباشر و في ترتيب عكسيالبايتات متطابقة لأن UTF-8 محدد بالبايتات 8 بت بدلاً من الكلمات ذات 16 بت. لا يحتوي UTF-8 على أي غموض في ترتيب البايت والذي يجب حله باستخدام علامات ترتيب البايت أو الاستدلال الأخرى.

أكثر من ذلك خاصية مهمة UTF-8 عديم الجنسية. كل بايت من دفق أو تسلسل UTF-8 فريد من نوعه. في UTF-8، أنت تعرف دائمًا مكانك - أي أنه يمكنك أن تعرف على الفور من بايت واحد ما إذا كان حرفًا أحادي البايت، أو البايت الأول من حرف مزدوج البايت، أو البايت الثاني من حرف مزدوج البايت الحرف، أو البايت الثاني أو الثالث أو الرابع من حرف مكون من ثلاثة أو أربعة بايت. (هذا ليس كل الاحتمالات بأي حال من الأحوال، ولكن المعلومات المقدمة ستساعدك في الحصول عليها فكرة عامة). في UTF-16، لا تعرف دائمًا ما إذا كانت البايتة "0x41" تمثل الحرف "A". في بعض الأحيان يكون هذا صحيحا، وأحيانا لا يكون كذلك. يجب أن يكون لديك ما يكفي من تتبع الحالة لمعرفة مكانك في التدفق. إذا تم فقدان أي بايت واحد، فستكون جميع البيانات اللاحقة من تلك النقطة فصاعدًا تالفة. في UTF-8، يتم اكتشاف البايتات المفقودة أو التالفة على الفور ولا تفسد البيانات الأخرى.

ترميز UTF-8 ليس مثاليًا لجميع التطبيقات. قد تؤدي التطبيقات التي تتطلب وصولاً عشوائيًا إلى فهارس محددة داخل المستند بشكل أسرع عند استخدام بعض الترميز ذي العرض الثابت مثل UCS2 أو UTF-32. (UTF-16 هو ترميز متغير العرض عند أخذ الأزواج البديلة في الاعتبار). ومع ذلك، معالجة XML ليست واحدة من تلك التطبيقات. تتطلب مواصفات XML ذلك بالفعل الموزعونبدأ التحليل من البايت الأول وثيقة XMLواستمر في التحليل حتى النهاية، وجميع المحللين الحاليين يعملون بهذه الطريقة. إن تسريع الوصول العشوائي لن يساعد في معالجة XML بأي شكل من الأشكال؛ لذلك، على الرغم من أن هذا يمكن أن يصبح واحدًا و أسباب وجيهةإن استخدام أي ترميز آخر في قاعدة بيانات أو نظام آخر لا يرتبط بـ XML.

خاتمة

في عالم يتسم بالتدويل بشكل متزايد، حيث أصبحت الحدود اللغوية والسياسية غير واضحة بشكل متزايد كل يوم، أصبحت مجموعات الشخصيات المحلية غير قابلة للاستخدام. Unicode هي مجموعة الأحرف الوحيدة التي يمكن استخدامها في جميع اللغات في العالم. UTF-8 هو تطبيق Unicode مناسب يقوم بما يلي:

• تتميز بدعم واسع للأداة، بما في ذلك أفضل التوافقمع الأنظمة التقليديةأسكي؛
• عملية بسيطة وفعالة.
• مقاومة لفساد البيانات؛
• منصة مستقلة.

حان الوقت للتوقف عن الجدال حول مجموعات الأحرف والتشفيرات - اختر UTF-8 وأنهِ النقاش.

من الناحية النظرية، كان الحل لهذه المشاكل موجودا منذ فترة طويلة. تسمى يونيكود (يونيكود). يونيكودهو جدول ترميز يتم فيه استخدام 2 بايت لتشفير كل حرف، أي. 16 بت. بناءً على هذا الجدول، يمكن ترميز N=2 16 =65,536 حرفًا.

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

ولأغراض أكاديمية، تمت إضافة العديد من الخطوط التاريخية، بما في ذلك: اليونانية القديمة، والهيروغليفية المصرية، والكتابة المسمارية، وكتابة المايا، والأبجدية الأترورية.

يوفر Unicode نطاقًا واسعًا من الرموز والصور التوضيحية الرياضية والموسيقية.

يوجد نطاقان من التعليمات البرمجية للأحرف السيريلية في Unicode:

السيريلية (#0400 - #04FF)

الملحق السيريلي (#0500 - #052F).

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

لذلك، في الممارسة العملية الآن، أصبح تمثيل Unicode UTF-8 (تنسيق تحويل Unicode) أكثر شيوعًا. يوفر UTF-8 أفضل توافق مع الأنظمة التي تستخدم أحرف 8 بت. النص الذي يتكون فقط من أحرف برقم أقل من 128 يتحول إلى نص عادي عند كتابته بترميز UTF-8 نص أسكي. يتم تمثيل أحرف Unicode الأخرى كتسلسلات يتراوح طولها من 2 إلى 4 بايت. بشكل عام، نظرًا لأن الأحرف الأكثر شيوعًا في العالم، وهي الأبجدية اللاتينية، لا تزال تشغل بايتًا واحدًا في UTF-8، فإن هذا التشفير أكثر اقتصادا من Unicode الخالص.

في مشفرة الانجليزية النصيتم استخدام 26 حرفًا فقط من الأبجدية اللاتينية و6 علامات ترقيم أخرى. في هذه الحالة، يمكن ضمان ضغط النص الذي يحتوي على 1000 حرف دون فقدان المعلومات بالحجم:

قاموس Ellochka - "أكلة لحوم البشر" (شخصية في رواية "الاثني عشر كرسيًا") يتكون من 30 كلمة. كم عدد البتات الكافية لتشفير مفردات Ellochka بأكملها؟ الخيارات: 8، 5، 3، 1.

1. وحدات حجم البيانات وسعة الذاكرة: كيلو بايت، ميجا بايت، جيجا بايت...

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

حجم البيانات (V) هو عدد البايتات المطلوبة لتخزينها في ذاكرة وسيط التخزين الإلكتروني.

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

ومع ذلك، فإن البايت هو وحدة صغيرة من حجم البيانات؛ أما الوحدات الأكبر حجمًا فهي كيلو بايت، وميجابايت، وجيجابايت، وتيرابايت...

يجب أن نتذكر أن البادئات "كيلو"، "ميجا"، "جيجا"... ليست موجودة في هذه الحالةعدد عشري. إذن "الكيلو" في كلمة "كيلوبايت" لا يعني "الألف"، أي. لا يعني "10 3". قليل - وحدة ثنائيةولهذا السبب في علوم الكمبيوتر من السهل استخدام وحدات القياس التي تكون مضاعفات الرقم "2" بدلاً من الرقم "10".

1 بايت = 2 3 = 8 بت، 1 كيلو بايت = 2 10 = 1024 بايت.في الثنائية 1 كيلو بايت = & 10000000000 بايت.

أولئك. "الكيلو" هنا يشير إلى الرقم الأقرب إلى الألف، وهو أيضًا من قوة الرقم 2، أي. وهو رقم "مستدير" في النظام الثنائيالحساب

الجدول 10.

تسمية	تعيين	القيمة بالبايت
كيلو بايت
ميغا بايت		2 10 كيلو بايت = 2 20 ب
جيجابايت		210 ميجابايت = 230 ب
تيرابايت		2 10 جيجا بايت = 2 40 ب	1 099 511 627 776 ب

ويرجع ذلك إلى حقيقة أن وحدات قياس الحجم والقدرة وسائط التخزينهي مضاعفات العدد 2 وليست مضاعفات العدد 10، معظم المسائل في هذا الموضوع تكون أسهل في الحل عندما يتم تمثيل القيم التي تظهر فيها كقوى للعدد 2. خذ مثالا مهمة مماثلةوحلها :

يخزن الملف النصي 400 صفحة من النص. تحتوي كل صفحة على 3200 حرف. إذا تم استخدام ترميز KOI-8 (8 بت لكل حرف)، فسيكون حجم الملف:

حل

تحديد العدد الإجمالي للأحرف في ملف نصي. في هذه الحالة، نحن نمثل الأعداد التي هي من مضاعفات قوى العدد 2 كقوى للعدد 2، أي. بدلاً من 4، اكتب 2 2، وما إلى ذلك. يمكن استخدام الجدول 7 لتحديد الدرجة.

الشخصيات.

2) وفقًا لشروط المشكلة، يشغل الحرف الواحد 8 بتات، أي 8 بتات. 1 بايت => يستغرق الملف 2 7 * 10000 بايت.

3) 1 كيلو بايت = 2 10 بايت => حجم الملف بالكيلوبايت هو:

.

كم عدد البتات الموجودة في كيلو بايت واحد؟

&10000000000000.

ما هو 1 ميغابايت يساوي؟

1024 بايت؛

1024 كيلو بايت؛

• 1000000 بايت.

كم عدد البتات الموجودة في رسالة ربع كيلو بايت؟ الخيارات: 250، 512، 2000، 2048.

مقدار ملف نصي 640 كيلو بايت. يحتوي الملف على كتاب يتم كتابته في المتوسط 32 خطوط على الصفحة وبواسطة 64 حرف في سطر. كم عدد صفحات الكتاب: 160، 320، 540، 640، 1280؟

يتم الاحتفاظ بملفات الموظفين 8 ميجا بايت. يحتوي كل واحد منهم 16 الصفحات ( 32 خطوط بواسطة 64 حرف في سطر). عدد الموظفين في المنظمة: 256؛ 512؛ 1024؛ 2048؟

هذا المنشور مخصص لأولئك الذين لا يفهمون ما هو UTF-8، ولكنهم يريدون فهمه، وغالبًا ما تغطي الوثائق المتاحة هذه المشكلة على نطاق واسع جدًا. سأحاول أن أصف الأمر هنا بالطريقة التي أود أن يخبرني بها أحد من قبل. نظرًا لأنني كثيرًا ما كنت أعاني من فوضى في رأسي بشأن UTF-8.

بعض القواعد البسيطة

1. لذا فإن UTF-8 عبارة عن غلاف لـ Unicode. هذا ليس ترميز أحرف منفصلاً، بل هو Unicode "ملفوف". من المحتمل أنك تعرف أو سمعت عن تشفير Base64 - حيث يمكنه تحويل البيانات الثنائية إلى أحرف قابلة للطباعة. حسنًا، UTF-8 هو نفس Base64 لـ Unicode مثل Base64 للبيانات الثنائية. هذا الوقت. إذا فهمت هذا، فسيصبح الكثير واضحا. وهو مثل Base64 يعتبر يحل مشكلة التوافق في الأحرف (تم اختراع Base64 للبريد الإلكتروني، وذلك لنقل الملفات عن طريق البريد، حيث تكون جميع الأحرف قابلة للطباعة)
2. علاوة على ذلك، إذا كان الكود يعمل مع UTF-8، فلا يزال بداخله يعمل مع ترميزات Unicode، أي أنه في مكان ما عميقًا توجد جداول أحرف لأحرف Unicode بالضبط. صحيح، قد لا يكون لديك جداول أحرف Unicode إذا كنت تحتاج فقط إلى حساب عدد الأحرف الموجودة في السطر، على سبيل المثال (انظر أدناه)
3. تم تصميم UTF-8 بحيث يمكن للبرامج القديمة وأجهزة الكمبيوتر الحالية العمل بشكل طبيعي مع أحرف Unicode، كما هو الحال مع الترميزات القديمة مثل KOI8 وWindows-1251 وما إلى ذلك. في UTF-8 لا توجد بايتات بأصفار، كل البايتات موجودة تكون إما من 0x01 - 0x7F، مثل ASCII العادي، أو 0x80 - 0xFF، والتي تعمل أيضًا ضمن البرامج المكتوبة بلغة C، تمامًا كما تعمل مع أحرف غير ASCII. صحيح ل العملية الصحيحةبالرموز، يجب أن يعرف البرنامج جداول Unicode.
4. أي شيء يحتوي على البت السابع الأكثر أهمية في البايت (عد البتات من 0) UTF-8 هو جزء من التدفق المشفر Unicode.

UTF-8 من الداخل

إذا كنت تعرف نظام البت، فإليك ما يلي تذكير موجزبترميز UTF-8:

يبدأ البايت الأول من حرف Unicode في UTF-8 ببايت حيث يكون البت السابع دائمًا واحدًا، والبت السادس دائمًا واحدًا. علاوة على ذلك، في البايت الأول، إذا نظرت إلى البتات من اليسار إلى اليمين (السابع والسادس وما إلى ذلك حتى الصفر)، فهناك عدد من الوحدات يساوي عدد البايتات، بما في ذلك الأولى، المستخدمة لترميز حرف Unicode واحد. تسلسل الآحاد ينتهي بصفر. وبعد ذلك تأتي أجزاء حرف Unicode نفسه. تقع البتات المتبقية من حرف Unicode في البايت الثاني أو حتى الثالث (ثلاثة كحد أقصى، راجع السبب - انظر أدناه). تبدأ وحدات البايت المتبقية، باستثناء الأولى، دائمًا بـ "10" ثم 6 بتات من الجزء التالي من حرف Unicode.

مثال

على سبيل المثال: هناك بايتات 110 10000 والثانية 10 011110 . يبدأ الأول بـ "110" - وهذا يعني أنه اثنان في واحد - سيكون هناك بايتان من دفق UTF-8، والبايت الثاني، مثل كل البايتات الأخرى، يبدأ بـ "10". وهاتان البايتتان تشفران حرف Unicode، الذي يتكون من 10100 بت من القطعة الأولى + 101101 من الثانية، فتبين -> 10000011110 -> 41هـبالنظام الست عشري، أو ش+041Eفي كتابة تدوينات Unicode. هذا هو رمز O الروسي الكبير.

ما هو الحد الأقصى للبايت لكل حرف؟

دعونا نرى أيضًا عدد وحدات البايت القصوى التي يستغرقها UTF-8 لتشفير 16 بت من ترميز Unicode. يمكن دائمًا أن تحتوي البايتات الثانية والإضافية على 6 بتات كحد أقصى. هذا يعني أنك إذا بدأت بالبايتات النهائية، فإن البايتتين ستنتقلان بالضبط (الثانية والثالثة)، ويجب أن تبدأ البايتة الأولى بـ "1110" من أجل تشفير الثلاثة. وهذا يعني أن البايت الأول في هذا الإصدار يمكنه على الأكثر تشفير أول 4 بتات من حرف Unicode. اتضح 4 + 6 + 6 = 16 بايت. اتضح أن UTF-8 يمكن أن يحتوي على 2 أو 3 بايت لكل حرف Unicode (لا يمكن للمرء ذلك، لأنه لا توجد حاجة لتشفير 6 بت (8 - 2 بت '10') - سوف يفعلون ذلك حرف ASCII. ولهذا السبب لا يمكن أبدًا أن يبدأ البايت الأول من UTF-8 بـ "10").

خاتمة

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