Megosztás a következőn keresztül:

Rendezés és Unicode-támogatás

A következőkre vonatkozik:SQL ServerAzure SQL DatabaseFelügyelt Azure SQL-példányAzure Synapse AnalyticsElemzési platformrendszer (PDW)SQL Analytics-végpont a Microsoft FabricbenRaktár a Microsoft FabricbenSQL-adatbázis a Microsoft Fabricben

Az SQL Server adatbázismotorban található kollációk rendezési szabályokat, kis- és nagybetű érzékenységet, valamint ékezetérzékenységet biztosítanak az adatok számára. A karakteres adattípusokkal (például char és varchar) használt válogatások diktálják a kódlapot és az adott adattípushoz reprezentálható karaktereket.

Függetlenül attól, hogy az SQL Server új példányát telepíti, visszaállítja az adatbázis biztonsági mentését, vagy csatlakoztatja a kiszolgálót az ügyfél-adatbázisokhoz, fontos megismernie a területi követelményeket, a rendezési sorrendet, valamint a használt adatok kis- és nagybetűs érzékenységét. Az SQL Server példányán elérhető kollációkat a sys.fn_helpcollationscím alatt találhatja.

Amikor kiválaszt egy rendezést a kiszolgálóhoz, adatbázishoz, oszlophoz vagy kifejezéshez, bizonyos jellemzőket rendel az adatokhoz. Ezek a jellemzők számos művelet eredményét befolyásolják az adatbázisban. Ha például ORDER BYhasználatával hoz létre lekérdezést, az eredményhalmaz rendezési sorrendje függhet az adatbázisra alkalmazott kollációtól, vagy egy COLLATE záradékban meg van határozva a lekérdezés kifejezésszintjén.

Az SQL Server rendezési támogatásának legjobb használatához ismernie kell az ebben a cikkben meghatározott kifejezéseket, és hogy ezek hogyan kapcsolódnak az adatok jellemzőihez.

Rendezési kifejezések

Collation

A rendezés határozza meg az adathalmaz egyes karaktereit ábrázoló bitmintákat. A kollázsok meghatározzák az adatokat rendező és összehasonlító szabályokat is. Az SQL Server támogatja a különböző rendezésű objektumok tárolását egyetlen adatbázisban. Nem Unicode-oszlopok esetén a rendezési beállítás határozza meg az adatok kódlapját, és hogy mely karakterek jeleníthetők meg. A nem Unicode-oszlopok között áthelyezett adatokat a forráskódlapról a célkódlapra kell konvertálni.

Transact-SQL utasítás eredménye eltérő lehet, ha az utasítás különböző rendezési beállításokkal rendelkező adatbázisok környezetében fut. Ha lehetséges, használjon szabványos rendezést a szervezet számára. Így nem kell minden karakterben vagy Unicode-kifejezésben megadnia a rendezést. Ha olyan objektumokkal kell dolgoznia, amelyek eltérő rendezési és kódlap-beállításokkal rendelkeznek, a lekérdezéseket úgy kell kódolnia, hogy figyelembe vegye a rendezési sorrend szabályait. További információért lásd: Rendezési sorrend.

A kollációval kapcsolatos beállítások a kis- és nagybetűérzékenység, a hangsúlyérzékenység, a kana érzékenység, a szélességérzékenység és a változatválasztó érzékenység. Az SQL Server 2019 (15.x) egy további lehetőséget biztosít UTF-8 kódoláshoz.

Ezeket a beállításokat a rendezési névhez hozzáadva adhatja meg. A Japanese_Bushu_Kakusu_100_CS_AS_KS_WS_SC_UTF8 rendezési sorrend például kis- és nagybetűérzékeny, ékezetérzékeny, kanaérzékeny, szélességérzékeny és UTF-8 kódolású. Másik példaként a rendezési Japanese_Bushu_Kakusu_140_CI_AI_KS_WS_VSS érzéketlen a kis- és nagybetűkre, érzéketlen az ékezetekre, érzékeny a kanára, érzékeny a szélességre, érzékeny a változatválasztóra, és egy régi kódlapot használ a varcharszámára.

A különböző lehetőségekhez társított viselkedést az alábbi táblázatban ismertetjük:

Option Description
Kis- és nagybetűk megkülönböztetése (_CS) Megkülönbözteti a nagybetűket és a kisbetűket. Ha ezt a beállítást választja, a kisbetűk a nagybetűs verziók elé kerülnek. Ha ez a beállítás nincs kiválasztva, a rendezés nem veszi figyelembe a nagybetűérzékenységet. Az SQL Server tehát a betűk kis- és nagybetűs verzióit rendezési célokra azonosnak tekinti. A _CI megadásával kifejezetten választhatja a kis- és nagybetűk érzékenységének figyelmen kívül hagyását.
Ékezetérzékeny (_AS) Megkülönbözteti az ékezetes és az ékezet nélküli karaktereket. A a például nem egyenlő ấ. Ha ez a beállítás nincs kiválasztva, a sorrend akszent-érzéketlen. Az SQL Server tehát a betűk ékezetes és nem célzott verzióit rendezési célokra azonosnak tekinti. Ékezetérzéketlenséget explicit módon választhat az _AI megadásával.
Kana-érzékeny (_KS) Megkülönbözteti a japán kana karakterek két típusát: Hiragana és Katakana. Ha ez a beállítás nincs kiválasztva, a rendezés kana-érzéketlen. Az SQL Server a Hiragana és a Katakana karaktereket rendezési célokra egyenlőnek tekinti. A kana-érzéketlenség megadásának egyetlen módszere a lehetőség kihagyása.
Szélességérzékeny (_WS) Megkülönbözteti a teljes szélességű és a félszélességű karaktereket. Ha ez a beállítás nincs kiválasztva, az SQL Server rendezési célokra azonosnak tekinti ugyanannak a karakternek a teljes szélességű és félszélességű ábrázolását. Ennek a beállításnak a kihagyása az egyetlen módszer a szélesség-érzéketlenség megadására.
Változatválasztó-érzékeny (_VSS) Megkülönbözteti az SQL Server 2017-ben bevezetett japán rendezések Japanese_Bushu_Kakusu_140 és Japanese_XJIS_140különböző ideografikus változatválasztóit (14.x). A változatütemezések egy alap karakterből és egy változatválasztóból állnak. Ha ez a _VSS beállítás nincs kiválasztva, a rendezés változatválasztó-érzéketlen, és a változatválasztó nem szerepel az összehasonlításban. Az SQL Server tehát az azonos alapkarakterekre épülő karaktereket különböző változatválasztókkal rendezési célokra azonosnak tekinti. További információ: Unicode Ideographic Variation Database.

A változatválasztó-érzékeny (_VSS) rendezések nem támogatottak a teljes szöveges keresési indexekben. A teljes szöveges keresési indexek csak a Accent-Sensitive (_AS), a kana-érzékeny (_KS) és a szélességérzékeny (_WS) beállításokat támogatják. Az SQL Server XML- és Common Language Runtime (CLR) integrációs motorjai nem támogatják a (_VSS) változatválasztókat.
Bináris (_BIN) 1 Az SQL Server-táblák adatait az egyes karakterekhez definiált bitminták alapján rendezi és hasonlítja össze. A bináris rendezési sorrend érzékeny a kis- és nagybetűkre, valamint az ékezetekre is. A bináris a leggyorsabb rendezési sorrend is. További információt a jelen cikk Bináris rendezések szakaszában talál.
Bináris kódpont (_BIN2) 1 A Unicode-adatok Unicode-kódpontjai alapján rendezi és hasonlítja össze az SQL Server-táblák adatait. Nem Unicode-adatok esetén a bináris kód pont olyan összehasonlításokat használ, amelyek megegyeznek a bináris rendezésekkel.

A bináris kódpontos rendezési sorrend használatának előnye, hogy a rendezett SQL Server-adatokat összehasonlító alkalmazásokban nincs szükség adatkonvekcióra. Ennek eredményeképpen a Bináris kód pont rendezési sorrendje egyszerűbb alkalmazásfejlesztést és a lehetséges teljesítménynövekedést biztosít. További információt a jelen cikk Bináris rendezések szakaszában talál.
UTF-8 (_UTF8) Lehetővé teszi az UTF-8 kódolású adatok SQL Serveren való tárolását. Ha ez a beállítás nincs kiválasztva, az SQL Server az alapértelmezett nem Unicode kódolási formátumot használja az alkalmazandó adattípusokhoz. További információt a jelen cikk UTF-8 támogatási szakaszában talál.

1 Ha bináris vagy bináris kódpont van kiválasztva, a kis- és nagybetű-érzékenység (_CS), az ékezetérzékenység (_AS), a Kana-érzékenység (_KS) és a szélességérzékenység (_WS) opciók nem érhetők el.

