it-swarm.asia

SQL Server 2005/2008 UTF-8 ترتيب / محارف

لا يمكنني العثور على خيار (خيارات) مباشرةً لتعيين UTF-8 Rellated Collations/Charsets في SQL Server 2005/2008 ، وهو نفس ما يمكن تعيينه في مشغلات SQL أخرى ، ولكن في SQL Server 2005/2008 هناك فقط نسخ لاتينية و SQL.

هل هناك خيار لفرض/تثبيت هذه النسخ/المجموعات في محرك SQL Server (لكل من الإصدار) 2005/2008 على Win2008 OS

16
mKorbel

لا ، ليس هناك. لا يدعم SQL Server UTF-8.

تحتاج إلى تعريف أعمدتك على أنها nvarchar/nchar إذا كنت تريد بيانات unicode. ملاحظة ، يخزن داخليًا SQL Server هذا كملف UCS-2.

لاحظ أن هذا قد طلب ben من MS on Connect وهناك مقالة KB قديمة . وبعض المعلومات على هذه المدونة أيضًا

13
gbn

لا يمكنك تثبيت UTF-8 كمجموعة أحرف لأنها ليست مجموعة أحرف ، إنها ترميز.

إذا كنت تريد تخزين نص Unicode ، فاستخدم نوع البيانات nvarchar.

إذا كنت تريد تخزين نص مرمّز باستخدام UTF-8 ، فيمكنك تخزينه كبيانات ثنائية (varbinary).

2
Guffa

بدءًا من SQL Server 2019 (حاليًا في الإصدار التجريبي/"Community Tech Preview") ، هناك دعم أصلي لـ UTF-8 عبر سلسلة جديدة من عمليات ترتيب UTF-8. HOWEVER، القدرة على استخدام UTF-8 تعني ليس تعني أن يجب. هناك عيوب محددة لاستخدام UTF-8 ، مثل:

  1. أول 128 رمز فقط هي 1 بايت (أي 7 بت القياسية ASCII set)
  2. النقاط التالية التي تبلغ 2000 رمز تقريبًا هي 2 بايت ، وبالتالي لا توجد وفورات في المساحة فوق UTF-16/NVARCHAR
  3. نقاط الرمز 63k المتبقية في BMP (أي نطاق U + 0800 - U + FFFF) كلها 3 بايت ، وبالتالي 1 بايت أكبر من نفس حرف في UTF-16/NVARCHAR.
  4. ما عليك سوى ذكره: الأحرف التكميلية هي 4 بايت في كلا الترميزين ، لذلك لا يوجد فرق في المساحة هناك
  5. على الرغم من أنك قد توفر مساحة باستخدام UTF-8 ، إلا أن هناك فرصة جيدة جدًا لتحقيق أداء على هذا النحو.

ما هو حقيقة الأمر هو أن: UTF-8 هو تصميم تنسيق تخزين لتمكين أنظمة 8 بت (التي تم تصميمها عادة حول ASCII و ASCII Extended - Code Pages) لاستخدام Unicode دون كسر أي شيء أو طلب أي تعديل للملفات الموجودة للحفاظ على تشغيل الأشياء. UTF-8 رائع لأنظمة الملفات والشبكات ، لكن البيانات المخزنة inside SQL Server ليس كذلك. حقيقة أن البيانات التي تحدث للتو في الغالب (أو كليًا) داخل النطاق ASCII يتطلب مساحة أقل من نفس البيانات عندما تم تخزينه كـ UTF-16/NVARCHAR وهو أحد الآثار الجانبية. بالتأكيد ، إنه أحد الآثار الجانبية التي يمكن أن تكون مفيدة ، ولكن هذا القرار يجب أن يتخذ من قبل شخص يفهم كل من البيانات و عواقب/عيوب هذا القرار. هذه = ليس ميزة للاستخدام العام.

أيضًا ، حالة الاستخدام الرئيسية لـ UTF-8 (في SQL Server) هي لرمز التطبيق الذي يستخدم بالفعل UTF-8 ، ربما بالفعل مع RDBMS آخر يدعمه ، ولا توجد رغبة أو قدرة على تحديث رمز التطبيق/مخطط قاعدة البيانات لاستخدام NVARCHAR أنواع البيانات (للجداول ، والمتغيرات ، والمعلمات ، وما إلى ذلك) ، أو بادئة حرفية السلسلة بحرف كبير "N". الهدف هو نفس سبب وجود UTF-8: تمكين رمز التطبيق من استخدام Unicode دون تغيير الهيكل العام أو جعل البيانات الموجودة غير صالحة. إذا كان هذا يصف حالتك ، فاستخدم UTF-8 ، ولكن كن على علم أنه لا تزال هناك بعض الأخطاء/المشكلات بها.

إذا لم يكن لديك حاجة صريحة لعمل Unicode دون استخدام NVARCHAR أو أحرف سلسلة مسبوقة بالحرف "N" ، فإن السيناريو الآخر الوحيد الذي تكون فيه UTF-8 هو فائدة إذا كان لديك الكثير من [ -تقريبًا standard ASCII بيانات تحتاج إلى السماح لأحرف Unicode ، وأنت تستخدم NVARCHAR(MAX) (مما يعني أن ضغط البيانات لن يعمل) ، ويتم تحديث الجدول بشكل متكرر (لذلك من المحتمل ألا يساعدك فهرس Columnstore Columnstore Index بالفعل).

للحصول على التفاصيل الكاملة ، يرجى الاطلاع على منصبي:

دعم UTF-8 الأصلي في SQL Server 2019: Savior or False Prophet؟

1
Solomon Rutzky

في حالتي ، كان علي عرض الأحرف العربية وكانت قاعدة بيانات التطوير الخاصة بي في عام 2014 ، هنا عملت الأمور بشكل جيد. هنا ، في الاستعلام ، كان بإمكاني رؤية الأحرف العربية وكان ترتيب نسختي هو SQL_Latin1_General_CP1256_CI_AS

لكن إنتاجي كان في SQL Server 2008 وفي النهاية لم يتم دعم محارف UTF-8. هنا يمكن أن أرى كل شيء ؟؟؟؟؟؟؟؟؟؟؟ لأن UTF-8 غير مدعوم في SQL 2008.

كل ما فعلته هو تغيير كل varchar إلى nvarchar ويمكنني رؤية الحرف العربي بشكل صحيح. أيضا أقوم بتغيير ترتيب قاعدة بيانات 2008 إلى SQL_Latin1_General_CP1256_CI_AS

0
Halim