Dukungan Kolase dan Unicode

  • Artikel

Berlaku untuk:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics AnalyticsPlatform System (PDW)Titik akhir analitik SQL di Microsoft FabricWarehouse di Microsoft Fabric

Kolase di SQL Server menyediakan aturan pengurutan, kasus, dan properti sensitivitas aksen untuk data Anda. Kolase yang digunakan dengan jenis data karakter, seperti karakter dan varchar, menentukan halaman kode dan karakter terkait yang dapat diwakili untuk jenis data tersebut.

Baik Anda menginstal instans baru SQL Server, memulihkan cadangan database, atau menyambungkan server ke database klien, penting untuk memahami persyaratan lokal, urutan pengurutan, dan sensitivitas kasus dan aksen data yang sedang Anda kerjakan. Untuk mencantumkan kolase yang tersedia di instans SQL Server Anda, lihat sys.fn_helpcollations (Transact-SQL).

Saat Anda memilih kolatasi untuk server, database, kolom, atau ekspresi, Anda menetapkan karakteristik tertentu ke data Anda. Karakteristik ini memengaruhi hasil banyak operasi dalam database. Misalnya, saat Anda membuat kueri dengan menggunakan ORDER BY, urutan pengurutan kumpulan hasil Anda mungkin bergantung pada kolase yang diterapkan ke database atau ditentukan dalam COLLATE klausul di tingkat ekspresi kueri.

Untuk menggunakan dukungan kolase terbaik di SQL Server, Anda harus memahami istilah yang ditentukan dalam artikel ini dan bagaimana mereka berhubungan dengan karakteristik data Anda.

Istilah kolabasi

Kolase

Kolase menentukan pola bit yang mewakili setiap karakter dalam himpunan data. Kolas juga menentukan aturan yang mengurutkan dan membandingkan data. SQL Server mendukung penyimpanan objek yang memiliki kolase berbeda dalam satu database. Untuk kolom non-Unicode, pengaturan kolase menentukan halaman kode untuk data dan karakter mana yang dapat diwakili. Data yang Anda pindahkan di antara kolom non-Unicode harus dikonversi dari halaman kode sumber ke halaman kode tujuan.

Hasil pernyataan Transact-SQL dapat bervariasi ketika pernyataan dijalankan dalam konteks database berbeda yang memiliki pengaturan kolase yang berbeda. Jika memungkinkan, gunakan kolate standar untuk organisasi Anda. Dengan cara ini, Anda tidak perlu menentukan kolater dalam setiap karakter atau ekspresi Unicode. Jika Anda harus bekerja dengan objek yang memiliki pengaturan halaman kolase dan kode yang berbeda, kode kueri Anda untuk mempertimbangkan aturan kolase yang diutamakan. Untuk informasi selengkapnya, lihat Prioritas Kolase (Transact-SQL).

Opsi yang terkait dengan kolase adalah sensitivitas huruf besar/kecil, sensitivitas aksen, sensitivitas kana, sensitivitas lebar, dan sensitivitas pemilih variasi. SQL Server 2019 (15.x) memperkenalkan opsi tambahan untuk pengodean UTF-8 .

Anda dapat menentukan opsi ini dengan menambahkannya ke nama kolase. Misalnya, kolase Japanese_Bushu_Kakusu_100_CS_AS_KS_WS_UTF8 peka huruf besar/kecil, sensitif terhadap aksen, peka kana, peka lebar, dan dikodekan UTF-8. Sebagai contoh lain, kolase Japanese_Bushu_Kakusu_140_CI_AI_KS_WS_VSS tidak peka huruf besar/kecil, tidak peka huruf besar/kecil, peka terhadap kana, peka lebar, sensitif terhadap selektor variasi, dan menggunakan pengodean non-Unicode.

Perilaku yang terkait dengan berbagai opsi ini dijelaskan dalam tabel berikut:

Opsi Deskripsi
Peka huruf besar/kecil (_CS) Membedakan antara huruf besar dan huruf kecil. Jika opsi ini dipilih, huruf kecil mengurutkan di depan versi huruf besarnya. Jika opsi ini tidak dipilih, kolater tidak peka huruf besar/kecil. Artinya, SQL Server menganggap versi huruf besar dan huruf kecil identik untuk tujuan pengurutan. Anda dapat secara eksplisit memilih ketidakpekaan huruf besar/kecil dengan menentukan _CI.
Peka aksen (_AS) Membedakan antara karakter beraksen dan tidak beraksen. Misalnya, "a" tidak sama dengan "ấ". Jika opsi ini tidak dipilih, kolaternya tidak peka aksen. Artinya, SQL Server menganggap versi huruf yang beraksen dan tidak beraksen agar identik untuk tujuan pengurutan. Anda dapat secara eksplisit memilih insensitivitas aksen dengan menentukan _AI.
Peka kana (_KS) Membedakan antara dua jenis karakter kana Jepang: Hiragana dan Katakana. Jika opsi ini tidak dipilih, kolatenya tidak peka kana. Artinya, SQL Server menganggap karakter Hiragana dan Katakana sama untuk tujuan pengurutan. Menghilangkan opsi ini adalah satu-satunya metode untuk menentukan kana-insensitivitas.
Peka lebar (_WS) Membedakan antara karakter lebar penuh dan lebar setengah. Jika opsi ini tidak dipilih, SQL Server mempertimbangkan representasi lebar penuh dan lebar setengah dari karakter yang sama agar identik untuk tujuan pengurutan. Menghilangkan opsi ini adalah satu-satunya metode untuk menentukan ketidakpekaan lebar.
Peka pemilih variasi (_VSS) Membedakan antara berbagai pemilih variasi ideografis dalam kolase Jepang Japanese_Bushu_Kakusu_140 dan Japanese_XJIS_140, yang diperkenalkan di SQL Server 2017 (14.x). Urutan variasi terdiri dari karakter dasar ditambah pemilih variasi. Jika opsi _VSS ini tidak dipilih, kolaternya tidak peka selektor variasi, dan pemilih variasi tidak dipertimbangkan dalam perbandingan. Artinya, SQL Server menganggap karakter yang dibangun di atas karakter dasar yang sama dengan pemilih variasi yang berbeda agar identik untuk tujuan pengurutan. Untuk informasi selengkapnya, lihat Database Variasi Ideografi Unicode.

Kolasis sensitif pemilih variasi (_VSS) tidak didukung dalam indeks pencarian teks lengkap. Indeks pencarian teks lengkap hanya mendukung opsi Aksen-Sensitif (_AS), Peka Kana (_KS), dan Peka lebar (_WS). Mesin SQL Server XML dan CLR tidak mendukung pemilih Variasi (_VSS).
Biner (_BIN)1 Mengurutkan dan membandingkan data dalam tabel SQL Server berdasarkan pola bit yang ditentukan untuk setiap karakter. Urutan pengurutan biner peka huruf besar/kecil dan peka aksen. Biner juga merupakan urutan pengurutan tercepat. Untuk informasi selengkapnya, lihat bagian Kolate biner di artikel ini.
Titik kode biner (_BIN2)1 Mengurutkan dan membandingkan data dalam tabel SQL Server berdasarkan titik kode Unicode untuk data Unicode. Untuk data non-Unicode, titik Kode biner menggunakan perbandingan yang identik dengan yang untuk pengurutan biner.

Keuntungan menggunakan urutan pengurutan titik kode Biner adalah bahwa tidak ada resor data yang diperlukan dalam aplikasi yang membandingkan data SQL Server yang diurutkan. Akibatnya, urutan pengurutan titik kode Biner menyediakan pengembangan aplikasi yang lebih sederhana dan kemungkinan peningkatan performa. Untuk informasi selengkapnya, lihat bagian Kolate biner di artikel ini.
UTF-8 (_UTF8) Memungkinkan data yang dikodekan UTF-8 disimpan di SQL Server. Jika opsi ini tidak dipilih, SQL Server menggunakan format pengodean non-Unicode default untuk jenis data yang berlaku. Untuk informasi selengkapnya, lihat bagian Dukungan UTF-8 di artikel ini.

1 Jika titik Biner atau Binary-code dipilih, opsi Peka huruf besar/kecil (_CS), Peka aksen (_AS), peka Kana (_KS), dan Opsi peka lebar (_WS) tidak tersedia.

Contoh opsi kolamen

Setiap kolase digabungkan sebagai serangkaian akhiran untuk menentukan sensitivitas huruf besar/kecil, aksen, lebar, atau kana. Contoh berikut menjelaskan perilaku urutan pengurutan untuk berbagai kombinasi akhiran.