Példák a rendezési beállításokra

A rendezéseket utótagok sorozataként kombináljuk a nagybetűérzékenység, ékezetérzékenység, szélességérzékenység vagy kanaérzékenység meghatározása érdekében. Az alábbi példák a rendezési sorrend viselkedését írják le az utótagok különböző kombinációihoz.

Windows kollációs utótag Rendezési sorrend leírása
_BIN 1 Bináris rendezés
_BIN2 1, 2 Bináris kód pont rendezési sorrendje
_CI_AI 2 Kis- és nagybetűérzéketlen, ékezetérzéketlen, kana-érzéketlen, szélességérzéketlen
_CI_AI_KS 2 Kis- és nagybetűkre érzéketlen, ékezetekre érzéketlen, kana-érzékeny, szélességre érzéketlen
_CI_AI_KS_WS 2 Kis- és nagybetűk iránti érzéketlenség, ékezetiránti érzéketlenség, kana-érzékeny, szélesség-érzékeny
_CI_AI_WS 2 Kis- és nagybetűk érzéketlen, ékezetérzéketlen, kana-érzéketlen, szélességérzékeny
_CI_AS 2 Kis- és nagybetű-érzéketlen, ékezetérzékeny, kana-érzéketlen, szélesség-érzéketlen
_CI_AS_KS 2 Kis- és nagybetűkre nem érzékeny, ékezetérzékeny, kana-érzékeny, szélességre nem érzékeny
_CI_AS_KS_WS 2 Kis- és nagybetűk megkülönböztetése, ékezetérzékeny, kana-érzékeny, szélesség-érzékeny
_CI_AS_WS 2 Kis- és nagybetűk megkülönböztetése, ékezetérzékeny, kana-érzéketlen, szélesség-érzékeny
_CS_AI 2 Kis- és nagybetűket nem különböztet meg, ékezeteket nem különböztet meg, kana-érzéketlen, szélesség-érzéketlen
_CS_AI_KS 2 Kis- és nagybetűk megkülönböztetése, ékezet-érzéketlen, kana-érzékeny, szélességi különbséget figyelmen kívül hagyó
_CS_AI_KS_WS 2 Kis- és nagybetűk megkülönböztetése, ékezetérzékeny, kana-érzékeny, szélesség-érzékeny
_CS_AI_WS 2 Kis- és nagybetűérzékeny, ékezetérzéketlen, kana-érzéketlen, szélességérzékeny
_CS_AS 2 Kis- és nagybetűk megkülönböztetése, ékezetérzékeny, kana-érzéketlen, szélesség-érzéketlen
_CS_AS_KS 2 Kis- és nagybetűérzékeny, ékezetérzékeny, kana-érzékeny, szélességfüggetlen
_CS_AS_KS_WS 2 Kis- és nagybetűk megkülönböztetése, ékezetérzékeny, kana-érzékeny, szélesség-érzékeny
_CS_AS_WS 2 Kis- és nagybetűk megkülönböztetése, ékezetérzékeny, kana-érzéketlen, szélesség-érzékeny

1 Ha bináris vagy bináris kódpont van kiválasztva, a kis- és nagybetű-érzékenység (_CS), az ékezetérzékenység (_AS), a Kana-érzékenység (_KS) és a szélességérzékenység (_WS) opciók nem érhetők el.

2 Az UTF-8 beállítás (_UTF8) hozzáadása lehetővé teszi Unicode-adatok kódolását az UTF-8 használatával. További információt a jelen cikk UTF-8 támogatási szakaszában talál.

Rendezési csoportok

Az SQL Server a következő rendezési csoportokat támogatja:

Windows-összehasonlítások

A Windows-sorbarendezések olyan szabályokat határoznak meg a karakteradatok tárolására, amelyek egy társított Windows-rendszer területi beállításain alapulnak. Windows-rendezés esetén a Unicode-adatokkal megegyező algoritmussal implementálhatja a nem Unicode-adatok összehasonlítását. Az alap Windows rendezési szabályok határozzák meg, hogy melyik ábécét vagy nyelvet használják a szótárrendezés alkalmazásakor. A szabályok azt a kódlapot is megadják, amely nem Unicode karakteradatok tárolására szolgál. A Unicode és a nem Unicode-rendezés egyaránt kompatibilis a Windows egy adott verziójában található sztring-összehasonlításokkal. Ez konzisztenciát biztosít az SQL Server adattípusai között, és lehetővé teszi a fejlesztők számára a sztringek rendezését az alkalmazásaikban ugyanazokkal a szabályokkal, amelyeket az SQL Server használ. További információért lásd a Windows rendezési nevét.

Bináris összehasonlítások

A bináris rendezések a területi beállítás és az adattípus által meghatározott kódolt értékek sorozata alapján rendezik az adatokat. A kis- és nagybetűk megkülönböztetik őket. Az SQL Server bináris kollációja határozza meg a helyi beállításokat és a használt ANSI-kódlapot. Ez bináris rendezési sorrendet kényszerít ki. Mivel viszonylag egyszerűek, a bináris rendezések segítenek az alkalmazás teljesítményének javításában. Nem Unicode-adattípusok esetén az adat-összehasonlítás az ANSI-kódlapon definiált kódpontokon alapul. Unicode-adattípusok esetén az adat-összehasonlítások a Unicode-kódpontokon alapulnak. Unicode-adattípusok bináris rendezéseinél a helyi beállítások nem hatnak az adatsorrendezésre. Például Latin1_General_BIN és Japanese_BIN azonos rendezési eredményeket eredményeznek, amikor Unicode-adatokon használják őket. További információért lásd a Windows rendezési nevét.

Az SQL Server kétféle bináris rendezést alkalmaz:

  • Az örökölt BIN összevetések, amelyek hiányos kódpont-kódpont összehasonlítást végeztek Unicode-adatok esetében. Az örökölt bináris kiosztások az első karaktert WCHAR-ként értékelték, ezt követően bájtonként hasonlították össze. A BIN rendezésben csak az első karakter lesz a kódpont szerint rendezve, a többi karakter pedig a bájtértékek szerint lesz rendezve.

  • Azok az újabb BIN2 rendezések, amelyek tiszta kódpont-összehasonlítást implementálnak. BIN2 rendezés esetén minden karakter a kódpontok szerint van rendezve. Mivel az Intel platform kis-endian architektúra, a Unicode-kódkarakterek bájtjai mindig felcserélve vannak tárolva.

SQL Server-rendezések

Az SQL Server-összehasonlítások (SQL_*) kompatibilitást biztosítanak a korábbi SQL Server verziókkal a rendezési sorrendben. A nem Unicode-adatok szótárrendezési szabályai nem kompatibilisek a Windows operációs rendszerek által biztosított rendezési rutinokkal. A Unicode-adatok rendezése azonban kompatibilis a Windows rendezési szabályainak egy adott verziójával. Mivel az SQL Server-rendezések eltérő összehasonlító szabályokat használnak a nem Unicode- és Unicode-adatokhoz, az alapul szolgáló adattípustól függően eltérő eredményeket láthat ugyanazon adatok összehasonlítására.

Ha például az SQL-rendezési beállítást SQL_Latin1_General_CP1_CI_AShasználja, a nem Unicode karakterlánc 'a-c' kisebb, mint a karakterlánc 'ab', mert a kötőjel (-) önálló karakterként van sorba rendezve, amely a belé kerül. Ha azonban unicode-ra konvertálja ezeket a sztringeket, és ugyanezt az összehasonlítást hajtja végre, a Unicode-sztring N'a-c' nagyobbnak tekinthető, mint N'ab', mivel a Unicode-rendezési szabályok egy szó szerinti rendezési használnak, amely figyelmen kívül hagyja a kötőjelet.

További információért lásd: SQL Server rendezési neve.

Az SQL Server beállítása során az alapértelmezett telepítési rendezési beállítást az operációs rendszer (OS) területi beállítása határozza meg. A kiszolgálószintű rendezést a telepítés során vagy az operációs rendszer területi beállításának módosításával módosíthatja a telepítés előtt. A visszamenőleges kompatibilitás érdekében az alapértelmezett rendezés az egyes területi beállításokhoz társított legrégebbi elérhető verzióra van beállítva. Ezért nem mindig ez az ajánlott rendezés. Az SQL Server funkcióinak teljes kihasználásához módosítsa az alapértelmezett telepítési beállításokat a Windows-rendezések használatára. Például az operációs rendszer "Angol (Egyesült Államok)" területi beállításainál (1252-es kódlap) a telepítés során az alapértelmezett rendezési beállítás SQL_Latin1_General_CP1_CI_AS, amely módosítható a legközelebbi Windows-rendezési megfelelőre, Latin1_General_100_CI_AS_SC.

