Dukungan Kolase dan Unicode
Berlaku untuk:
Titik akhir analitik SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics Platform System (PDW) SQL di Microsoft Fabric Warehouse 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 |
| Jerman - Sortir Buku Telepon (DIN) | 0x10407 | 0x10407 | German_PhoneBook_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 Connectivity (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 Rakyat Tiongkok 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 |
1 Byte 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)keCHAR(10), dan menggunakan kolase yang diaktifkan UTF-8, diterjemahkan menjadi pengurangan 50 persen dalam persyaratan penyimpanan. Pengurangan ini karenaNCHAR(10)membutuhkan 20 byte untuk penyimpanan, dibandingkan denganCHAR(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 terkait
| 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:
- Perubahan Kolase Praktik Terbaik SQL Server
- Menggunakan Format Karakter Unicode untuk Mengimpor atau Mengekspor Data (SQL Server)
- Tulis Pernyataan Transact-SQL Internasional
- Migrasi Praktik Terbaik SQL Server ke Unicode (tidak lagi dipertahankan)
- Konsorsium Unicode
- Standar Unicode
- Dukungan UTF-8 di Driver OLE DB untuk SQL Server
- Nama Kolase SQL Server (Transact-SQL)
- Nama Kolase Windows (Transact-SQL)
- Memperkenalkan dukungan UTF-8 untuk SQL Server
- COLLATE (Transact-SQL)
- Prioritas Kolase