نصائح حول ترحيل MySQL UTF/Unicode

Question

هل لدى أي شخص أي نصائح أو لحظات يجب الانتباه إليها عند محاولة ترحيل جداول MySQL من مجموعات الأحرف السويدية أو ascii الافتراضية غير الحساسة لحالة الأحرف إلى utf-8؟تسعى بعض المشاريع التي أشارك فيها إلى تحقيق تدويل أفضل وستكون قاعدة البيانات جزءًا مهمًا من هذا التغيير.

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

شكرا على اي مساعدة

Answer 1

بعض التلميحات:

• لك CHAR و VARCHAR ستستخدم الأعمدة ما يصل إلى 3 أضعاف مساحة القرص.(ربما لن تحصل على مساحة كبيرة على القرص للكلمات السويدية.)
• يستخدم SET NAMES utf8 قبل القراءة أو الكتابة إلى قاعدة البيانات.إذا لم تقم بذلك فسوف تحصل على أحرف مشوهة جزئيًا.

Answer 2

سأقوم بمراجعة المواقع/المقالات التالية للمساعدة في العثور على إجابة.

الحد الأدنى المطلق الذي يجب أن يعرفه كل مطور برامج بشكل مطلق وإيجابي عن Unicode ومجموعات الأحرف (بدون أعذار!) - جويل على البرامج

الأسئلة الشائعة حول UTF-8 وUnicode

حلقة هانسيلمينتس "فرز التدويل مع مايكل كابلان"

ولقد عثرت للتو أيضًا على منشور حول الموضوع بقلم Derek Sivers @ O'Reilly ONLamp Blog بينما كنت أكتب هذا. تحويل بيانات MySQL من latin1 إلى utf8 utf-8

Answer 3

احذر من قيود طول الفهرس.إذا تم تنظيم الجدول، فقل:

مفتاح Varchar (255) B varchar (255) ('A' ، 'B')

ستتجاوز الحد الأقصى البالغ 1000 بايت لأطوال المفاتيح.255+255 لا بأس بها، لكن 255*3 + 255*3 لن تعمل.

Answer 4

لك CHAR و VARCHAR ستستخدم الأعمدة ما يصل إلى 3 أضعاف مساحة القرص.

فقط إذا كانت مليئة باللاتينية 1 مع الترتيبات> 128.وبخلاف ذلك، فإن زيادة استخدام المساحة لـ UTF-8 تكون ضئيلة.

Answer 5

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