Az SQL Server angol nyelvű példányának frissítésekor megadhatja az SQL Server-kollációkat (SQL_*) a meglévő példányokkal való kompatibilitás érdekében. Mivel az SQL Server egy példányának alapértelmezett rendezése a beállítás során van meghatározva, ügyeljen arra, hogy gondosan adja meg a rendezési beállításokat, ha a következő feltételek teljesülnek:

  • Az alkalmazáskód a korábbi SQL Server-rendezések viselkedésétől függ.
  • Több nyelvet tükröző karakteradatokat kell tárolnia.

Rendezési szintek

Az SQL Server egy példányának több szintjén támogatott a kollációk beállítása:

Kiszolgálószintű rendezések

Az alapértelmezett kiszolgáló-rendezés az SQL Server beállításakor lesz meghatározva, és ez lesz a rendszeradatbázisok és az összes felhasználói adatbázis alapértelmezett rendezése.

Az alábbi táblázat az operációs rendszer (OS) területi beállításai által meghatározott alapértelmezett rendezési megjelöléseket mutatja be, beleértve a Windows- és SQL Language Code-azonosítókat (LCID):

Windows régióbeállítás Windows LCID SQL LCID Alapértelmezett kolláció
Afrikaans (Dél-Afrika) 0x0436 0x0409 Latin1_General_CI_AS
Albán (Albánia) 0x041c 0x041c Albanian_CI_AS
Alsatian (Franciaország) 0x0484 0x0409 Latin1_General_CI_AS
Amharic (Etiópia) 0x045e 0x0409 Latin1_General_CI_AS
arab (Algéria) 0x1401 0x0401 Arabic_CI_AS
Arab (Bahrein) 0x3c01 0x0401 Arabic_CI_AS
Arab nyelv (egyiptomi) 0x0c01 0x0401 Arabic_CI_AS
arab (Irak) 0x0801 0x0401 Arabic_CI_AS
Arab (Jordánia) 0x2c01 0x0401 Arabic_CI_AS
Arab (Kuvait) 0x3401 0x0401 Arabic_CI_AS
arab (libanoni) 0x3001 0x0401 Arabic_CI_AS
arab (Líbia) 0x1001 0x0401 Arabic_CI_AS
Arab nyelv (Marokkó) 0x1801 0x0401 Arabic_CI_AS
Arab (Omán) 0x2001 0x0401 Arabic_CI_AS
Arab (Katar) 0x4001 0x0401 Arabic_CI_AS
arab nyelv (Szaúd-Arábia) 0x0401 0x0401 Arabic_CI_AS
Arab (Szíria) 0x2801 0x0401 Arabic_CI_AS
Arab nyelv (Tunézia) 0x1c01 0x0401 Arabic_CI_AS
arab (Egyesült Arab Emírségek) 0x3801 0x0401 Arabic_CI_AS
arab nyelv (Jemen) 0x2401 0x0401 Arabic_CI_AS
Örmény (Örménia) 0x042b 0x0419 Latin1_General_CI_AS
Assam nyelv (India) 0x044d 0x044d Kiszolgálószinten nem érhető el
Azerbajdzsáni (Azerbajdzsán, cirill betűs) 0x082c 0x082c Elavult, kiszolgálószinten nem érhető el
Azerbajdzsáni (Azerbajdzsán, latin) 0x042c 0x042c Elavult, kiszolgálószinten nem érhető el
Bashkir (Oroszország) 0x046d 0x046d Latin1_General_CI_AI
Baszk (Baszk) 0x042d 0x0409 Latin1_General_CI_AS
Fehérorosz (Belarusz) 0x0423 0x0419 Cyrillic_General_CI_AS
bengáli (Banglades) 0x0845 0x0445 Kiszolgálószinten nem érhető el
Bengáli (India) 0x0445 0x0439 Kiszolgálószinten nem érhető el
Boszniai (Bosznia-Hercegovina, cirill betűs) 0x201a 0x201a Latin1_General_CI_AI
Bosnyák nyelv (Bosznia-Hercegovina, Latin) 0x141a 0x141a Latin1_General_CI_AI
Breton (Franciaország) 0x047e 0x047e Latin1_General_CI_AI
Bolgár (Bulgária) 0x0402 0x0419 Cyrillic_General_CI_AS
Katalán (katalán) 0x0403 0x0409 Latin1_General_CI_AS
Kínai (Hongkong Különleges Közigazgatási Terület, Kínai Népköztársaság) 0x0c04 0x0404 Chinese_Taiwan_Stroke_CI_AS
Kínai (Macao SAR) 0x1404 0x1404 Latin1_General_CI_AI
Kínai (Macao SAR) 0x21404 0x21404 Latin1_General_CI_AI
Kínai (KNK) 0x0804 0x0804 Chinese_PRC_CI_AS
Kínai (Kínai Népköztársaság) 0x20804 0x20804 Chinese_PRC_Stroke_CI_AS
Kínai (Szingapúr) 0x1004 0x0804 Chinese_PRC_CI_AS
Kínai (Szingapúr) 0x21004 0x20804 Chinese_PRC_Stroke_CI_AS
Kínai (Tajvan) 0x30404 0x30404 Chinese_Taiwan_Bopomofo_CI_AS
Kínai (Tajvan) 0x0404 0x0404 Chinese_Taiwan_Stroke_CI_AS
Korzikán (Franciaország) 0x0483 0x0483 Latin1_General_CI_AI
Horvát (Bosznia-Hercegovina, latin betűs) 0x101a 0x041a Croatian_CI_AS
Horvát (Horvátország) 0x041a 0x041a Croatian_CI_AS
Cseh (Cseh Köztársaság) 0x0405 0x0405 Czech_CI_AS
Dán (Dánia) 0x0406 0x0406 Danish_Norwegian_CI_AS
Dari (Afganisztán) 0x048c 0x048c Latin1_General_CI_AI
Divehi (Maldív-szigetek) 0x0465 0x0465 Kiszolgálószinten nem érhető el
Holland (Belgium) 0x0813 0x0409 Latin1_General_CI_AS
Holland (Hollandia) 0x0413 0x0409 Latin1_General_CI_AS
Angol (Ausztrália) 0x0c09 0x0409 Latin1_General_CI_AS
Angol (Belize) 0x2809 0x0409 Latin1_General_CI_AS
Angol (Kanada) 0x1009 0x0409 Latin1_General_CI_AS
Angol (Karib-térség) 0x2409 0x0409 Latin1_General_CI_AS
Angol (India) 0x4009 0x0409 Latin1_General_CI_AS
Angol (Írország) 0x1809 0x0409 Latin1_General_CI_AS
Angol (Jamaica) 0x2009 0x0409 Latin1_General_CI_AS
Angol (Malajzia) 0x4409 0x0409 Latin1_General_CI_AS
Angol (Új-Zéland) 0x1409 0x0409 Latin1_General_CI_AS
Angol (Fülöp-szigetek) 0x3409 0x0409 Latin1_General_CI_AS
Angol (Szingapúr) 0x4809 0x0409 Latin1_General_CI_AS
Angol (Dél-Afrika) 0x1c09 0x0409 Latin1_General_CI_AS
Angol (Trinidad és Tobago) 0x2c09 0x0409 Latin1_General_CI_AS
Angol (Egyesült Királyság) 0x0809 0x0409 Latin1_General_CI_AS
Angol (Egyesült Államok) 0x0409 0x0409 SQL_Latin1_General_CP1_CI_AS
Angol (Zimbabwe) 0x3009 0x0409 Latin1_General_CI_AS
Észt nyelv (Észtország) 0x0425 0x0425 Estonian_CI_AS
Feröe (Feröe-szigetek) 0x0438 0x0409 Latin1_General_CI_AS
Filipino (Fülöp-szigetek) 0x0464 0x0409 Latin1_General_CI_AS
finn nyelv (Finnország) 0x040b 0x040b Finnish_Swedish_CI_AS
Francia (Belgium) 0x080c 0x040c French_CI_AS
Francia (Kanada) 0x0c0c 0x040c French_CI_AS
Francia (Franciaország) 0x040c 0x040c French_CI_AS
Francia (Luxemburg) 0x140c 0x040c French_CI_AS
Francia (Monaco) 0x180c 0x040c French_CI_AS
Francia (Svájc) 0x100c 0x040c French_CI_AS
Fríz (Holland) 0x0462 0x0462 Latin1_General_CI_AI
Galician 0x0456 0x0409 Latin1_General_CI_AS
grúz nyelv (Grúzia) 0x10437 0x10437 Georgian_Modern_Sort_CI_AS
grúz nyelv (Grúzia) 0x0437 0x0419 Latin1_General_CI_AS
Német - Telefonkönyv rendezés (DIN) 0x10407 0x10407 German_PhoneBook_CI_AS
Német (Ausztria) 0x0c07 0x0409 Latin1_General_CI_AS
Német (Németország) 0x0407 0x0409 Latin1_General_CI_AS
Német (Liechtenstein) 0x1407 0x0409 Latin1_General_CI_AS
Német (Luxemburg) 0x1007 0x0409 Latin1_General_CI_AS
Német (Svájc) 0x0807 0x0409 Latin1_General_CI_AS
Görög (Görögország) 0x0408 0x0408 Greek_CI_AS
Grönlandi (Grönland) 0x046f 0x0406 Danish_Norwegian_CI_AS
gudzsaráti (India) 0x0447 0x0439 Kiszolgálószinten nem érhető el
Hausa (Nigéria, latin) 0x0468 0x0409 Latin1_General_CI_AS
Héber (Izrael) 0x040d 0x040d Hebrew_CI_AS
hindi (India) 0x0439 0x0439 Kiszolgálószinten nem érhető el
Magyar nyelv (Magyarország) 0x040e 0x040e Hungarian_CI_AS
Magyar műszaki osztályozás 0x1040e 0x1040e Hungarian_Technical_CI_AS
Izlandi nyelv (Izland) 0x040f 0x040f Icelandic_CI_AS
Igbo (Nigéria) 0x0470 0x0409 Latin1_General_CI_AS
Indonéz nyelv (Indonézia) 0x0421 0x0409 Latin1_General_CI_AS
Inuktitut (Kanada, latin) 0x085d 0x0409 Latin1_General_CI_AS
Inuktitut (szillabikusok) Kanada 0x045d 0x045d Latin1_General_CI_AI
Ír (Írország) 0x083c 0x0409 Latin1_General_CI_AS
Olasz (Olaszország) 0x0410 0x0409 Latin1_General_CI_AS
Olasz nyelv (Svájc) 0x0810 0x0409 Latin1_General_CI_AS
Japán (Japán XJIS) 0x0411 0x0411 Japanese_CI_AS
japán nyelv (Japán) 0x040411 0x40411 Latin1_General_CI_AI
kannada (India) 0x044b 0x0439 Kiszolgálószinten nem érhető el
Kazak (Kazahsztán) 0x043f 0x043f Kazakh_90_CI_AS
Khmer (Kambodzsa) 0x0453 0x0453 Kiszolgálószinten nem érhető el
K'iche (Guatemala) 0x0486 0x0c0a Modern_Spanish_CI_AS
Kinyarwanda (Ruanda) 0x0487 0x0409 Latin1_General_CI_AS
Konkani (India) 0x0457 0x0439 Kiszolgálószinten nem érhető el
Koreai (koreai szótárrendezés) 0x0412 0x0412 Korean_Wansung_CI_AS
Kirgiz (Kirgizisztán) 0x0440 0x0419 Cyrillic_General_CI_AS
Lao (Lao PDR) 0x0454 0x0454 Kiszolgálószinten nem érhető el
Lett nyelv (Lettország) 0x0426 0x0426 Latvian_CI_AS
litván nyelv (Litvánia) 0x0427 0x0427 Lithuanian_CI_AS
Alsó Sorbian (Németország) 0x082e 0x0409 Latin1_General_CI_AS
Luxemburgi (Luxemburg) 0x046e 0x0409 Latin1_General_CI_AS
Macedón (Észak-Macedónia) 0x042f 0x042f Macedonian_FYROM_90_CI_AS
Maláj (Brunei Darussalam) 0x083e 0x0409 Latin1_General_CI_AS
Maláj (Malajzia) 0x043e 0x0409 Latin1_General_CI_AS
Malajalam (India) 0x044c 0x0439 Kiszolgálószinten nem érhető el
máltai (Málta) 0x043a 0x043a Latin1_General_CI_AI
Maori (Új-Zéland) 0x0481 0x0481 Latin1_General_CI_AI
Mapudungun (Chile) 0x047a 0x047a Latin1_General_CI_AI
marathi (India) 0x044e 0x0439 Kiszolgálószinten nem érhető el
Mohawk (Kanada) 0x047c 0x047c Latin1_General_CI_AI
Mongol (Mongólia) 0x0450 0x0419 Cyrillic_General_CI_AS
Mongol (Kínai Népköztársaság) 0x0850 0x0419 Cyrillic_General_CI_AS
Nepáli (Nepál) 0x0461 0x0461 Kiszolgálószinten nem érhető el
Norvég (Bokmål, Norvégia) 0x0414 0x0414 Latin1_General_CI_AI
Nynorsk norvég nyelv (Norvégia) 0x0814 0x0414 Latin1_General_CI_AI
Occitan (Franciaország) 0x0482 0x040c French_CI_AS
Odia (India) 0x0448 0x0439 Kiszolgálószinten nem érhető el
Pashto (Afganisztán) 0x0463 0x0463 Kiszolgálószinten nem érhető el
Perzsa (Irán) 0x0429 0x0429 Latin1_General_CI_AI
Lengyel (Lengyelország) 0x0415 0x0415 Polish_CI_AS
Portugál (Brazília) 0x0416 0x0409 Latin1_General_CI_AS
Portugál nyelv (Portugália) 0x0816 0x0409 Latin1_General_CI_AS
pandzsábi (India) 0x0446 0x0439 Kiszolgálószinten nem érhető el
Quechua (Bolívia) 0x046b 0x0409 Latin1_General_CI_AS
Quechua (Ecuador) 0x086b 0x0409 Latin1_General_CI_AS
Quechua (Peru) 0x0c6b 0x0409 Latin1_General_CI_AS
Román (Románia) 0x0418 0x0418 Romanian_CI_AS
Romansh (Svájc) 0x0417 0x0417 Latin1_General_CI_AI
Orosz (Oroszország) 0x0419 0x0419 Cyrillic_General_CI_AS
Sahka (Oroszország) 0x0485 0x0485 Latin1_General_CI_AI
Sami (Inari, Finnország) 0x243b 0x083b Latin1_General_CI_AI
Sami (Lule, Norvégia) 0x103b 0x043b Latin1_General_CI_AI
Sami (Lule, Svédország) 0x143b 0x083b Latin1_General_CI_AI
Sami (Észak-, Finnország) 0x0c3b 0x083b Latin1_General_CI_AI
Sami (Észak-, Norvégia) 0x043b 0x043b Latin1_General_CI_AI
Sami (Északi, Svédország) 0x083b 0x083b Latin1_General_CI_AI
Sami (Skolt, Finnország) 0x203b 0x083b Latin1_General_CI_AI
Sami (Dél-, Norvégia) 0x183b 0x043b Latin1_General_CI_AI
Sami (Dél-, Svédország) 0x1c3b 0x083b Latin1_General_CI_AI
Szanszkrit (India) 0x044f 0x0439 Kiszolgálószinten nem érhető el
Szerb (Bosznia-Hercegovina, cirill betűs) 0x1c1a 0x0c1a Latin1_General_CI_AI
Szerb (Bosznia és Hercegovina, Latin) 0x181a 0x081a Latin1_General_CI_AI
Szerb (Szerbia, cirill betűs) 0x0c1a 0x0c1a Latin1_General_CI_AI
Szerb (szerbiai, latin) 0x081a 0x081a Latin1_General_CI_AI
Sesotho sa Leboa/Northern Sotho (Dél-Afrika) 0x046c 0x0409 Latin1_General_CI_AS
Setswana/Tswana (Dél-Afrika) 0x0432 0x0409 Latin1_General_CI_AS
Sinhala (Sri Lanka) 0x045b 0x0439 Kiszolgálószinten nem érhető el
Szlovák (Szlovákia) 0x041b 0x041b Slovak_CI_AS
Szlovén nyelv (Szlovénia) 0x0424 0x0424 Slovenian_CI_AS
Spanyol (Argentína) 0x2c0a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Bolívia) 0x400a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Chile) 0x340a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Kolumbia) 0x240a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Costa Rica) 0x140a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Dominikai Köztársaság) 0x1c0a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Ecuador) 0x300a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Salvador) 0x440a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Guatemala) 0x100a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Honduras) 0x480a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Mexikó) 0x080a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Nicaragua) 0x4c0a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Panama) 0x180a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Paraguay) 0x3c0a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Peru) 0x280a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Puerto Rico) 0x500a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Spanyolország) 0x0c0a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Spanyolország, hagyományos rendezés) 0x040a 0x040a Traditional_Spanish_CI_AS
Spanyol (Egyesült Államok) 0x540a 0x0409 Latin1_General_CI_AS
Spanyol (Uruguay) 0x380a 0x0c0a Modern_Spanish_CI_AS
Spanyol (Venezuela) 0x200a 0x0c0a Modern_Spanish_CI_AS
Szuahél (Kenya) 0x0441 0x0409 Latin1_General_CI_AS
Svéd (Finnország) 0x081d 0x040b Finnish_Swedish_CI_AS
Svéd (Svédország) 0x041d 0x040b Finnish_Swedish_CI_AS
Szíriak (Szíria) 0x045a 0x045a Kiszolgálószinten nem érhető el
Tádzsik (Tádzsikisztán) 0x0428 0x0419 Cyrillic_General_CI_AS
Tamazight (Algéria, Latin) 0x085f 0x085f Latin1_General_CI_AI
tamil (India) 0x0449 0x0439 Kiszolgálószinten nem érhető el
Tatár (Oroszország) 0x0444 0x0444 Cyrillic_General_CI_AS
telugu (India) 0x044a 0x0439 Kiszolgálószinten nem érhető el
Thai (Thaiföld) 0x041e 0x041e Thai_CI_AS
Tibeti (Kínai Népköztársaság) 0x0451 0x0451 Kiszolgálószinten nem érhető el
Törökország (Török) 0x041f 0x041f Turkish_CI_AS
türkmén (Türkmenisztán) 0x0442 0x0442 Latin1_General_CI_AI
Ujgur (KNR) 0x0480 0x0480 Latin1_General_CI_AI
Ukrán nyelv (Ukrajna) 0x0422 0x0422 Ukrainian_CI_AS
Felső Sorbian (Németország) 0x042e 0x042e Latin1_General_CI_AI
Urdu (Pakisztán) 0x0420 0x0420 Latin1_General_CI_AI
Üzbegisztán (Üzbegisztán, cirill betűs) 0x0843 0x0419 Cyrillic_General_CI_AS
Üzbég (Üzbegisztán, latin) 0x0443 0x0443 Uzbek_Latin_90_CI_AS
Vietnámi nyelv (Vietnám) 0x042a 0x042a Vietnamese_CI_AS
Welsh (Egyesült Királyság) 0x0452 0x0452 Latin1_General_CI_AI
Wolof (Szenegál) 0x0488 0x040c French_CI_AS
Xhosa/isiXhosa (Dél-Afrika) 0x0434 0x0409 Latin1_General_CI_AS
Yi (KNK) 0x0478 0x0409 Latin1_General_CI_AS
Yoruba (Nigéria) 0x046a 0x0409 Latin1_General_CI_AS
Zulu/isiZulu (Dél-Afrika) 0x0435 0x0409 Latin1_General_CI_AS