Akhiran kolase Windows Mengurutkan deskripsi urutan
_BIN 1 Pengurutan biner
_BIN2 1, 2 Urutan pengurutan titik kode biner
_CI_AI 2 Tidak peka huruf besar/kecil, aksen-tidak sensitif, kana-tidak peka, tidak peka lebar
_CI_AI_KS 2 Tidak peka huruf besar/kecil, aksen-tidak sensitif, peka kana, tidak peka lebar
_CI_AI_KS_WS 2 Tidak peka huruf besar/kecil, aksen-tidak sensitif, peka kana, peka lebar
_CI_AI_WS 2 Tidak peka huruf besar/kecil, aksen-tidak sensitif, kana-tidak peka, peka lebar
_CI_AS 2 Tidak peka huruf besar/kecil, peka terhadap aksen, kana-tidak peka, tidak peka lebar
_CI_AS_KS 2 Tidak peka huruf besar/kecil, peka aksen, peka kana, tidak peka lebar
_CI_AS_KS_WS 2 Tidak peka huruf besar/kecil, peka aksen, peka kana, peka lebar
_CI_AS_WS 2 Tidak peka huruf besar/kecil, peka aksen, kana-tidak peka, peka lebar
_CS_AI 2 Peka huruf besar/kecil, aksen-tidak sensitif, kana-tidak peka, tidak peka lebar
_CS_AI_KS 2 Peka huruf besar/kecil, aksen-tidak sensitif, peka kana, tidak peka lebar
_CS_AI_KS_WS 2 Peka huruf besar/kecil, aksen-tidak sensitif, peka kana, peka lebar
_CS_AI_WS 2 Peka huruf besar/kecil, aksen-tidak sensitif, kana-tidak peka, peka lebar
_CS_AS 2 Peka huruf besar/kecil, sensitif terhadap aksen, kana-tidak peka, tidak peka lebar
_CS_AS_KS 2 Peka huruf besar/kecil, sensitif terhadap aksen, peka kana, tidak peka lebar
_CS_AS_KS_WS 2 Peka huruf besar/kecil, peka aksen, peka kana, peka lebar
_CS_AS_WS 2 Peka huruf besar/kecil, peka aksen, kana tidak peka, peka lebar

1 Jika titik Biner atau Binary-code dipilih, opsi Peka huruf besar/kecil (_CS), Peka aksen (_AS), peka Kana (_KS), dan Opsi peka lebar (_WS) tidak tersedia.

2 Menambahkan opsi UTF-8 (_UTF8) memungkinkan Anda untuk mengodekan data Unicode dengan menggunakan UTF-8. Untuk informasi selengkapnya, lihat bagian Dukungan UTF-8 di artikel ini.

Kumpulan kolase

SQL Server mendukung kumpulan kolase berikut:

Kolatasi Windows

Kolase Windows menentukan aturan untuk menyimpan data karakter yang didasarkan pada lokal sistem Windows terkait. Untuk kolase Windows, Anda dapat menerapkan perbandingan data non-Unicode dengan menggunakan algoritma yang sama seperti untuk data Unicode. Aturan kolaksi Windows dasar menentukan alfabet atau bahasa mana yang digunakan saat pengurutan kamus diterapkan. Aturan juga menentukan halaman kode yang digunakan untuk menyimpan data karakter non-Unicode. Pengurutan Unicode dan non-Unicode kompatibel dengan perbandingan string dalam versi Windows tertentu. Ini memberikan konsistensi di seluruh jenis data dalam SQL Server, dan memungkinkan pengembang mengurutkan string dalam aplikasi mereka dengan menggunakan aturan yang sama yang digunakan oleh SQL Server. Untuk informasi selengkapnya, lihat Nama Kolase Windows (Transact-SQL).

Kolatasi biner

Kolase biner mengurutkan data berdasarkan urutan nilai berkode yang ditentukan oleh jenis lokal dan data. Mereka peka huruf besar/kecil. Kolase biner di SQL Server menentukan lokal dan halaman kode ANSI yang digunakan. Ini memberlakukan urutan pengurutan biner. Karena kolase biner relatif sederhana membantu meningkatkan performa aplikasi. Untuk jenis data non-Unicode, perbandingan data didasarkan pada titik kode yang ditentukan pada halaman kode ANSI. Untuk jenis data Unicode, perbandingan data didasarkan pada titik kode Unicode. Untuk kolaborasi biner pada jenis data Unicode, lokal tidak dipertimbangkan dalam pengurutan data. Misalnya, Latin1_General_BIN dan Japanese_BIN menghasilkan hasil pengurutan yang identik saat digunakan pada data Unicode. Untuk informasi selengkapnya, lihat Nama Kolase Windows (Transact-SQL).

Ada dua jenis kolase biner di SQL Server:

  • Kolase BIN warisan, yang melakukan perbandingan code-point-to-code-point yang tidak lengkap untuk data Unicode. Kolase biner warisan ini membandingkan karakter pertama sebagai WCHAR, diikuti oleh perbandingan byte-byte. Dalam kolase BIN, hanya karakter pertama yang diurutkan sesuai dengan titik kode, dan karakter yang tersisa diurutkan sesuai dengan nilai bytenya.

  • Kolaborasi BIN2 yang lebih baru, yang mengimplementasikan perbandingan titik kode murni. Dalam kolase BIN2, semua karakter diurutkan sesuai dengan titik kodenya. Karena platform Intel adalah arsitektur little endian, karakter kode Unicode selalu disimpan byte-swapped.

Kolase SQL Server

Kolase SQL Server (SQL_*) menyediakan kompatibilitas urutan pengurutan dengan versi SQL Server yang lebih lama. Aturan pengurutan kamus untuk data non-Unicode tidak kompatibel dengan rutinitas pengurutan apa pun yang disediakan oleh sistem operasi Windows. Namun, mengurutkan data Unicode kompatibel dengan versi aturan pengurutan Windows tertentu. Karena kolase SQL Server menggunakan aturan perbandingan yang berbeda untuk data non-Unicode dan Unicode, Anda melihat hasil yang berbeda untuk perbandingan data yang sama, tergantung pada jenis data yang mendasarinya.

Misalnya, jika Anda menggunakan kolase SQL SQL_Latin1_General_CP1_CI_AS, string 'a-c' non-Unicode kurang dari string 'ab' karena tanda hubung (-) diurutkan sebagai karakter terpisah yang datang sebelum b. Namun, jika Anda mengonversi string ini ke Unicode dan Anda melakukan perbandingan yang sama, string N'a-c' Unicode dianggap lebih besar dari N'ab', karena aturan pengurutan Unicode menggunakan pengurutan kata yang mengabaikan tanda hubung.

Untuk informasi selengkapnya, lihat Nama Kolase SQL Server (Transact-SQL).

Selama penyiapan SQL Server, pengaturan kolase penginstalan default ditentukan oleh lokal sistem operasi (OS). Anda dapat mengubah kolaborasi tingkat server baik selama penyiapan atau dengan mengubah lokal OS sebelum penginstalan. Untuk alasan kompatibilitas mundur, kolase default diatur ke versi terlama yang tersedia yang terkait dengan setiap lokal tertentu. Oleh karena itu, ini tidak selalu merupakan kolase yang direkomendasikan. Untuk memanfaatkan sepenuhnya fitur SQL Server, ubah pengaturan penginstalan default untuk menggunakan kolase Windows. Misalnya, untuk lokal OS "Inggris (Amerika Serikat)" (halaman kode 1252), kolase default selama penyiapan SQL_Latin1_General_CP1_CI_AS, dan dapat diubah ke rekan kolase Windows terdekat, Latin1_General_100_CI_AS_SC.

Catatan

Saat Anda meningkatkan instans bahasa Inggris SQL Server, Anda dapat menentukan kolase SQL Server (SQL_*) untuk kompatibilitas dengan instans SQL Server yang ada. Karena kolase default untuk instans SQL Server ditentukan selama penyiapan, pastikan Anda menentukan pengaturan kolase dengan hati-hati ketika kondisi berikut ini benar:

  • Kode aplikasi Anda bergantung pada perilaku kolase SQL Server sebelumnya.
  • Anda harus menyimpan data karakter yang mencerminkan beberapa bahasa.

Tingkat kolabasi

Kolase pengaturan didukung pada tingkat instans SQL Server berikut:

Kolatasi tingkat server

Kolase server default ditentukan selama penyiapan SQL Server, dan itu menjadi kolase default database sistem dan semua database pengguna.

