مع الاستخدام الواسع النطاق لمجموعات الأحرف متعددة البايت، فإن نسبة عالية جدًا من المبرمجين الناطقين باللغة الإنجليزية في تطوير البرمجيات لا يعرفون الكثير عن الأحرف متعددة البايت، وهذا هو السبب في أن العديد من الثغرات الأمنية في السنوات الأخيرة هي السبب. يتحدث مؤلف هذه المقالة عن آرائه الخاصة حول دور بنية مجموعة أحرف MySQL. في الأشهر القليلة الماضية، في كل مرة أستخدم فيها MySQL، أفكر دائمًا تقريبًا: هل بنية مجموعة الأحرف الهرمية الحالية في MySQL مفيدة حقًا؟
معالجة مجموعة أحرف MySQL
إرسال الطلب
العميل (character_set_client)=》اتصال قاعدة البيانات (character_set_connection)=》التخزين (الجدول، العمود)
طلب العودة
التخزين (الجدول، العمود)=》اتصال قاعدة البيانات (character_set_connection)=》العميل (character_set_results)
في كل عقدة غير أولية، يتم تنفيذ عملية تحويل مجموعة الأحرف من العقدة السابقة إلى العقدة الحالية. على سبيل المثال، خذ بعين الاعتبار البيئة التالية:
◆ Character_set_connection utf-8
◆ Character_set_results gbk
◆ Character_set_client gb2312
◆ يوجد جدول A، ومجموعات أحرف الحقل كلها BIG5
عند إرسال طلب، يتم تحويل البيانات أولاً من gbk إلى utf-8، ثم إلى BIG5، ثم تخزينها.
عند إعادة الطلب، يتم تحويل البيانات أولاً من BIG5 إلى utf-8، ثم إلى gb2312، ثم إرسالها إلى العميل.
دور الهندسة المعمارية
1. السماح للعملاء المختلفين بالحصول على مجموعات أحرف مختلفة. أحد الأمثلة النموذجية هو أن لدي موقع UTF-8، وهو عميل لديه عميل مجموعة أحرف من UTF-8. في الوقت نفسه، قد أحتاج إلى قراءة وكتابة قاعدة البيانات على محطة gbk، وهو عميل آخر، ولكن مجموعة الأحرف الخاصة به هي gbk.
2. عند تشغيل نظام الملفات من خلال قاعدة البيانات، تحتاج إلى تحويل مسار الملف إلى مجموعة الأحرف الخاصة بنظام الملفات. على سبيل المثال، عميلي هو gbk ونظام ملفات الخادم هو utf-8. العملية "/A Slice/Rina.rmvb"، من بين البيانات المرسلة، تختلف بيانات "الشريحة" عن الخادم. في هذا الوقت، يجب أن تكون هناك طريقة لتحويل "شريحة" GBK إلى utf-8. هنا يقدم MySQL شيئًا يسمى Character_filesystem لإنجاز هذا.
بخلاف ذلك، لا أستطيع التفكير في أي استخدامات أخرى في الوقت الراهن. لكن فكر في الأمر جيدًا، هل نحتاج حقًا إلى هذا النوع من العلاج؟ تأمل العديد من مواقع الويب أن تظهر بياناتها كما يحلو لها. هناك حالتان أخريان هنا.
1. أتمنى أن أتمكن من فرز أو إجراء مثل هذه العمليات بناءً على البيانات. لنتحدث عن الفرز أولاً بالنسبة للحقول التي تحتوي على اللغة الصينية، فإن مفهوم الفرز بناءً على مجموعات الأحرف غير مجدي. عند فرز اللغة الصينية المبسطة، فأنت تريد عمومًا الفرز حسب نظام Pinyin. لم أفهم حقًا عملية التحقق في MySQL، ولكن انطلاقًا من البرامج التي تعاملت معها، إذا كان هذا النوع من الفرز مطلوبًا، فسيتم إنشاء حقل خصيصًا لتخزين نظام Pinyin للفرز. هناك أيضًا أحرف متعددة الألحان في نظام Pinyin. إذا كان UTF-8، فهناك أيضًا موقف حيث يتم مشاركة نطاق معين من اللغة الصينية بين الصين واليابان وكوريا الجنوبية في نفس الوقت. ليس من السهل تنفيذه، لذلك لا يجب على GBK أو مجموعة اختيار UTF-8 الخاصة بـ MySQL تنفيذ Pinyin. أجرؤ على القول أن معظم مواقع الويب في الصين التي تستخدم MySQL تستخدم الآن مجموعة تحقق لا تعدو أن تكون مجرد نوع بايت. مع فرز البايت، ليست هناك حاجة لاستخدام أي مجموعة أحرف على الإطلاق. لذلك، بالنسبة للمواقع الصينية، ليس للتحقق من أحرف MySQL أي معنى في الفرز.
ولكن من حيث العملية المشابهة، فإن لها معنى قليل. على سبيل المثال، إذا أحببت '%a%'، فمن الممكن مطابقة حرف صيني يحتوي على "a" في جزء معين. بالطبع، لن يتم مواجهة هذا الموقف في ظل UTF-8، لأن تنسيق تخزين UTF-8 يعني أن a يمكن أن يكون فقط، ولا يمكن أن يكون جزءًا من حرف متعدد البايت. ولكن قد تحدث هذه المشكلة في مجموعات الأحرف الأخرى. وفي النهاية، يصبح الإعجاب مثل الترتيب، مما يجعل التحقق بلا معنى. إِغماء.
2. إذا لم تكن هناك حاجة لفرز البيانات أو البحث عن نص كامل، فيرجى التوقف عن استخدام char وvarchar والنص وما شابه. ثنائي، varbinary، BLOB هي الاختيارات الصحيحة. لن يقوم الثنائي وما شابه بإجراء تحويل مجموعة الأحرف عند التخزين والاسترداد، ولكن عند الفرز، يتم فرزها فقط وفقًا للمحتوى الثنائي، وبالتالي فإن الكفاءة أعلى بكثير من كفاءة char وvarchar والنص.
في هذه الحالة، ليست هناك حاجة لمجموعة الأحرف. ومع ذلك، وفقًا لبنية MySQL الحالية، ستظل عمليات مجموعة الأحرف بين العميل والاتصال تتجاهل أنواع الحقول.
اذكر أيضًا إعداد مجموعة الأحرف في PHP. الرجاء التوقف عن استخدام عبارات مثل mysql_query("تعيين أسماء utf8"). mysql_set_charset() هي الطريقة الأكثر اكتمالا لإعداد مجموعة الأحرف. يحتوي الأخير على إعداد واحد أكثر من الأول، وهو تعيين عضو مجموعة الأحرف في بنية MySQL. يلعب متغير العضو هذا دورًا مهمًا جدًا في الهروب، خاصة بالنسبة لتنسيقات التشفير مثل GBK التي تستخدم "" كجزء من الحرف. إذا كنت تستخدم mysql_query("setnames XXX") فقط، ففي بعض مجموعات الأحرف، ستكون هناك ثغرات أمنية كبيرة، مما يتسبب في أن يصبح mysql_real_escape_string غير آمن مثل addlashes.
-