Miután hozzárendelt egy rendezést a kiszolgálóhoz, csak úgy módosíthatja, hogy exportálja az összes adatbázis-objektumot és adatot, újraépíti a master adatbázist, és importálja az összes adatbázis-objektumot és adatot. Az SQL Server egy példányának alapértelmezett rendezése helyett megadhatja a kívánt rendezést egy új adatbázis vagy adatbázisoszlop létrehozásakor.

Az SQL Server egy példányának kiszolgálóütemezésének lekérdezéséhez használja a SERVERPROPERTY függvényt:

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

Az összes elérhető kollázs lekérdezéséhez használja a következő fn_helpcollations() beépített függvényt.

SELECT *
FROM sys.fn_helpcollations();

Adatbázisszintű rendezések

Adatbázis létrehozásakor vagy módosításakor a COLLATE vagy CREATE DATABASE utasítás ALTER DATABASE záradékával megadhatja az alapértelmezett adatbázis-rendezést. Ha nincs megadva kolláció, az adatbázishoz a kiszolgáló kollációja van hozzárendelve.

A rendszeradatbázisok rendezése csak akkor módosítható, ha módosítja a kiszolgáló rendezési rendszerét.

  • Az SQL Serverben és a felügyelt Azure SQL-példányban az adatbázis-rendezés az adatbázis összes metaadataihoz használatos, a rendezés pedig az alapértelmezett érték az adatbázisban használt összes sztringoszlop, ideiglenes objektum, változónév és egyéb sztring esetében.
  • Az Azure SQL Database-ben nincs kiszolgálói rendezés, ezért minden adatbázishoz tartozik egy rendezés az adatokhoz és egy rendezés a katalógushoz. A CATALOG_COLLATION az adatbázis metaadataihoz használatos, a rendezés pedig alapértelmezés szerint az adatbázisban használt összes karakterlánc oszlop, ideiglenes objektum, változók neve és egyéb karakterlánc esetében. A CATALOG_COLLATION létrehozáskor van beállítva, és nem módosítható.