Tabel berikut menunjukkan penunjukan kolase default, seperti yang ditentukan oleh lokal sistem operasi (OS), termasuk Pengidentifikasi Kode Bahasa Windows dan SQL (LCID):

Lokal Windows Windows LCID SQL LCID Kolatasi default
Afrikaans (Afrika Selatan) 0x0436 0x0409 Latin1_General_CI_AS
Albania (Albania) 0x041c 0x041c Albanian_CI_AS
Alsatia (Prancis) 0x0484 0x0409 Latin1_General_CI_AS
Amharis (Ethiopia) 0x045e 0x0409 Latin1_General_CI_AS
Arab (Aljazair) 0x1401 0x0401 Arabic_CI_AS
Arab (Bahrain) 0x3c01 0x0401 Arabic_CI_AS
Arab (Mesir) 0x0c01 0x0401 Arabic_CI_AS
Arab (Irak) 0x0801 0x0401 Arabic_CI_AS
Arab (Jordania) 0x2c01 0x0401 Arabic_CI_AS
Arab (Kuwait) 0x3401 0x0401 Arabic_CI_AS
Arab (Lebanon) 0x3001 0x0401 Arabic_CI_AS
Arab (Libya) 0x1001 0x0401 Arabic_CI_AS
Arab (Maroko) 0x1801 0x0401 Arabic_CI_AS
Arab (Oman) 0x2001 0x0401 Arabic_CI_AS
Arab (Qatar) 0x4001 0x0401 Arabic_CI_AS
Arab (Arab Saudi) 0x0401 0x0401 Arabic_CI_AS
Arab (Suriah) 0x2801 0x0401 Arabic_CI_AS
Arab (Tunisia) 0x1c01 0x0401 Arabic_CI_AS
Arab (U.A.E.) 0x3801 0x0401 Arabic_CI_AS
Arab (Yaman) 0x2401 0x0401 Arabic_CI_AS
Armenia (Armenia) 0x042b 0x0419 Latin1_General_CI_AS
Assamese (India) 0x044d 0x044d Tidak tersedia di tingkat server
Azerbaijan (Azerbaijan, Sirilik) 0x082c 0x082c Tidak digunakan lagi, tidak tersedia di tingkat server
Azerbaijan (Azerbaijan, Latin) 0x042c 0x042c Tidak digunakan lagi, tidak tersedia di tingkat server
Bashkir (Rusia) 0x046d 0x046d Latin1_General_CI_AI
Basque (Basque) 0x042d 0x0409 Latin1_General_CI_AS
Belarusia (Belarus) 0x0423 0x0419 Cyrillic_General_CI_AS
Bengali (Bangladesh) 0x0845 0x0445 Tidak tersedia di tingkat server
Bengali (India) 0x0445 0x0439 Tidak tersedia di tingkat server
Bosnia (Bosnia dan Herzegovina, Sirilik) 0x201a 0x201a Latin1_General_CI_AI
Bosnia (Bosnia dan Herzegovina, Latin) 0x141a 0x141a Latin1_General_CI_AI
Breton (Prancis) 0x047e 0x047e Latin1_General_CI_AI
Bulgaria (Bulgaria) 0x0402 0x0419 Cyrillic_General_CI_AS
Bahasa Katalan (Bahasa Katalan) 0x0403 0x0409 Latin1_General_CI_AS
Tionghoa (Hong Kong SAR, RRC) 0x0c04 0x0404 Chinese_Taiwan_Stroke_CI_AS
Bahasa Mandarin (Macau SAR) 0x1404 0x1404 Latin1_General_CI_AI
Bahasa Mandarin (Macau SAR) 0x21404 0x21404 Latin1_General_CI_AI
Tionghoa (RRC) 0x0804 0x0804 Chinese_PRC_CI_AS
Tionghoa (RRC) 0x20804 0x20804 Chinese_PRC_Stroke_CI_AS
Bahasa Tionghoa (Singapura) 0x1004 0x0804 Chinese_PRC_CI_AS
Bahasa Tionghoa (Singapura) 0x21004 0x20804 Chinese_PRC_Stroke_CI_AS
China (Taiwan) 0x30404 0x30404 Chinese_Taiwan_Bopomofo_CI_AS
China (Taiwan) 0x0404 0x0404 Chinese_Taiwan_Stroke_CI_AS
Corsican (Prancis) 0x0483 0x0483 Latin1_General_CI_AI
Kroasia (Bosnia dan Herzegovina, Latin) 0x101a 0x041a Croatian_CI_AS
Kroasia (Kroasia) 0x041a 0x041a Croatian_CI_AS
Bahasa Ceko (Republik Ceko) 0x0405 0x0405 Czech_CI_AS
Denmark (Denmark) 0x0406 0x0406 Danish_Norwegian_CI_AS
Dari (Afghanistan) 0x048c 0x048c Latin1_General_CI_AI
Divehi (Maldives) 0x0465 0x0465 Tidak tersedia di tingkat server
Belanda (Belgia) 0x0813 0x0409 Latin1_General_CI_AS
Bahasa Belanda (Belanda) 0x0413 0x0409 Latin1_General_CI_AS
Inggris (Australia) 0x0c09 0x0409 Latin1_General_CI_AS
Inggris (Belize) 0x2809 0x0409 Latin1_General_CI_AS
Inggris (Kanada) 0x1009 0x0409 Latin1_General_CI_AS
Inggris (Karibia) 0x2409 0x0409 Latin1_General_CI_AS
Inggris (India) 0x4009 0x0409 Latin1_General_CI_AS
Inggris (Irlandia) 0x1809 0x0409 Latin1_General_CI_AS
Inggris (Jamaika) 0x2009 0x0409 Latin1_General_CI_AS
Inggris (Malaysia) 0x4409 0x0409 Latin1_General_CI_AS
Inggris (Selandia Baru) 0x1409 0x0409 Latin1_General_CI_AS
Bahasa Inggris (Filipina) 0x3409 0x0409 Latin1_General_CI_AS
Inggris (Singapura) 0x4809 0x0409 Latin1_General_CI_AS
Inggris (Afrika Selatan) 0x1c09 0x0409 Latin1_General_CI_AS
Inggris (Trinidad dan Tobago) 0x2c09 0x0409 Latin1_General_CI_AS
Inggris (Kerajaan Inggris Bersatu) 0x0809 0x0409 Latin1_General_CI_AS
Inggris (Amerika Serikat) 0x0409 0x0409 SQL_Latin1_General_CP1_CI_AS
Inggris (Zimbabwe) 0x3009 0x0409 Latin1_General_CI_AS
Estonia (Estonia) 0x0425 0x0425 Estonian_CI_AS
Faroese (Kepulauan Faroe) 0x0438 0x0409 Latin1_General_CI_AS
Filipino (Filipina) 0x0464 0x0409 Latin1_General_CI_AS
Finlandia (Finlandia) 0x040b 0x040b Finnish_Swedish_CI_AS
Prancis (Belgia) 0x080c 0x040c French_CI_AS
Prancis (Kanada) 0x0c0c 0x040c French_CI_AS
Bahasa Prancis (Prancis) 0x040c 0x040c French_CI_AS
Prancis (Luksemburg) 0x140c 0x040c French_CI_AS
Prancis (Monako) 0x180c 0x040c French_CI_AS
Prancis (Swiss) 0x100c 0x040c French_CI_AS
Frisia (Belanda) 0x0462 0x0462 Latin1_General_CI_AI
Galisia 0x0456 0x0409 Latin1_General_CI_AS
Georgia (Georgia) 0x10437 0x10437 Georgian_Modern_Sort_CI_AS
Georgia (Georgia) 0x0437 0x0419 Latin1_General_CI_AS
Bahasa Jerman - Telepon Sortir Buku (DIN) 0x10407 0x10407 German_Telepon Book_CI_AS
Jerman (Austria) 0x0c07 0x0409 Latin1_General_CI_AS
Bahasa Jerman (Jerman) 0x0407 0x0409 Latin1_General_CI_AS
Jerman (Liechtenstein) 0x1407 0x0409 Latin1_General_CI_AS
Jerman (Luksemburg) 0x1007 0x0409 Latin1_General_CI_AS
Jerman (Swiss) 0x0807 0x0409 Latin1_General_CI_AS
Yunani (Yunani) 0x0408 0x0408 Greek_CI_AS
Greenlandic (Greenland) 0x046f 0x0406 Danish_Norwegian_CI_AS
Gujarati (India) 0x0447 0x0439 Tidak tersedia di tingkat server
Hausa (Nigeria, Latin) 0x0468 0x0409 Latin1_General_CI_AS
Ibrani (Israel) 0x040d 0x040d Hebrew_CI_AS
Hindi (India) 0x0439 0x0439 Tidak tersedia di tingkat server
Bahasa Hungaria (Hungaria) 0x040e 0x040e Hungarian_CI_AS
Sortir Teknis Hungaria 0x1040e 0x1040e Hungarian_Technical_CI_AS
Islandia (Islandia) 0x040f 0x040f Icelandic_CI_AS
Igbo (Nigeria) 0x0470 0x0409 Latin1_General_CI_AS
Indonesia (Indonesia) 0x0421 0x0409 Latin1_General_CI_AS
Inuktitut (Kanada, Latin) 0x085d 0x0409 Latin1_General_CI_AS
Inuktitut (Syllabics) Kanada 0x045d 0x045d Latin1_General_CI_AI
Irlandia (Irlandia) 0x083c 0x0409 Latin1_General_CI_AS
Italia (Italia) 0x0410 0x0409 Latin1_General_CI_AS
Italia (Swiss) 0x0810 0x0409 Latin1_General_CI_AS
Jepang (Jepang XJIS) 0x0411 0x0411 Japanese_CI_AS
Jepang (Jepang) 0x040411 0x40411 Latin1_General_CI_AI
Kannada (India) 0x044b 0x0439 Tidak tersedia di tingkat server
Kazakh (Kazakhstan) 0x043f 0x043f Kazakh_90_CI_AS
Khmer (Kamboja) 0x0453 0x0453 Tidak tersedia di tingkat server
K'iche (Guatemala) 0x0486 0x0c0a Modern_Spanish_CI_AS
Kinyarwanda (Rwanda) 0x0487 0x0409 Latin1_General_CI_AS
Konkani (India) 0x0457 0x0439 Tidak tersedia di tingkat server
Korea (Pengurutan Kamus Korea) 0x0412 0x0412 Korean_Wansung_CI_AS
Kirgiz (Kirgizstan) 0x0440 0x0419 Cyrillic_General_CI_AS
Lao (Lao PDR) 0x0454 0x0454 Tidak tersedia di tingkat server
Latvia (Latvia) 0x0426 0x0426 Latvian_CI_AS
Lituania (Lituania) 0x0427 0x0427 Lithuanian_CI_AS
Sorbia Bawah (Jerman) 0x082e 0x0409 Latin1_General_CI_AS
Luksemburg (Luksemburg) 0x046e 0x0409 Latin1_General_CI_AS
Makedonia (Makedonia Utara) 0x042f 0x042f Macedonian_FYROM_90_CI_AS
Melayu (Brunei Darussalam) 0x083e 0x0409 Latin1_General_CI_AS
Melayu (Malaysia) 0x043e 0x0409 Latin1_General_CI_AS
Malayalam (India) 0x044c 0x0439 Tidak tersedia di tingkat server
Malta (Malta) 0x043a 0x043a Latin1_General_CI_AI
Maori (Selandia Baru) 0x0481 0x0481 Latin1_General_CI_AI
Mapudungun (Chili) 0x047a 0x047a Latin1_General_CI_AI
Marathi (India) 0x044e 0x0439 Tidak tersedia di tingkat server
Mohawk (Kanada) 0x047c 0x047c Latin1_General_CI_AI
Mongolia (Mongolia) 0x0450 0x0419 Cyrillic_General_CI_AS
Mongolia (RRC) 0x0850 0x0419 Cyrillic_General_CI_AS
Nepal (Nepal) 0x0461 0x0461 Tidak tersedia di tingkat server
Norwegia (Bokmål, Norwegia) 0x0414 0x0414 Latin1_General_CI_AI
Norwegia (Nynorsk, Norwegia) 0x0814 0x0414 Latin1_General_CI_AI
Okitan (Prancis) 0x0482 0x040c French_CI_AS
Odia (India) 0x0448 0x0439 Tidak tersedia di tingkat server
Pashto (Afganistan) 0x0463 0x0463 Tidak tersedia di tingkat server
Persia (Iran) 0x0429 0x0429 Latin1_General_CI_AI
Polandia (Polandia) 0x0415 0x0415 Polish_CI_AS
Portugis (Brasil) 0x0416 0x0409 Latin1_General_CI_AS
Portugis (Portugal) 0x0816 0x0409 Latin1_General_CI_AS
Punjabi (India) 0x0446 0x0439 Tidak tersedia di tingkat server
Quechua (Bolivia) 0x046b 0x0409 Latin1_General_CI_AS
Quechua (Ekuador) 0x086b 0x0409 Latin1_General_CI_AS
Quechua (Peru) 0x0c6b 0x0409 Latin1_General_CI_AS
Rumania (Rumania) 0x0418 0x0418 Romanian_CI_AS
Bahasa Romawi (Swiss) 0x0417 0x0417 Latin1_General_CI_AI
Rusia (Rusia) 0x0419 0x0419 Cyrillic_General_CI_AS
Sahka (Rusia) 0x0485 0x0485 Latin1_General_CI_AI
Sami (Inari, Finlandia) 0x243b 0x083b Latin1_General_CI_AI
Sami (Lule, Norwegia) 0x103b 0x043b Latin1_General_CI_AI
Sami (Lule, Swedia) 0x143b 0x083b Latin1_General_CI_AI
Sami (Utara, Finlandia) 0x0c3b 0x083b Latin1_General_CI_AI
Sami (Utara, Norwegia) 0x043b 0x043b Latin1_General_CI_AI
Sami (Utara, Swedia) 0x083b 0x083b Latin1_General_CI_AI
Sami (Skolt, Finlandia) 0x203b 0x083b Latin1_General_CI_AI
Sami (Selatan, Norwegia) 0x183b 0x043b Latin1_General_CI_AI
Sami (Selatan, Swedia) 0x1c3b 0x083b Latin1_General_CI_AI
Bahasa Sanskerta (India) 0x044f 0x0439 Tidak tersedia di tingkat server
Serbia (Bosnia dan Herzegovina, Sirilik) 0x1c1a 0x0c1a Latin1_General_CI_AI
Serbia (Bosnia dan Herzegovina, Latin) 0x181a 0x081a Latin1_General_CI_AI
Serbia (Serbia, Cyrillic) 0x0c1a 0x0c1a Latin1_General_CI_AI
Serbia (Serbia, Latin) 0x081a 0x081a Latin1_General_CI_AI
Sesotho sa Leboa/Northern Sotho (Afrika Selatan) 0x046c 0x0409 Latin1_General_CI_AS
Setswana/Tswana (Afrika Selatan) 0x0432 0x0409 Latin1_General_CI_AS
Bahasa Sinhala (Sri Lanka) 0x045b 0x0439 Tidak tersedia di tingkat server
Slowakia (Slowakia) 0x041b 0x041b Slovak_CI_AS
Slovenia (Slovenia) 0x0424 0x0424 Slovenian_CI_AS
Bahasa Spanyol (Argentina) 0x2c0a 0x0c0a Modern_Spanish_CI_AS
Bahasa Spanyol (Bolivia) 0x400a 0x0c0a Modern_Spanish_CI_AS
Bahasa Spanyol (Chili) 0x340a 0x0c0a Modern_Spanish_CI_AS
Bahasa Spanyol (Kolombia) 0x240a 0x0c0a Modern_Spanish_CI_AS
Bahasa Spanyol (Kosta Rika) 0x140a 0x0c0a Modern_Spanish_CI_AS
Bahasa Spanyol (Republik Dominika) 0x1c0a 0x0c0a Modern_Spanish_CI_AS
Bahasa Spanyol (Ekuador) 0x300a 0x0c0a Modern_Spanish_CI_AS
Bahasa Spanyol (El Salvador) 0x440a 0x0c0a Modern_Spanish_CI_AS
Bahasa Spanyol (Guatemala) 0x100a 0x0c0a Modern_Spanish_CI_AS
Bahasa Spanyol (Honduras) 0x480a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Meksiko) 0x080a 0x0c0a Modern_Spanish_CI_AS
Bahasa Spanyol (Nikaragua) 0x4c0a 0x0c0a Modern_Spanish_CI_AS
Bahasa Spanyol (Panama) 0x180a 0x0c0a Modern_Spanish_CI_AS
Bahasa Spanyol (Paraguay) 0x3c0a 0x0c0a Modern_Spanish_CI_AS
Bahasa Spanyol (Peru) 0x280a 0x0c0a Modern_Spanish_CI_AS
Bahasa Spanyol (Puerto Riko) 0x500a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Spanyol) 0x0c0a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Spanyol, Jenis Tradisional) 0x040a 0x040a Traditional_Spanish_CI_AS
Bahasa Spanyol (Amerika Serikat) 0x540a 0x0409 Latin1_General_CI_AS
Bahasa Spanyol (Uruguay) 0x380a 0x0c0a Modern_Spanish_CI_AS
Bahasa Spanyol (Venezuela) 0x200a 0x0c0a Modern_Spanish_CI_AS
Swahili (Kenya) 0x0441 0x0409 Latin1_General_CI_AS
Swedia (Finlandia) 0x081d 0x040b Finnish_Swedish_CI_AS
Swedia (Swedia) 0x041d 0x040b Finnish_Swedish_CI_AS
Suriah (Suriah) 0x045a 0x045a Tidak tersedia di tingkat server
Tajik (Tajikistan) 0x0428 0x0419 Cyrillic_General_CI_AS
Tamazight (Aljazair, Latin) 0x085f 0x085f Latin1_General_CI_AI
Tamil (India) 0x0449 0x0439 Tidak tersedia di tingkat server
Tatar (Rusia) 0x0444 0x0444 Cyrillic_General_CI_AS
Telugu (India) 0x044a 0x0439 Tidak tersedia di tingkat server
Thailand (Thailand) 0x041e 0x041e Thai_CI_AS
Tibet (RRC) 0x0451 0x0451 Tidak tersedia di tingkat server
Turki (Türkiye) 0x041f 0x041f Turkish_CI_AS
Turkmen (Turkmenistan) 0x0442 0x0442 Latin1_General_CI_AI
Uighur (RRC) 0x0480 0x0480 Latin1_General_CI_AI
Ukraina (Ukraina) 0x0422 0x0422 Ukrainian_CI_AS
Sorbia Atas (Jerman) 0x042e 0x042e Latin1_General_CI_AI
Urdu (Pakistan) 0x0420 0x0420 Latin1_General_CI_AI
Uzbek (Uzbekistan, Sirilik) 0x0843 0x0419 Cyrillic_General_CI_AS
Uzbek (Uzbekistan, Latin) 0x0443 0x0443 Uzbek_Latin_90_CI_AS
Bahasa Vietnam (Vietnam) 0x042a 0x042a Vietnamese_CI_AS
Welsh (Inggris Raya) 0x0452 0x0452 Latin1_General_CI_AI
Wolof (Senegal) 0x0488 0x040c French_CI_AS
Xhosa/isiXhosa (Afrika Selatan) 0x0434 0x0409 Latin1_General_CI_AS
Yi (RRC) 0x0478 0x0409 Latin1_General_CI_AS
Yoruba (Nigeria) 0x046a 0x0409 Latin1_General_CI_AS
Zulu/isiZulu (Afrika Selatan) 0x0435 0x0409 Latin1_General_CI_AS

