SQL Server 2005/2008 UTF-8 Collation / Charset

16

Saya tidak dapat menemukan opsi (s) langsung untuk mengatur UTF-8rellated Collations/Charsetsdi SQL Server 2005/2008, sama seperti mungkin untuk diatur dalam mesin SQL lain, tetapi dalam SQL Server 2005/2008 hanya ada koleksi Latin dan SQL.

Apakah ada beberapa opsi untuk memaksa / menginstal collations / charset ini dalam mesin SQL Server (untuk keduanya ver.) 2005/2008 pada Win2008 OS

— mKorbel
sumber

13

Tidak, tidak ada. SQL Server tidak mendukung UTF-8.

Anda perlu mendefinisikan kolom Anda sebagai nvarchar / nchar jika Anda menginginkan data unikode. Catatan, secara internal SQL Server menyimpan ini sebagai UCS-2.

Perhatikan bahwa ini telah diminta dari MS pada Connect dan ada artikel KB yang lebih lama . Dan beberapa info di blog ini juga

— gbn
sumber

6

selain itu, jika Anda akan melakukan pencocokan teks pada nvarchar dengan karakter asing, Anda harus mencocokkan pada string yang diformat dengan N sebelum string (mis. N'οἰκονόμον ').

— swasheck

Apakah perilaku ini berubah dalam rilis terbaru dari server SQL?

— Seiyria

@Seiyria: tidak, perilaku yang sama

— gbn

Siapa pun yang menemukan cara mereka untuk jawaban ini, silakan buka halaman MS Connect dan pilih bahwa MS mendukung UTF-8 pada SQL Server. Terima kasih: D

— DarcyThomas

@DarcyThomas ini menjadi kenyataan di SQL Server 2019, meskipun masih bukan sesuatu yang harus menggunakan kecuali mereka memiliki kebutuhan eksplisit untuk itu. Silakan lihat jawaban saya untuk detailnya.

— Solomon Rutzky

2

Anda tidak dapat menginstal UTF-8 sebagai set karakter karena itu bukan set karakter, ini adalah encoding.

Jika Anda ingin menyimpan teks Unicode, Anda menggunakan nvarchartipe data.

Jika Anda ingin menyimpan teks yang disandikan menggunakan UTF-8, Anda menyimpannya sebagai data biner ( varbinary).

— Guffa
sumber

1

Dimulai pada SQL Server 2019 (saat ini dalam versi beta / "Komunitas Tek Preview"), ada dukungan asli untuk UTF-8 melalui seri baru UTF-8 collations. NAMUN, memiliki kemampuan untuk menggunakan UTF-8 tidak berarti Anda harus melakukannya. Ada beberapa kekurangan untuk menggunakan UTF-8, seperti:

Hanya 128 titik kode pertama yang 1 byte (yaitu set ASCII 7-bit standar)
Hampir 2000 poin kode berikutnya adalah 2 byte, karenanya tidak ada penghematan ruang pada UTF-16 / NVARCHAR
Poin kode 63k yang tersisa dalam BMP (yaitu kisaran U + 0800 - U + FFFF) semuanya 3 byte, karenanya 1 byte lebih besar dari karakter yang sama dalam UTF-16 / NVARCHAR.
Katakan saja: Karakter Tambahan adalah 4 byte di kedua pengkodean, jadi tidak ada perbedaan ruang di sana
Meskipun Anda dapat menghemat ruang menggunakan UTF-8, ada peluang yang sangat baik bahwa Anda akan terpukul kinerja untuk melakukannya.

Apa yang sebenarnya terjadi adalah ini: UTF-8 adalah desain format penyimpanan untuk mengaktifkan sistem 8-bit (yang biasanya dirancang di sekitar ASCII dan ASCII Extended - Code Pages) untuk menggunakan Unicode tanpa merusak apa pun atau memerlukan modifikasi apa pun yang ada file agar tetap berjalan. UTF-8 sangat bagus untuk sistem file dan jaringan, tetapi data yang disimpan di dalam SQL Server juga tidak. Fakta bahwa data yang kebetulan sebagian besar (atau seluruhnya) dalam rentang ASCII standar membutuhkan lebih sedikit ruang daripada data yang sama ketika disimpan sebagai UTF-16 / NVARCHARadalah efek samping. Tentu, ini adalah efek samping yang terbukti bermanfaat, tetapi keputusan itu perlu dibuat oleh seseorang yang memahami data dan konsekuensi / kelemahan dari keputusan ini. Ini adalahbukan fitur untuk penggunaan umum.

Juga, use case utama untuk UTF-8 (dalam SQL Server) adalah untuk kode aplikasi yang sudah menggunakan UTF-8, mungkin sudah dengan RDBMS lain yang mendukungnya, dan tidak ada keinginan atau kemampuan untuk memperbarui kode aplikasi / skema DB untuk menggunakan NVARCHARtipe data (untuk tabel, variabel, parameter, dll), atau untuk awalan string literal dengan huruf besar "N". Tujuannya sama dengan alasan UTF-8 yang ada: memungkinkan kode aplikasi untuk menggunakan Unicode tanpa mengubah struktur keseluruhan atau membuat data yang ada tidak valid. Jika ini menggambarkan situasi Anda, maka gunakan UTF-8, tetapi perlu diketahui bahwa masih ada beberapa bug / masalah dengan itu.

Jika Anda tidak memiliki kebutuhan eksplisit untuk Unicode yang bekerja tanpa menggunakan NVARCHARatau huruf kapital string awalan "N", maka satu-satunya skenario di mana UTF-8 adalah manfaat adalah jika Anda memiliki BANYAK sebagian besar data ASCII standar yang perlu untuk memungkinkan Karakter Unicode, dan Anda menggunakan NVARCHAR(MAX)(yang berarti bahwa kompresi data tidak akan berfungsi), dan tabel akan sering diperbarui (jadi Indeks Columnstore Clustered mungkin tidak akan benar-benar membantu).

Untuk detail lengkap, silakan lihat posting saya:

Dukungan UTF-8 Asli di SQL Server 2019: Juruselamat atau Nabi Palsu?

— Solomon Rutzky
sumber

0

Saya kasus saya, saya harus menampilkan karakter Arab dan database pengembangan saya pada tahun 2014, di sini semuanya bekerja dengan baik. Di sini, dalam kueri saya bisa melihat karakter bahasa Arab dan collation saya adalah SQL_Latin1_General_CP1256_CI_AS

Tapi produksi saya di SQL server 2008 dan akhirnya tidak didukung charset UTF-8. Di sini, saya bisa melihat semua ??????????? karena UTF-8 tidak didukung dalam SQL 2008.

Apa yang saya lakukan adalah mengubah semua varchar menjadi nvarchar dan saya bisa melihat arang bahasa Arab dengan benar. Saya juga mengubah susunan basis data 2008 saya menjadi SQL_Latin1_General_CP1256_CI_AS

— Halim
sumber