Ha módosítja egy felhasználói adatbázis rendezését, rendezési ütközések léphetnek fel, amikor az adatbázis lekérdezései ideiglenes táblákhoz férnek hozzá. Az ideiglenes táblák mindig a tempdb rendszeradatbázisban vannak tárolva, amely a példány számára beállított rendezési sorrendet használja. A felhasználói adatbázis és a tempdb közötti karakteradatokat összehasonlító lekérdezések meghiúsulhatnak, ha a rendezések ütközést okoznak a karakteradatok kiértékelése során. Ezt a problémát a lekérdezés COLLATE záradékának megadásával oldhatja meg. További információ: COLLATE.

A felhasználói adatbázisok rendezése az alábbi kódmintához hasonló ALTER DATABASE utasítással módosítható:

ALTER DATABASE myDB COLLATE Greek_CS_AI;

Important

Az adatbázisszintű rendezés módosítása nem befolyásolja az oszlopszintű vagy kifejezésszintű rendezéseket. Ez nincs hatással a meglévő oszlopokban lévő adatokra.

Az adatbázis aktuális rendezése az alábbi kódmintához hasonló utasítással kérhető le:

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

Oszlopszintű rendezések

Táblázat létrehozásakor vagy módosításakor a COLLATE záradék használatával rendezéseket adhat meg az egyes karakter-sztringoszlopokhoz. Ha nem ad meg rendezést, az oszlop az adatbázis alapértelmezett rendezési eleméhez lesz rendelve.

Az oszlop rendezést az alábbi kódmintához hasonló ALTER TABLE utasítással módosíthatja:

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

Kifejezésszintű rendezések

A kifejezésszintű rendezések egy utasítás futtatásakor vannak beállítva, és hatással vannak az eredményhalmaz visszaadásának módjára. Ez lehetővé teszi ORDER BY rendezési eredmények területi beállítását. A kifejezésszintű rendezések implementálásához használjon egy COLLATE záradékot, például a következő kódmintát:

SELECT name
FROM customer
ORDER BY name COLLATE Latin1_General_CS_AI;

Locale

A helyi sajátosság egy helyhez vagy kultúrához társított információkészlet. Az információk között szerepelhet a beszélt nyelv neve és azonosítója, a nyelv írásához használt szkript, valamint a kulturális konvenciók. A rendezések egy vagy több nyelvi területekhez társíthatók. További információ: Microsoftáltal hozzárendelt területi azonosítók.

Kódlap

A kódlap egy adott szkript karaktereinek rendezett halmaza, amelyben numerikus index vagy kódpontérték van társítva minden karakterhez. A Windows-kódlapokat általában karakterkészletnek nevezzük, vagy karakterkészletnek. A kódlapok a különböző Windows-rendszer területi beállításai által használt karakterkészletek és billentyűzetkiosztások támogatásához használhatók.

Rendezési sorrend

A rendezési sorrend az adatértékek rendezésének módját határozza meg. A sorrend hatással van az adat-összehasonlítás eredményeire. Az adatok összehasonlításokkal történik, és indexek alkalmazásával válik optimalizálhatóvá.

Unicode-támogatás

A Unicode a karakterekre mutató kódpontok leképezésének szabványa. Mivel úgy tervezték, hogy a világ összes nyelvének összes karakterét lefedje, nincs szükség különböző kódlapokra a különböző karakterkészletek kezeléséhez.

A Unicode alapjai

Az adatok több nyelven való tárolása egy adatbázisban nehéz, ha csak karakteradatokat és kódlapokat használ. Az adatbázis egyetlen kódlapját is nehéz megtalálni, amely képes tárolni az összes szükséges nyelvspecifikus karaktert. Emellett nehéz garantálni a speciális karakterek megfelelő fordítását, amikor különböző kódlapokat futtató ügyfelek olvassák vagy frissítik őket. A nemzetközi ügyfeleket támogató adatbázisoknak mindig Unicode-adattípusokat kell használniuk a nem Unicode-adattípusok helyett.

Vegyük például az észak-amerikai ügyfelek adatbázisát, amelynek három fő nyelvet kell kezelnie:

  • Mexikó spanyol nevei és címei
  • Quebec francia nevei és címei
  • Kanada és az Egyesült Államok többi részének angol nevei és címei