Setelah menetapkan kolase ke server, Anda hanya dapat mengubahnya dengan mengekspor semua objek dan data database, membangun master kembali database, dan mengimpor semua objek dan data database. Alih-alih mengubah kolase default instans SQL Server, Anda dapat menentukan kolase yang diinginkan saat membuat database atau kolom database baru.

Untuk mengkueri kolase server untuk instans SQL Server, gunakan SERVERPROPERTY fungsi :

SELECT CONVERT(nvarchar(128), SERVERPROPERTY('collation'));

Untuk mengkueri server untuk semua kolatasi yang tersedia, gunakan fungsi bawaan berikut fn_helpcollations() :

SELECT * FROM sys.fn_helpcollations();

Kolase di Azure SQL Database

Anda tidak dapat mengubah atau mengatur kolase server logis di Azure SQL Database, tetapi dapat mengonfigurasi kolase setiap database baik untuk data maupun untuk katalog. Kolase katalog menentukan kolase untuk metadata sistem, seperti pengidentifikasi objek. Kedua kolase dapat ditentukan secara independen saat Anda membuat database di portal Azure, di T-SQL dengan CREATE DATABASE, di PowerShell dengan New-AzSqlDatabase.

Kolase di Azure SQL Managed Instance

Kolase tingkat server di Azure SQL Managed Instance dapat ditentukan saat instans dibuat dan tidak dapat diubah nanti.

