SQL Server 2005/2008 UTF-8 Collation / Charset

ฉันไม่สามารถค้นหาตัวเลือกโดยตรงเพื่อตั้งค่าการUTF-8รวมCollations/Charsetsใน SQL Server 2005/2008 เช่นเดียวกับที่เป็นไปได้ในการตั้งค่าในเอ็นจิน SQL อื่น แต่ใน SQL Server 2005/2008 มีการเปรียบเทียบละตินและ SQL เท่านั้น

มีตัวเลือกในการบังคับ / ติดตั้ง collations / charsets เหล่านี้ในเอ็นจิน SQL Server (สำหรับทั้งสองเวอร์ชัน) 2005/2008 บน Win2008 OS

ไม่ไม่มี SQL Server ไม่รองรับ UTF-8

คุณจำเป็นต้องกำหนดคอลัมน์ของคุณเป็น nvarchar / nchar ถ้าคุณต้องการข้อมูล Unicode หมายเหตุ SQL Server ภายในเก็บสิ่งนี้เป็น UCS-2

หมายเหตุที่ว่านี้มีเบนการร้องขอจากMS ในการเชื่อมต่อและมีบทความ KB เก่า และข้อมูลบางอย่างในบล็อกนี้ด้วย

คุณไม่สามารถติดตั้ง UTF-8 เป็นชุดอักขระได้เนื่องจากไม่ใช่ชุดอักขระเป็นการเข้ารหัส

ถ้าคุณต้องการเก็บข้อความ Unicode คุณใช้nvarcharชนิดข้อมูล

หากคุณต้องการจัดเก็บข้อความที่เข้ารหัสโดยใช้ UTF-8 คุณจะเก็บไว้เป็นข้อมูลไบนารี่ ( varbinary)

เริ่มต้นใน SQL Server 2019 (ขณะนี้อยู่ในรุ่นเบต้า / "Community Tech Preview") มีการสนับสนุนดั้งเดิมสำหรับ UTF-8 ผ่านทางชุดใหม่ของการเปรียบเทียบ UTF-8 อย่างไรก็ตามการมีความสามารถในการใช้ UTF-8 ไม่ได้หมายความว่าคุณควร มีข้อเสียเปรียบที่ชัดเจนในการใช้ UTF-8 เช่น:

1. คะแนน 128 รหัสแรกเท่านั้นคือ 1 ไบต์ (เช่นชุด ASCII 7 บิตมาตรฐาน)
2. จุดโค้ดเกือบ 2,000 จุดถัดไปคือ 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 ยอดเยี่ยมสำหรับระบบไฟล์และระบบเครือข่าย แต่ข้อมูลที่เก็บไว้ใน SQL Server นั้นไม่ใช่ ความจริงที่ว่าข้อมูลที่เพิ่งเกิดขึ้นส่วนใหญ่ (หรือทั้งหมด) ภายในช่วง ASCII มาตรฐานนั้นต้องการพื้นที่น้อยกว่าข้อมูลเดียวกันเมื่อจัดเก็บเป็น UTF-16 / NVARCHARเป็นผลข้างเคียง แน่นอนว่ามันเป็นผลข้างเคียงที่สามารถพิสูจน์ได้ว่ามีประโยชน์ แต่การตัดสินใจนั้นจำเป็นต้องทำโดยคนที่เข้าใจทั้งข้อมูลและผลที่ตามมา / ข้อเสียของการตัดสินใจครั้งนี้ นี่คือไม่ใช่คุณสมบัติสำหรับการใช้งานทั่วไป

นอกจากนี้กรณีใช้งานหลักสำหรับ UTF-8 (ใน SQL Server) สำหรับรหัสแอปที่ใช้ UTF-8 อยู่แล้วอาจมี RDBMS อื่นที่รองรับอยู่แล้วและไม่มีความปรารถนาหรือความสามารถในการอัปเดตรหัสแอป / DB schema เพื่อใช้NVARCHARประเภทข้อมูล (สำหรับตารางตัวแปรพารามิเตอร์ ฯลฯ ) หรือเพื่อนำหน้าตัวอักษรสตริงด้วยตัวพิมพ์ใหญ่ "N" เป้าหมายเหมือนกันกับเหตุผลที่มีอยู่ของ UTF-8: เปิดใช้งานรหัสแอปเพื่อใช้ Unicode โดยไม่ต้องเปลี่ยนโครงสร้างโดยรวมหรือการแสดงข้อมูลที่มีอยู่ไม่ถูกต้อง หากสิ่งนี้อธิบายสถานการณ์ของคุณให้ใช้ UTF-8 แต่พึงระวังว่ายังมีข้อบกพร่อง / ปัญหาเล็กน้อยอยู่

หากคุณไม่มีความต้องการที่ชัดเจนสำหรับ Unicode ที่ทำงานโดยไม่ต้องใช้NVARCHARหรือใช้ตัวอักษรสตริง "นำหน้า" ตัวอักษรตัวพิมพ์ใหญ่ดังนั้นสถานการณ์อื่น ๆ เท่านั้นที่ UTF-8 เป็นประโยชน์คือถ้าคุณมีข้อมูล ASCII มาตรฐานส่วนใหญ่ที่ต้องการอนุญาต อักขระ Unicode และคุณกำลังใช้งานNVARCHAR(MAX)(ซึ่งหมายความว่าการบีบอัดข้อมูลจะไม่ทำงาน) และตารางจะได้รับการอัปเดตบ่อยครั้ง (ดังนั้นดัชนีคอลัมน์หลักของคลัสเตอร์อาจไม่ช่วยได้จริง)

สำหรับรายละเอียดโปรดดูโพสต์ของฉัน:

สนับสนุน UTF-8 ดั้งเดิมใน SQL Server 2019: Savior หรือ False Prophet?

ฉันกรณีของฉันฉันต้องแสดงตัวอักษรภาษาอาหรับและฐานข้อมูลการพัฒนาของฉันคือในปี 2014 ที่นี่สิ่งที่ทำงานได้ดี ที่นี่ในแบบสอบถามฉันเห็นตัวอักษรภาษาอาหรับและการเรียงหน้าของฉันคือ SQL_Latin1_General_CP1256_CI_AS

แต่การผลิตของฉันอยู่ใน SQL Server 2008 และในที่สุดมันก็ไม่รองรับ UTF-8 charset ที่นี่ฉันเห็นทั้งหมด ??????????? ไม่รองรับ UTF-8 ใน SQL 2008

ทุกสิ่งที่ฉันทำคือเปลี่ยน varchar ทั้งหมดเป็น nvarchar และฉันเห็นภาษาอาหรับอย่างถูกต้อง นอกจากนี้ฉันเปลี่ยนการจัดเรียงฐานข้อมูล 2008 ของฉันเป็น SQL_Latin1_General_CP1256_CI_AS