Ha csak karakteroszlopokat és kódlapokat használ, ügyeljen arra, hogy az adatbázis olyan kódlapra legyen telepítve, amely mindhárom nyelv karaktereit kezeli. Ügyelnie kell arra is, hogy a karakterek bármely nyelvről való megfelelő fordítása biztosított legyen, amikor a karaktereket olyan ügyfelek olvassák, amelyek egy másik nyelv kódlapját futtatják.

Note

Az ügyfél által használt kódlapokat az operációs rendszer (OS) beállításai határozzák meg. Ha ügyfélkódlapokat szeretne beállítani a Windows operációs rendszeren, használja Területi beállítások a Vezérlőpulton.

Nehéz lenne olyan kódlapot választani a karakteradat-típusokhoz, amelyek támogatják a globális közönség által megkövetelt karaktereket. A karakteradatok nemzetközi adatbázisokban való kezelésének legegyszerűbb módja a Unicode-ot támogató adattípus használata.

Unicode-adattípusok

Ha több nyelvet tükröző karakteradatokat tárol az SQL Serverben (SQL Server 2005 (9.x) és újabb verziókban), használjon Unicode-adattípusokat (nchar, nvarchar, és ntext) nem Unicode-adattípusok helyett (karakter, varcharés szöveges).

Note

Unicode adattípusok esetén az Adatbázis Motor legfeljebb 65 536 karaktert képes megjeleníteni UCS-2 használatával, vagy a teljes Unicode tartományt (1,114,112 karakter), ha kiegészítő karaktereket is használunk. További információ a kiegészítő karakterek engedélyezéséről: Kiegészítő karakterek.

Másik lehetőségként az SQL Server 2019-től kezdve (15.x) UTF-8-kompatibilis rendezés (_UTF8) használata esetén a korábban nem Unicode-adattípusok (karakteres és varchar) Unicode-adattípusokká válnak UTF-8 kódolással. Az SQL Server 2019 (15.x) nem módosítja a korábban meglévő Unicode-adattípusok (nchar, nvarcharés ntext) viselkedését, amelyek továbbra is UCS-2 vagy UTF-16 kódolást használnak. További információ: Tárolási különbségek az UTF-8 és az UTF-16között.

Unicode-szempontok

Jelentős korlátozások vannak társítva a nem Unicode-adattípusokhoz. Ennek az az oka, hogy a nem Unicode rendszerű számítógépek egyetlen kódlap használatára korlátozódnak. A Unicode használatával teljesítménynövekedést tapasztalhat, mivel kevesebb kódlapkonverzióra van szükség. A Unicode-rendezéseket külön-külön kell kijelölni az adatbázis, az oszlop vagy a kifejezés szintjén, mert a kiszolgáló szintjén nem támogatottak.

Amikor adatokat helyez át egy kiszolgálóról egy ügyféloldalra, előfordulhat, hogy a régebbi ügyfélillesztők nem ismerik fel a kiszolgáló kollációját. Ez akkor fordulhat elő, ha adatokat helyez át Unicode-kiszolgálóról nem Unicode-ügyfélre. A legjobb megoldás lehet az ügyfél operációs rendszerének frissítése az alapul szolgáló rendszerütemezések frissítése érdekében. Ha az ügyfél rendelkezik telepített adatbázis-ügyfélszoftverrel, érdemes lehet egy szolgáltatásfrissítést alkalmazni az adatbázis-ügyfélszoftverre.

Tip