Untuk informasi selengkapnya, lihat Mengatur atau Mengubah Kolase Server.

Kolatasi tingkat database

Saat membuat atau mengubah database, Anda bisa menggunakan COLLATE klausul CREATE DATABASE pernyataan atau ALTER DATABASE untuk menentukan kolate database default. Jika tidak ada kolase yang ditentukan, database diberi kolase server.

Anda tidak dapat mengubah kolas database sistem kecuali Anda mengubah kolatasi untuk server.

  • Di SQL Server dan Azure SQL Managed Instance, kolase database digunakan untuk semua metadata dalam database, dan kolase adalah default untuk semua kolom string, objek sementara, nama variabel, dan string lain yang digunakan dalam database.
  • Di Azure SQL Database, tidak ada kolase server, sehingga setiap database memiliki kolase untuk data dan kolase untuk katalog. CATALOG_COLLATION digunakan untuk semua metadata dalam database, dan kolate adalah default untuk semua kolom string, objek sementara, nama variabel, dan string lain yang digunakan dalam database. CATALOG_COLLATION diatur saat pembuatan dan tidak dapat diubah.

Saat Anda mengubah kolase database pengguna, mungkin ada konflik kolase saat kueri dalam tabel sementara akses database. Tabel sementara selalu disimpan dalam tempdb database sistem, yang menggunakan kolatasi untuk instans. Kueri yang membandingkan data karakter antara database pengguna dan tempdb mungkin gagal jika kolase menyebabkan konflik dalam mengevaluasi data karakter. Anda dapat mengatasi masalah ini dengan menentukan COLLATE klausa dalam kueri. Untuk informasi selengkapnya, lihat COLLATE (Transact-SQL).

Anda dapat mengubah kolamen database pengguna dengan menggunakan pernyataan yang ALTER DATABASE mirip dengan sampel kode berikut:

ALTER DATABASE myDB COLLATE Greek_CS_AI;

Penting

Mengubah kolase tingkat database tidak memengaruhi kolase tingkat kolom atau tingkat ekspresi. Ini tidak memengaruhi data di kolom yang ada.

Anda dapat mengambil kolamen database saat ini dengan menggunakan pernyataan yang mirip dengan sampel kode berikut:

SELECT CONVERT (nvarchar(128), DATABASEPROPERTYEX('database_name', 'collation'));

Kolatasi tingkat kolom

Saat membuat atau mengubah tabel, Anda dapat menentukan kolase untuk setiap kolom string karakter dengan menggunakan COLLATE klausa. Jika Anda tidak menentukan kolase, kolom diberi kolase default database.

Anda dapat mengubah kolamen kolom dengan menggunakan pernyataan yang ALTER TABLE mirip dengan sampel kode berikut:

ALTER TABLE myTable ALTER COLUMN mycol NVARCHAR(10) COLLATE Greek_CS_AI;

Kolatasi tingkat ekspresi

Kolase tingkat ekspresi diatur saat pernyataan dijalankan, dan memengaruhi cara kumpulan hasil dikembalikan. Ini memungkinkan pengurutan ORDER BY hasil menjadi spesifik lokal. Untuk menerapkan kolase tingkat ekspresi, gunakan COLLATE klausa seperti sampel kode berikut:

SELECT name FROM customer ORDER BY name COLLATE Latin1_General_CS_AI;

Lokal

Lokal adalah sekumpulan informasi yang terkait dengan lokasi atau budaya. Informasi dapat mencakup nama dan pengidentifikasi bahasa lisan, skrip yang digunakan untuk menulis bahasa, dan konvensi budaya. Kolase dapat dikaitkan dengan satu atau beberapa lokal. Untuk informasi selengkapnya, lihat ID Lokal yang Ditetapkan oleh Microsoft.

Halaman kode

Halaman kode adalah sekumpulan karakter yang diurutkan dari skrip tertentu di mana indeks numerik, atau nilai titik kode, dikaitkan dengan setiap karakter. Halaman kode Windows biasanya disebut sebagai set karakter atau set karakter. Halaman kode digunakan untuk memberikan dukungan untuk set karakter dan tata letak keyboard yang digunakan oleh lokal sistem Windows yang berbeda.

Susunan urutan

Urutan pengurutan menentukan bagaimana nilai data diurutkan. Pesanan memengaruhi hasil perbandingan data. Data diurutkan dengan menggunakan kolase, dan dapat dioptimalkan dengan menggunakan indeks.

Dukungan Unicode

Unicode adalah standar untuk memetakan poin kode ke karakter. Karena dirancang untuk mencakup semua karakter dari semua bahasa dunia, Anda tidak memerlukan halaman kode yang berbeda untuk menangani serangkaian karakter yang berbeda.

Dasar-dasar Unicode

Menyimpan data dalam beberapa bahasa dalam satu database sulit dikelola saat Anda hanya menggunakan data karakter dan halaman kode. Juga sulit untuk menemukan satu halaman kode untuk database yang dapat menyimpan semua karakter khusus bahasa yang diperlukan. Selain itu, sulit untuk menjamin terjemahan karakter khusus yang benar saat dibaca atau diperbarui oleh berbagai klien yang menjalankan berbagai halaman kode. Database yang mendukung klien internasional harus selalu menggunakan jenis data Unicode alih-alih jenis data non-Unicode.

Misalnya, pertimbangkan database pelanggan dalam Amerika Utara yang harus menangani tiga bahasa utama:

  • Nama dan alamat spanyol untuk Meksiko
  • Nama dan alamat bahasa Prancis untuk Quebec
  • Nama dan alamat bahasa Inggris untuk seluruh Kanada dan Amerika Serikat

Saat Anda hanya menggunakan kolom karakter dan halaman kode, Anda harus berhati-hati untuk memastikan bahwa database diinstal dengan halaman kode yang akan menangani karakter ketiga bahasa. Anda juga harus berhati-hati untuk menjamin terjemahan karakter yang benar dari salah satu bahasa saat karakter dibaca oleh klien yang menjalankan halaman kode untuk bahasa lain.

Catatan

Halaman kode yang digunakan klien ditentukan oleh pengaturan sistem operasi (OS). Untuk mengatur halaman kode klien pada sistem operasi Windows, gunakan Pengaturan Regional di Panel Kontrol.

Akan sulit untuk memilih halaman kode untuk jenis data karakter yang akan mendukung semua karakter yang diperlukan oleh audiens di seluruh dunia. Cara term mudah untuk mengelola data karakter dalam database internasional adalah dengan selalu menggunakan jenis data yang mendukung Unicode.

Jenis data Unicode

Jika Anda menyimpan data karakter yang mencerminkan beberapa bahasa di SQL Server (SQL Server 2005 (9.x) dan yang lebih baru), gunakan jenis data Unicode (nchar, nvarchar, dan ntext) alih-alih jenis data non-Unicode (karakter, varchar, dan teks).

Catatan

For Unicode data types, the Database Engine can represent up to 65,536 characters using UCS-2, or the full Unicode range (‭1,114,112‬ characters) if supplementary characters are used. Untuk informasi selengkapnya tentang mengaktifkan karakter tambahan, lihat Karakter Tambahan.

Atau, dimulai dengan SQL Server 2019 (15.x), jika kolase yang diaktifkan UTF-8 (_UTF8) digunakan, sebelumnya jenis data non-Unicode (karakter dan varchar) menjadi jenis data Unicode menggunakan pengodean UTF-8. SQL Server 2019 (15.x) tidak mengubah perilaku jenis data Unicode yang ada sebelumnya (nchar, nvarchar, dan ntext), yang terus menggunakan pengodean UCS-2 atau UTF-16. Untuk informasi selengkapnya, lihat Perbedaan penyimpanan antara UTF-8 dan UTF-16.

Pertimbangan Unicode

Batasan signifikan dikaitkan dengan jenis data non-Unicode. Ini karena komputer non-Unicode terbatas pada penggunaan satu halaman kode. Anda mungkin mengalami perolehan performa dengan menggunakan Unicode, karena memerlukan lebih sedikit konversi halaman kode. Kolase unicode harus dipilih satu per satu di tingkat database, kolom, atau ekspresi karena tidak didukung di tingkat server.

Saat Anda memindahkan data dari server ke klien, kolase server Anda mungkin tidak dikenali oleh driver klien yang lebih lama. Ini dapat terjadi ketika Anda memindahkan data dari server Unicode ke klien non-Unicode. Opsi terbaik Anda mungkin adalah meningkatkan sistem operasi klien sehingga kolase sistem yang mendasar diperbarui. Jika klien memiliki perangkat lunak klien database yang terinstal, Anda mungkin mempertimbangkan untuk menerapkan pembaruan layanan ke perangkat lunak klien database.

Tip

Anda juga dapat mencoba menggunakan kolamen yang berbeda untuk data di server. Pilih kolatasi yang memetakan ke halaman kode pada klien.

Untuk menggunakan kolase UTF-16 yang tersedia di SQL Server (SQL Server 2012 (11.x) dan yang lebih baru) untuk meningkatkan pencarian dan pengurutan beberapa karakter Unicode (hanya kolase Windows), Anda dapat memilih salah satu kolase karakter tambahan (_SC) atau salah satu kolase versi 140.

Untuk menggunakan kolase UTF-8 yang tersedia di SQL Server 2019 (15.x), dan untuk meningkatkan pencarian dan pengurutan beberapa karakter Unicode (hanya kolase Windows), Anda harus memilih kolase berkemampuan pengodean UTF-8 (_UTF8).

  • Bendera UTF8 dapat diterapkan ke:

    • Kolase linguistik yang sudah mendukung karakter tambahan (_SC) atau kesadaran sensitif pemilih variasi (_VSS)
    • Kolater biner BIN2

  • Bendera UTF8 tidak dapat diterapkan ke:

    • Kolase linguistik yang tidak mendukung karakter tambahan (_SC) atau kesadaran sensitif pemilih variasi (_VSS)
    • Kolatasi biner BIN
    • Kolatasi SQL_*

Untuk mengevaluasi masalah yang terkait dengan penggunaan jenis data Unicode atau non-Unicode, uji skenario Anda untuk mengukur perbedaan performa di lingkungan Anda. Ini adalah praktik yang baik untuk menstandarkan kolase yang digunakan pada sistem di seluruh organisasi Anda, dan untuk menyebarkan server dan klien Unicode sedapat mungkin.

Dalam banyak situasi, SQL Server berinteraksi dengan server atau klien lain, dan organisasi Anda mungkin menggunakan beberapa standar akses data antara aplikasi dan instans server. Klien SQL Server adalah salah satu dari dua jenis utama:

  • Klien Unicode yang menggunakan OLE DB dan Open Database Koneksi ivity (ODBC) versi 3.7 atau yang lebih baru.
  • Klien non-Unicode yang menggunakan DB-Library dan ODBC versi 3.6 atau yang lebih lama.

Tabel berikut ini menyediakan informasi tentang menggunakan data multibahasa dengan berbagai kombinasi server Unicode dan non-Unicode:

Server Klien Manfaat atau batasan
Unicode Unicode Karena data Unicode digunakan di seluruh sistem, skenario ini memberikan performa dan perlindungan terbaik dari kerusakan data yang diambil. Ini adalah situasi dengan ActiveX Data Objects (ADO), OLE DB, dan ODBC versi 3.7 atau yang lebih baru.
Unicode Non-Unicode Dalam skenario ini, terutama dengan koneksi antara server yang menjalankan sistem operasi yang lebih baru dan klien yang menjalankan versi SQL Server yang lebih lama, atau pada sistem operasi yang lebih lama, mungkin ada batasan atau kesalahan saat Anda memindahkan data ke komputer klien. Data Unicode di server mencoba memetakan ke halaman kode yang sesuai pada klien non-Unicode untuk mengonversi data.
Non-Unicode Unicode Ini bukan konfigurasi yang ideal untuk menggunakan data multibahasa. Anda tidak dapat menulis data Unicode ke server non-Unicode. Masalah kemungkinan terjadi ketika data dikirim ke server yang berada di luar halaman kode server.
Non-Unicode Non-Unicode Ini adalah skenario yang sangat membatasi untuk data multibahasa. Anda hanya dapat menggunakan satu halaman kode.

Karakter tambahan

Unicode Consortium mengalokasikan ke setiap karakter titik kode unik, yang merupakan nilai dalam rentang 000000–10FFFF. Karakter yang paling sering digunakan memiliki nilai titik kode dalam rentang 000000–00FFFF (65.536 karakter) yang cocok dengan kata 8-bit atau 16-bit dalam memori dan di disk. Rentang ini biasanya ditetapkan sebagai Basic Multilingual Plane (BMP).