Próbálja meg a kiszolgálón lévő adatokhoz másik rendezési módot használni. Válasszon egy rendezést, amely leképez egy ügyféloldali kódlapra. Ha az SQL Serverben (SQL Server 2012 (11.x) és újabb verziókban elérhető UTF-16 rendezéseket szeretné használni egyes Unicode-karakterek keresésének és rendezésének javítására (csak Windows-rendezések esetén), kiválaszthatja a kiegészítő karakterek (_SC) vagy a 140-es verziójú rendezések egyikét.

Az SQL Server 2019-ben elérhető UTF-8 rendezés (15.x) használatához, valamint egyes Unicode-karakterek keresésének és rendezésének javításához (csak Windows-rendezések esetén) az UTF-8 kódolásra alkalmas rendezéseket (_UTF8) kell választania.

  • Az UTF8 jelző a következőre alkalmazható:

    • Olyan nyelvi összehasonlítások, amelyek már támogatják a kiegészítő karaktereket (_SC) vagy a változatválasztó-érzékeny (_VSS) érzékenységet.
    • BIN2 bináris kolláció

  • Az UTF8 jelző nem alkalmazható a következőre:

    • Olyan nyelvi rendezések, amelyek nem támogatják a kiegészítő karaktereket (_SC) vagy a változatválasztó-érzékenységet (_VSS)
    • A BIN bináris kollációi
    • A SQL_* kollációk

A Unicode- vagy nem Unicode-adattípusok használatával kapcsolatos problémák kiértékeléséhez tesztelje a forgatókönyvet a környezetben tapasztalható teljesítménybeli különbségek méréséhez. Ajánlott szabványosítani a szervezet rendszereiben használt rendezést, és ahol csak lehetséges, Unicode-kiszolgálókat és ügyfeleket üzembe helyezni.

Az SQL Server sok esetben más kiszolgálókkal vagy ügyfelekkel is kommunikál, és a szervezet több adatelérési szabványt is használhat az alkalmazások és a kiszolgálópéldányok között. Az SQL Server-ügyfelek két fő típus egyikét képezik:

  • Unicode-ügyfelek, amelyek az OLE DB és az Open Database Connectivity (ODBC) 3.7-es vagy újabb verzióját használják.
  • nem Unicode-ügyfelek, amelyek DB-Library és ODBC 3.6-os vagy korábbi verzióját használják.

Az alábbi táblázat a többnyelvű adatok Unicode- és nem Unicode-kiszolgálók különböző kombinációival való használatáról nyújt tájékoztatást:

Server Client Előnyök vagy korlátozások
Unicode Unicode Mivel a Unicode-adatokat a rendszer egészében használják, ez a forgatókönyv biztosítja a legjobb teljesítményt és védelmet a beolvasott adatok sérülése ellen. Ez a helyzet az ActiveX Data Objects (ADO), az OLE DB és az ODBC 3.7-es vagy újabb verziójával.
Unicode Non-Unicode Ebben a forgatókönyvben, különösen az újabb operációs rendszert futtató kiszolgáló és az SQL Server egy korábbi verzióját futtató ügyfél vagy egy régebbi operációs rendszer közötti kapcsolatok esetén korlátozások vagy hibák léphetnek fel, amikor adatokat helyez át egy ügyfélszámítógépre. A kiszolgálón lévő Unicode-adatok a nem Unicode-ügyfél megfelelő kódlapjával próbálják megfeleltetni az adatok konvertálásához.
Non-Unicode Unicode Ez nem ideális konfiguráció többnyelvű adatok használatához. Unicode-adatokat nem írhat a nem Unicode-kiszolgálóra. A problémák valószínűleg akkor fordulnak elő, ha a rendszer a kiszolgáló kódlapján kívül eső kiszolgálókra küld adatokat.
Non-Unicode Non-Unicode Ez egy nagyon korlátozó forgatókönyv a többnyelvű adatok esetében. Csak egyetlen kódlapot használhat.

Kiegészítő karakterek

A Unicode Consortium minden karakterhez egy egyedi kódpontot rendel, amely a 000000–10FFFF tartományban lévő érték. A leggyakrabban használt karakterek kódpontértékekkel rendelkeznek a 000000–00FFFF (65 536 karakter) tartományban, amelyek egy 8 bites vagy 16 bites szóhoz illeszkednek a memóriában és a lemezen. Ez a tartomány általában alapszintű többnyelvű síkként (BMP) van kijelölve.

A Unicode Consortium azonban további 16 karakterből álló "síkot" hozott létre, ezek mérete megegyezik a BMP-vel. Ez a definíció lehetővé teszi a Unicode számára, hogy 1 114 112 karaktert (azaz 216 * 17 karaktert) képviseljen a kódponttartományon belül 000000 és 10FFFF között. A 00FFFF-nél nagyobb kódpontértékkel rendelkező karakterekhez két-négy egymást követő 8 bites szóra (UTF-8) vagy két egymást követő 16 bites szóra (UTF-16) van szükség. Ezeket a BMP-t követő karaktereket kiegészítő karakterekneknevezik, a további egymást követő 8 bites vagy 16 bites szavakat pedig helyettesítő pároknak. További információ a kiegészítő karakterekről, a helyettesítőkről és a helyettesítő párokról: a Unicode Standard.

Az SQL Server olyan adattípusokat biztosít, mint nchar és nvarchar Unicode-adatok tárolására a BMP-tartományban (000000 – 00FFFF), amelyet az adatbázismotor az UCS-2 használatával kódol.

Az SQL Server 2012 (11.x) bevezetett egy új, kiegészítő karaktercsaládot (_SC), amely a nchar, nvarcharés sql_variant adattípusokkal használható a teljes Unicode-karaktertartomány (000000 – 10FFFF) megjelenítéséhez. Például: Latin1_General_100_CI_AS_SC, vagy ha japán rendezést használ, Japanese_Bushu_Kakusu_100_CI_AS_SC.

Az SQL Server 2019 (15.x) kiegészítő karaktertámogatást nyújt a karakteres és varchar adattípusokhoz az új UTF-8-kompatibilis rendezésekkel (_UTF8). Ezek az adattípusok a Teljes Unicode-karaktertartományt is képesek képviselni.

Note

Az SQL Server 2017-től kezdve (14.x) minden új rendezés automatikusan támogatja a kiegészítő karaktereket.

Ha kiegészítő karaktereket használ:

  • Kiegészítő karakterek használhatók a rendezési és összehasonlítási műveletekhez a 90-as vagy újabb rendezési verziókban.

  • Minden verzió 100-as összehasonlítás támogatja a nyelvi sorrendiséget többlet karakterekkel.

  • A kiegészítő karakterek nem használhatók metaadatokban, például adatbázis-objektumok neveiben.

  • Az SC-jelző a következőre alkalmazható:

    • 90-es verziójú rendezések
    • 100-es verziójú rendezések

  • Az SC-jelző nem alkalmazható a következőre:

    • Nem verziószámozott Windows-rendezések, 80-as verzió
    • A BIN vagy BIN2 bináris kollációk
    • Az SQL* összevetései
    • 140-es verziójú rendezések (ezekhez nincs szükség az SC-jelzőre, mert már támogatják a kiegészítő karaktereket)

Az alábbi táblázat összehasonlítja egyes sztringfüggvények és sztringoperátorok viselkedését, ha kiegészítő karaktereket használnak kiegészítő karakterérzékeny (SCA) rendezéssel és anélkül:

Sztring függvény vagy operátor SCA-rendezéssel SCA-rendezés nélkül
CHARINDEX

LEN
PATINDEX		 Az UTF-16 helyettesítő pár egyetlen kódpontnak számít. Az UTF-16 helyettesítő pár két kódpontnak számít.
LEFT

REPLACE
REVERSE
RIGHT
SUBSTRING
STUFF		 Ezek a függvények az egyes helyettesítő párokat egyetlen kódpontként kezelik, és a várt módon működnek. Ezek a függvények feloszthatják a helyettesítő párokat, és váratlan eredményekhez vezethetnek.
NCHAR A 0 – 0x10FFFF tartományban megadott Unicode-kódpont értékének megfelelő karaktert adja vissza. Ha a megadott érték a 0 – 0xFFFF tartományban található, a rendszer egy karaktert ad vissza. Magasabb értékek esetén a függvény a megfelelő helyettesítő értéket adja vissza. 0xFFFF-nál magasabb érték esetén NULL kerül visszaadásra a megfelelő helyettesítő helyett.
UNICODE UTF-16 kódpontot ad vissza a 0 – 0x10FFFF tartományban. Egy UCS-2 kódpontot ad vissza a 0 – 0xFFFF tartományban.
Egy karakteres helyettesítő karakter

Helyettesítő karakter – Nem egyező karakter(ek)		 A kiegészítő karakterek minden wildcard művelethez támogatottak. A kiegészítő karakterek nem támogatottak ezekhez a helyettesítési műveletekhez. Más helyettesítő karakterek is vannak támogatva.

GB18030 támogatás

GB18030 egy külön szabvány, amelyet a Kínai Népköztársaságban használnak a kínai karakterek kódolására. A GB18030 a karakterek hossza 1, 2 vagy 4 bájt lehet. Az SQL Server támogatja GB18030 kódolt karaktereket azáltal, hogy felismeri őket, amikor ügyféloldali alkalmazásból lépnek be a kiszolgálóra, és natívan Unicode-karakterekként konvertálják és tárolják őket. Miután a kiszolgálón tárolták őket, a rendszer Unicode-karakterekként kezeli őket a későbbi műveletek során.

Bármilyen kínai rendezési sorrendet használhat, lehetőleg a legújabb 100-as verziót. Minden 100-as verziójú kolláció támogatja a nyelvi sorrendbe állítást a GB18030 karakterekkel. Ha az adatok kiegészítő karaktereket (helyettesítő párokat) tartalmaznak, az SQL Serverben elérhető SC-rendezésekkel javíthatja a keresést és a rendezést.

Note

Győződjön meg arról, hogy az ügyféleszközök( például az SQL Server Management Studio) a Dengxian betűtípussal megfelelően jelenítik meg a GB18030 kódolt karaktereket tartalmazó sztringeket.

Összetett szkriptek támogatása

Az SQL Server támogatja az összetett szkriptek bevitelét, tárolását, módosítását és megjelenítését. Az összetett szkriptek a következő típusokat tartalmazzák:

  • Olyan szkriptek, amelyek a jobbról balra és a balról jobbra szöveg kombinációját is tartalmazzák, például az arab és az angol szöveg kombinációját.
  • Azok a szkriptek, amelyek karakterei a pozíciójuktól függően változnak, vagy ha más karakterekkel, például arab, indiai és thai karakterekkel vannak kombinálva.
  • Olyan nyelvek, mint például a thai, amelyekhez belső szótárakra van szükség a szavak felismeréséhez, mert nincs közöttük törés.

Az SQL Serverrel kommunikáló adatbázis-alkalmazásoknak összetett szkripteket támogató vezérlőket kell használniuk. A felügyelt kódban létrehozott szabványos Windows-űrlapvezérlők összetett parancsfájlokkal kompatibilisek.

Japán kollációk hozzáadva az SQL Server 2017-ben

Az SQL Server 2017-től kezdődően (14.x) új japán rendezési családok támogatottak, különféle opciók kombinációival (_CS, _AS, _KS, _WSés _VSS), valamint _BIN és _BIN2.

Az összevetések listázásához lekérdezheti az SQL Server adatbázismotort.

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

Az összes új kolláció beépített támogatást nyújt a kiegészítő karakterekhez, így az új 140 kollációk egyike sem rendelkezik (vagy van szüksége) az SC-jelölőre.

Ezeket a rendezéseket az adatbázismotor-indexek, a memóriaoptimalizált táblák, az oszlopcentrikus indexek és a natívan lefordított modulok támogatják.

Rendezés az Azure SQL Database-ben

Nem módosíthatja vagy állíthatja be a logikai kiszolgáló rendezést az Azure SQL Database-ben, de konfigurálhatja az egyes adatbázisok rendezési beállításait az adatokhoz és a katalógushoz egyaránt. A katalógus rendezése határozza meg a rendszer metaadatainak, például az objektumazonosítóknak a rendezést. Mindkét kolláció egymástól függetlenül adható meg, amikor létrehozod az adatbázist az Azure portálon, T-SQL-lel a CREATE DATABASEparancs segítségével, vagy PowerShell-lel a New-AzSqlDatabaseparancs segítségével.

Kollációk az Azure SQL felügyelt példányban

A felügyelt Azure SQL-példány kiszolgálószintű rendezése a példány létrehozásakor adható meg, és később nem módosítható.

További információért lásd a Kiszolgáló kolláció beállítása vagy módosításarészt.

Kolláció a Microsoft Fabricben

A Microsoft Fabric Data Warehouse-ban csak a következő rendezések engedélyezettek: Latin1_General_100_BIN2_UTF8 és Latin1_General_100_CI_AS_KS_WS_SC_UTF8.

A Microsoft Fabric SQL-adatbázisában alapértelmezés szerint a rendezés SQL_Latin1_General_CP1_CI_AS, amely jelenleg nem módosítható. Az egyes oszlopok kollációi támogatottak.

UTF-8-támogatás

Az SQL Server 2019 (15.x) teljes körű támogatást nyújt a széles körben használt UTF-8 karakterkódoláshoz importálási vagy exportálási kódolásként, valamint a sztringadatok adatbázisszintű vagy oszlopszintű rendezéseként. Az UTF-8 a karakteres és varchar adattípusokban engedélyezett, és akkor engedélyezve van, ha egy objektum rendezést hoz létre vagy módosít egy UTF8 utótagot tartalmazó rendezésre. Ilyen például a Latin1_General_100_CI_AS_SC módosítása Latin1_General_100_CI_AS_SC_UTF8.

Az UTF-8 csak az SQL Server 2012-ben (11.x) bevezetett kiegészítő karaktereket támogató Windows-rendezésekhez érhető el. A nchar és nvarchar adattípusok csak UCS-2 vagy UTF-16 kódolást tesznek lehetővé, és változatlanok maradnak.

Az Azure SQL Database és a felügyelt Azure SQL-példány is támogatja az UTF-8-at adatbázis- és oszlopszinten, míg a felügyelt SQL-példány ezt kiszolgálószinten is támogatja.

Tárolási különbségek az UTF-8 és az UTF-16 között

A Unicode Consortium minden karakterhez egy egyedi kódpontot rendel, amely a 000000–10FFFF tartományban lévő érték. Az SQL Server 2019 (15.x) használatával az UTF-8 és az UTF-16 kódolás is elérhető a teljes tartomány megjelenítéséhez:

  • Az UTF-8 kódolás esetén az ASCII-tartomány karakterei (000000 – 00007F) 1 bájtot, a kódpontok 000080 – 0007FF 2 bájtot igényelnek, a kódpontok 000800 – 00FFFF 3 bájtot, a kódpontok pedig 0010000 – 0010FFFF 4 bájtot igényelnek.
  • Az UTF-16 kódolással a kódpontok 0000000 – 00FFFF 2 bájtot igényelnek, a kódpontok pedig 0010000 – 0010FFFF 4 bájtot igényelnek.

Az alábbi táblázat felsorolja az egyes karaktertartományokhoz és kódolási típusokhoz tartozó kódolási tárbájtokat:

Kódtartomány (hexadecimális) Kódtartomány (decimális) Tárolt bájtok 1 UTF-8 használatával Tárolási bájtok 1 UTF-16-tal
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 – 03FFFF 2

040000 – 10FFFF 2		 65 536 – 262 143 2
262 144 – 1 114 111 2		 4 4

1tárolási bájtok a kódolt bájthosszra vonatkoznak, nem a lemezen tárolt adattípus méretére. További információ a lemezen tárolt tárhelyméretekről: nchar és nvarchar és char és varchar.

2 Az kiegészítő karakterek kódponttartománya.

Tip

Gyakran előforduló vélemény, hogy a karakter és varchar vagy a nchar és nvarchartípusoknál az n határozza meg a karakterek számát. Ennek az az oka, hogy egy karakter(10) oszlop példájában a 0–127 tartomány 10 ASCII-karaktere tárolható egy olyan rendezéssel, mint a Latin1_General_100_CI_AI, mivel ebben a tartományban minden karakter csak 1 bájtot használ. Azonban a char és varchartípusok esetén a n határozza meg a sztring méretét bájtban (0 - 8 000), míg a nchar és nvarcharesetén a n a bájtpárokban határozza meg a sztring méretét (0 - 4 000). n soha nem határoz meg tárolható karakterek számát.

A megfelelő Unicode-kódolás és adattípus kiválasztása jelentős tárolási megtakarítást eredményezhet, vagy növelheti az aktuális tárterület-lábnyomot a használatban lévő karaktertől függően. Ha például olyan latin rendezést használ, amely engedélyezve van az UTF-8-ban, például Latin1_General_100_CI_AI_SC_UTF8, egy karakter(10) oszlop 10 bájtot tárol, és 10 ASCII-karaktert tartalmazhat a 0 és 127 közötti tartományban. A 128–2047 tartományban azonban csak öt karaktert tartalmazhat, a 2048–65535 tartományban pedig csak három karaktert. Összehasonlításképpen, mivel egy nchar(10) oszlop 10 bájtpárt (20 bájtot) tárol, 10 karaktert tartalmazhat a 0 és 65535 közötti tartományban.

Mielőtt eldöntené, hogy UTF-8 vagy UTF-16 kódolást használ-e egy adatbázishoz vagy oszlophoz, fontolja meg a tárolt sztringadatok eloszlását:

  • Ha ez többnyire a 0 és 127 közötti ASCII-tartományban van (például angol), minden karakterhez 1 bájt UTF-8 és 2 bájt UTF-16 értékre van szükség. Az UTF-8 használata tárolási előnyöket biztosít. Ha egy meglévő oszlop adattípusát ASCII-karakterekkel módosítja a 0 –127 tartományban nchar(10)char(10)értékre, és UTF-8-kompatibilis rendezés használatával 50%-kal csökkenti a tárolási követelményeket. Ennek az az oka, hogy nchar(10) 20 bájtot igényel a tároláshoz, szemben a karakter(10), amely 10 bájtot igényel ugyanahhoz a Unicode-sztring-ábrázoláshoz.
  • Az ASCII-tartomány felett szinte minden latin-alapú szkript, valamint a görög, cirill, kopt, örmény, héber, arab, szír, tāna és N'Ko karakterenként 2 bájtot igényelnek az UTF-8 és az UTF-16 karakterenként. Ezekben az esetekben a hasonló adattípusok (például karakter vagy nchar) esetében nincs jelentős tárolási különbség.
  • Ha ez többnyire kelet-ázsiai szkript (például koreai, kínai és japán), minden karakterhez 3 bájt UTF-8 és 2 bájt UTF-16 kell. Az UTF-16 használata tárolási előnyöket biztosít.
  • A 010000–10FFFF tartományban lévő karakterek 4 bájtot igényelnek mind az UTF-8, mind az UTF-16 tartományban. Ezekben az esetekben nincs tárolási különbség az összehasonlítható adattípusok között (például char vagy ncharesetén).

További megfontolásokért lásd: Nemzetközi Transact-SQL Nyilatkozatok.

Konvertálás UTF-8-ra

Mivel char és varchar vagy nchar és nvarcharesetén az n határozza meg a bájttárolási méretet, nem pedig a tárolható karakterek számát, fontos meghatározni az adattípus méretét, amelyre konvertálnia kell. A méretet meghaladó karaktereket le kell vágni.

Vegyük például az nvarchar(100) definiált oszlopot, amely 180 bájt japán karaktert tárol. Ebben a példában az oszlopadatok kódolása jelenleg UCS-2 vagy UTF-16 használatával történik, amely karakterenként 2 bájtot használ. Az oszloptípus varchar(200) konvertálása nem elegendő az adat csonkolásának megakadályozásához, mivel az új adattípus csak 200 bájtot képes tárolni, a japán karakterek azonban 3 bájtot igényelnek az UTF-8 kódolása esetén. Az oszlopot varchar(270) kell definiálni az adat csonkoláson keresztüli adatvesztés elkerülése érdekében.

Ezért előre tudnia kell, hogy mi az oszlopdefiníció tervezett bájtmérete, mielőtt a meglévő adatokat UTF-8-ra konvertálja, és ennek megfelelően módosítania kell az új adattípus méretét. A Transact-SQL szkriptben vagy az SQL Notebookban, amely megtalálható a adatminta GitHuboldalán, használja a DATALENGTH függvényt és a COLLATE utasítást az UTF-8 konverziós műveletekhez szükséges adathossz-követelmények meghatározásához egy meglévő adatbázisban.

Ha egy meglévő táblában módosítani szeretné az oszlopelegyezést és az adattípust, használja az Oszlopelegyezés beállítása vagy módosításacímű cikkben ismertetett módszerek egyikét.

Ha módosítani szeretné az adatbázis-rendezést, lehetővé teszi az új objektumok számára az adatbázis-rendezés alapértelmezés szerinti öröklődését, vagy módosíthatja a kiszolgáló rendezést, lehetővé téve, hogy az új adatbázisok alapértelmezés szerint örökölje a rendszer rendezést, tekintse meg a cikk Kapcsolódó feladatok szakaszát.

Task Article
Az SQL Server-példány rendezési beállításának vagy módosításának módját ismerteti. A kiszolgáló rendezésének módosítása nem módosítja a meglévő adatbázisok rendezést. Kiszolgáló rendezési beállítása vagy módosítása
A felhasználói adatbázisok rendezési beállításának vagy módosításának módját ismerteti. Az adatbázis-rendezés módosítása nem módosítja a meglévő táblaoszlopok rendezési módját. Adatbázis-rendezési beállítása vagy módosítása
Azt ismerteti, hogyan állíthatja be vagy módosíthatja egy oszlop rendezési módját az adatbázisban. Az oszlop karakterkészlet-összerendelésének beállítása vagy módosítása
Ez a cikk azt ismerteti, hogyan ad vissza rendezési adatokat a kiszolgáló, adatbázis vagy oszlop szintjén. Kollációs információk megtekintése
Ismerteti, hogyan írhat Transact-SQL olyan utasításokat, amelyek hordozhatóbbak az egyik nyelvről a másikra, vagy hogyan támogatnak könnyebben több nyelvet. Nemzetközi Transact-SQL nyilatkozatok írása
Ismerteti, hogyan módosíthatja a hibaüzenetek nyelvét, valamint a dátum-, idő- és pénznemadatok felhasználási és megjelenítési beállításait. Munkamenet nyelvének beállítása

Kapcsolódó tartalom

  • Last updated on