Tetapi Unicode Consortium telah menetapkan 16 "bidang" karakter tambahan, masing-masing berukuran sama dengan BMP. Definisi ini memungkinkan Unicode potensi untuk mewakili 1.114.112 karakter (yaitu, 216 * 17 karakter) dalam rentang titik kode 000000–10FFFF. Karakter dengan nilai titik kode yang lebih besar dari 00FFFF memerlukan dua hingga empat kata 8-bit berturut-turut (UTF-8), atau dua kata 16-bit berturut-turut (UTF-16). Karakter-karakter yang terletak di luar BMP ini disebut karakter tambahan, dan kata-kata tambahan 8-bit atau 16-bit berturut-turut disebut pasangan pengganti. Untuk informasi selengkapnya tentang karakter tambahan, pengganti, dan pasangan pengganti, lihat Standar Unicode.

SQL Server menyediakan jenis data seperti nchar dan nvarchar untuk menyimpan data Unicode dalam rentang BMP (000000–00FFFF), yang dikodekan Mesin Database menggunakan UCS-2.

SQL Server 2012 (11.x) memperkenalkan keluarga baru kolase karakter tambahan (_SC) yang dapat digunakan dengan jenis data nchar, nvarchar, dan sql_variant untuk mewakili rentang karakter Unicode lengkap (000000–10FFFF). Misalnya: Latin1_General_100_CI_AS_SC atau, jika Anda menggunakan kolatasi Jepang, Japanese_Bushu_Kakusu_100_CI_AS_SC.

SQL Server 2019 (15.x) memperluas dukungan karakter tambahan ke jenis data karakter dan varchar dengan kolase baru yang diaktifkan UTF-8 (_UTF8). Jenis data ini juga mampu mewakili rentang karakter Unicode lengkap.

Catatan

Dimulai dengan SQL Server 2017 (14.x), semua kolase baru secara otomatis mendukung karakter tambahan.

Jika Anda menggunakan karakter tambahan:

  • Karakter tambahan dapat digunakan dalam operasi pengurutan dan perbandingan dalam kolase versi 90 atau lebih besar.

  • Semua kolater versi 100 mendukung pengurutan linguistik dengan karakter tambahan.

  • Karakter tambahan tidak didukung untuk digunakan dalam metadata, seperti dalam nama objek database.

  • Bendera SC dapat diterapkan ke:

    • Kolagasi versi 90
    • Kolasasi versi 100

  • Bendera SC tidak dapat diterapkan ke:

    • Kolase Windows versi 80 non-versi
    • Kolatasi biner BIN atau BIN2
    • Kolase SQL*
    • Kolase versi 140 (ini tidak memerlukan bendera SC, karena mereka sudah mendukung karakter tambahan)

Tabel berikut membandingkan perilaku beberapa fungsi string dan operator string saat mereka menggunakan karakter tambahan dengan dan tanpa kolatasi sadar karakter tambahan (SCA):

Fungsi atau operator string Dengan kolatasi SCA Tanpa kolatasi SCA
CHARINDEX

LEN

PATINDEX		 Pasangan pengganti UTF-16 dihitung sebagai titik kode tunggal. Pasangan pengganti UTF-16 dihitung sebagai dua titik kode.
LEFT

REPLACE

REVERSE

RIGHT

SUBSTRING

STUFF		 Fungsi-fungsi ini memperlakukan setiap pasangan pengganti sebagai satu titik kode dan berfungsi seperti yang diharapkan. Fungsi-fungsi ini dapat membagi pasangan pengganti apa pun dan menyebabkan hasil yang tidak terduga.
NCHAR Mengembalikan karakter yang sesuai dengan nilai titik kode Unicode yang ditentukan dalam rentang 0–0x10FFFF. Jika nilai yang ditentukan terletak pada rentang 0–0xFFFF, satu karakter dikembalikan. Untuk nilai yang lebih tinggi, pengganti yang sesuai dikembalikan. Nilai yang lebih tinggi dari 0xFFFF mengembalikan NULL alih-alih pengganti yang sesuai.
UNICODE Mengembalikan titik kode UTF-16 dalam rentang 0–0x10FFFF. Mengembalikan titik kode UCS-2 dalam rentang 0–0xFFFF.
Cocokkan KartuBebas Satu Karakter

Kartubebas - Karakter Tidak Cocok		 Karakter tambahan didukung untuk semua operasi kartubebas. Karakter tambahan tidak didukung untuk operasi kartubebas ini. Operator kartubebas lainnya didukung.

dukungan GB18030

GB18030 adalah standar terpisah yang digunakan di Republik Tiongkok Orang untuk mengodekan karakter Cina. Dalam GB18030, panjang karakter bisa 1, 2, atau 4 byte. SQL Server menyediakan dukungan untuk karakter yang dikodekan GB18030 dengan mengenalinya ketika mereka memasuki server dari aplikasi sisi klien dan mengonversi dan menyimpannya secara asli sebagai karakter Unicode. Setelah disimpan di server, mereka diperlakukan sebagai karakter Unicode dalam operasi berikutnya.

Anda dapat menggunakan kolamen Cina apa pun, sebaiknya versi 100 terbaru. Semua kolaterasi versi 100 mendukung pengurutan linguistik dengan karakter GB18030. Jika data menyertakan karakter tambahan (pasangan pengganti), Anda dapat menggunakan kolase SC yang tersedia di SQL Server untuk meningkatkan pencarian dan pengurutan.

Catatan

Pastikan bahwa alat klien Anda, seperti SQL Server Management Studio, gunakan font Dengxian untuk menampilkan string dengan benar yang berisi karakter yang dikodekan GB18030.

Dukungan skrip kompleks

SQL Server dapat mendukung input, penyimpanan, perubahan, dan menampilkan skrip yang kompleks. Skrip kompleks mencakup jenis berikut:

  • Skrip yang menyertakan kombinasi teks kanan-ke-kiri dan kiri-ke-kanan, seperti kombinasi teks Arab dan Inggris.
  • Skrip yang karakternya berubah bentuk tergantung pada posisinya, atau jika dikombinasikan dengan karakter lain, seperti karakter Arab, Indik, dan Thailand.
  • Bahasa, seperti Thailand, yang memerlukan kamus internal untuk mengenali kata-kata karena tidak ada jeda di antara mereka.

Aplikasi database yang berinteraksi dengan SQL Server harus menggunakan kontrol yang mendukung skrip kompleks. Kontrol formulir Windows standar yang dibuat dalam kode terkelola diaktifkan skrip kompleks.

Kolase Jepang ditambahkan di SQL Server 2017 (14.x)

Dimulai dengan SQL Server 2017 (14.x), keluarga kolase Jepang baru didukung, dengan permutasi berbagai opsi (_CS, , _AS_KS, _WS, dan _VSS), serta _BIN dan _BIN2.

Untuk mencantumkan kolase ini, Anda bisa mengkueri Mesin Database SQL Server:

SELECT name, description
FROM   sys.fn_helpcollations()  
WHERE  COLLATIONPROPERTY(name, 'Version') = 3;

Semua kolatasi baru memiliki dukungan bawaan untuk karakter tambahan, sehingga tidak ada kolamen 140 baru yang memiliki (atau kebutuhan) bendera SC.

Kolase ini didukung dalam indeks Mesin Database, tabel yang dioptimalkan memori, indeks penyimpan kolom, dan modul yang dikompilasi secara asli.

Dukungan UTF-8

SQL Server 2019 (15.x) memperkenalkan dukungan penuh untuk pengodean karakter UTF-8 yang banyak digunakan sebagai pengodean impor atau ekspor, dan sebagai kolase tingkat database atau tingkat kolom untuk data string. UTF-8 diizinkan dalam jenis data karakter dan varchar , dan diaktifkan saat Anda membuat atau mengubah kolase objek menjadi kolase yang memiliki akhiran UTF8 . Salah satu contohnya adalah mengubah LATIN1_GENERAL_100_CI_AS_SC menjadi LATIN1_GENERAL_100_CI_AS_SC_UTF8.

UTF-8 hanya tersedia untuk kolase Windows yang mendukung karakter tambahan, seperti yang diperkenalkan di SQL Server 2012 (11.x). Jenis data nchar dan nvarchar hanya memungkinkan pengodean UCS-2 atau UTF-16, dan tetap tidak berubah.

Azure SQL Database dan Azure SQL Managed Instance juga mendukung UTF-8 pada tingkat database dan kolom, sementara SQL Managed Instance juga mendukung ini pada tingkat server.

Perbedaan penyimpanan antara UTF-8 dan UTF-16

Unicode Consortium mengalokasikan ke setiap karakter titik kode unik, yang merupakan nilai dalam rentang 000000–10FFFF. Dengan SQL Server 2019 (15.x), pengodean UTF-8 dan UTF-16 tersedia untuk mewakili rentang lengkap:

  • Dengan pengodean UTF-8, karakter dalam rentang ASCII (000000–00007F) memerlukan 1 byte, titik kode 000080–0007FF memerlukan 2 byte, titik kode 000800–00FFFF memerlukan 3 byte, dan titik kode 0010000–0010FFFF memerlukan 4 byte.
  • Dengan pengodean UTF-16, titik kode 000000–00FFFF memerlukan 2 byte, dan titik kode 0010000–0010FFFF memerlukan 4 byte.

Tabel berikut mencantumkan byte penyimpanan pengodean untuk setiap rentang karakter dan jenis pengodean:

Rentang kode (heksadesimal) Rentang kode (desimal) Bytepenyimpanan 1 dengan UTF-8 Bytepenyimpanan 1 dengan UTF-16
000000–00007F 0–127 1 2
000080–00009F
0000A0–0003FF
000400–0007FF		 128–159
160–1,023
1,024–2,047		 2 2
000800–003FFF
004000–00FFFF		 2,048–16,383
16,384–65,535		 3 2
010000–03FFFF2

040000–10FFFF2		 65.536–262.1432

262.144–1.114.1112		 4 4

1Byte penyimpanan mengacu pada panjang byte yang dikodekan, bukan ukuran penyimpanan pada disk jenis data. Untuk informasi selengkapnya tentang ukuran penyimpanan di disk, lihat nchar dan nvarchar dan char dan varchar.

2 Rentang titik kode untuk karakter tambahan.

Tip

Adalah umum untuk berpikir, dalam CHAR(n) dan VARCHAR(n) atau di NCHAR(n) dan NVARCHAR(n), yang n mendefinisikan jumlah karakter. Ini karena, dalam contoh kolom CHAR(10), 10 karakter ASCII dalam rentang 0–127 dapat disimpan dengan menggunakan kolase seperti Latin1_General_100_CI_AI, karena setiap karakter dalam rentang ini hanya menggunakan 1 byte.

Namun, dalam CHAR(n) dan VARCHAR(n), n menentukan ukuran string dalam byte (0–8.000), dan dalam NCHAR(n) dan NVARCHAR(n), n menentukan ukuran string dalam byte-pair ( 0–4.000). n tidak pernah mendefinisikan jumlah karakter yang dapat disimpan.

Seperti yang baru saja Anda lihat, memilih pengodean Unicode dan jenis data yang sesuai mungkin memberi Anda penghematan penyimpanan yang signifikan atau meningkatkan jejak penyimpanan Anda saat ini, tergantung pada set karakter yang digunakan. Misalnya, saat Anda menggunakan kolase Latin yang diaktifkan UTF-8, seperti Latin1_General_100_CI_AI_SC_UTF8, CHAR(10) kolom menyimpan 10 byte dan dapat menampung 10 karakter ASCII dalam rentang 0–127. Tetapi hanya dapat menampung lima karakter dalam rentang 128–2047 dan hanya tiga karakter dalam rentang 2048–65535. Sebagai perbandingan, karena NCHAR(10) kolom menyimpan 10 byte-pairs (20 byte), kolom dapat menampung 10 karakter dalam rentang 0–65535.

Sebelum Anda memilih apakah akan menggunakan pengodean UTF-8 atau UTF-16 untuk database atau kolom, pertimbangkan distribusi data string yang akan disimpan:

  • Jika sebagian besar dalam rentang ASCII 0–127 (seperti bahasa Inggris), setiap karakter memerlukan 1 byte dengan UTF-8 dan 2 byte dengan UTF-16. Menggunakan UTF-8 memberikan manfaat penyimpanan. Mengubah jenis data kolom yang ada dengan karakter ASCII dalam rentang 0–127 dari NCHAR(10) ke CHAR(10), dan menggunakan kolase yang diaktifkan UTF-8, diterjemahkan menjadi pengurangan 50 persen dalam persyaratan penyimpanan. Pengurangan ini karena NCHAR(10) membutuhkan 20 byte untuk penyimpanan, dibandingkan dengan CHAR(10), yang memerlukan 10 byte untuk representasi string Unicode yang sama.
  • Di atas rentang ASCII, hampir semua skrip berbasis Latin, dan Yunani, Sirilik, Koptik, Armenia, Ibrani, Arab, Suriah, Tāna, dan N'Ko, membutuhkan 2 byte per karakter dalam UTF-8 dan UTF-16. Dalam kasus ini, tidak ada perbedaan penyimpanan yang signifikan untuk jenis data yang sebanding (misalnya, antara menggunakan karakter atau nchar).
  • Jika sebagian besar skrip Asia Timur (seperti Korea, Cina, dan Jepang), setiap karakter memerlukan 3 byte dengan UTF-8 dan 2 byte dengan UTF-16. Menggunakan UTF-16 memberikan manfaat penyimpanan.
  • Karakter dalam rentang 010000–10FFFF memerlukan 4 byte di UTF-8 dan UTF-16. Dalam kasus ini, tidak ada perbedaan penyimpanan untuk jenis data yang sebanding (misalnya, antara menggunakan karakter atau nchar).

Untuk pertimbangan lain, lihat Menulis Pernyataan Transact-SQL Internasional.

Konversi ke UTF-8

Karena dalam CHAR(n) dan VARCHAR(n) atau di NCHAR(n) dan NVARCHAR(n), n menentukan ukuran penyimpanan byte, bukan jumlah karakter yang dapat disimpan, penting untuk menentukan ukuran jenis data yang harus Anda konversi, untuk menghindari pemotongan data.

Misalnya, pertimbangkan kolom yang didefinisikan sebagai NVARCHAR(100) yang menyimpan 180 byte karakter Jepang. Dalam contoh ini, data kolom saat ini dikodekan menggunakan UCS-2 atau UTF-16, yang menggunakan 2 byte per karakter. Mengonversi jenis kolom ke VARCHAR(200) tidak cukup untuk mencegah pemotongan data, karena tipe data baru hanya dapat menyimpan 200 byte, tetapi karakter Jepang memerlukan 3 byte saat dikodekan dalam UTF-8. Jadi kolom harus didefinisikan sebagai VARCHAR(270) untuk menghindari kehilangan data melalui pemotongan data.

Oleh karena itu, perlu diketahui terlebih dahulu berapa ukuran byte yang diproyeksikan untuk definisi kolom sebelum mengonversi data yang ada ke UTF-8, dan menyesuaikan ukuran jenis data baru yang sesuai. Lihat skrip Transact-SQL atau SQL Notebook di GitHub Sampel Data, yang menggunakan fungsi DATALENGTH dan pernyataan COLLATE untuk menentukan persyaratan panjang data yang benar untuk operasi konversi UTF-8 dalam database yang ada.

Untuk mengubah kolase kolom dan tipe data dalam tabel yang sudah ada, gunakan salah satu metode yang dijelaskan dalam Mengatur atau Mengubah Kolase Kolom.

Untuk mengubah kolase database, memungkinkan objek baru untuk mewarisi kolase database secara default, atau mengubah kolase server, memungkinkan database baru untuk mewarisi kolase sistem secara default, lihat bagian Tugas terkait di artikel ini.

Tugas Artikel
Menjelaskan cara mengatur atau mengubah kolase instans SQL Server. Mengubah kolatasi server tidak mengubah kolatasi database yang ada. Mengatur atau Mengubah Kolase Server
Menjelaskan cara mengatur atau mengubah kolase database pengguna. Mengubah kolatasi database tidak mengubah kolatasi kolom tabel yang sudah ada. Mengatur atau Mengubah Kolase Database
Menjelaskan cara mengatur atau mengubah kolase kolom dalam database Mengatur atau Mengubah Kolase Kolom
Menjelaskan cara mengembalikan informasi kolater di tingkat server, database, atau kolom Lihat Informasi Kolajek
Menjelaskan cara menulis pernyataan Transact-SQL yang lebih portabel dari satu bahasa ke bahasa lain, atau mendukung beberapa bahasa dengan lebih mudah Tulis Pernyataan Transact-SQL Internasional
Menjelaskan cara mengubah bahasa pesan kesalahan dan preferensi tentang bagaimana data tanggal, waktu, dan mata uang digunakan dan ditampilkan Mengatur Bahasa Sesi

Konten terkait

Untuk informasi selengkapnya, lihat konten terkait berikut ini:

Lihat juga