Podpora řazení a Unicode

platí pro:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)koncový bod SQL Analytics ve službě Microsoft FabricÚložiště v Microsoft Fabric

Sady v SQL Serveru poskytují pravidla řazení, vlastnosti citlivosti na velikost písmen a akcenty pro vaše data. Sady řazení používané s datovými typy znaků, jako například char a varchar, určují stránku kódů a odpovídající znaky, které lze reprezentovat pro daný datový typ.

Bez ohledu na to, jestli instalujete novou instanci SQL Serveru, obnovujete zálohu databáze nebo připojujete server k klientským databázím, je důležité pochopit požadavky na národní prostředí, pořadí řazení a rozlišování velkých a malých a velkých písmen u dat, se kterými pracujete. Seznam kolací, které jsou k dispozici ve vaší instanci SQL Serveru, najdete v sys.fn_helpcollations.

Když pro server, databázi, sloupec nebo výraz vyberete kolaci, přiřadíte vašim datům určité charakteristiky. Tyto charakteristiky ovlivňují výsledky mnoha operací v databázi. Například při vytváření dotazu pomocí ORDER BYmůže pořadí řazení sady výsledků záviset na kolaci použité v databázi nebo diktované v klauzuli COLLATE na úrovni výrazu dotazu.

Pokud chcete co nejlépe využít podporu kolace na SQL Serveru, měli byste porozumět pojmům definovaným v tomto článku a jejich vztahu k charakteristikám vašich dat.

Podmínky kolace

• kolace
  • sady třídění
  • úrovně kolace
• Lokalita
• znakové stránky
• pořadí řazení

Kolace

Kolace určuje bitové vzory, které představují každý znak v datové sadě. Kolace také určují pravidla, podle kterých se data třídí a porovnávají. SQL Server podporuje ukládání objektů, které mají různé kolace v jedné databázi. U sloupců, které nejsou unicode, určuje nastavení kolace znakovou stránku pro data a znaky, které mohou být reprezentovány. Data, která přesouváte mezi sloupci neobsahujícími Unicode, musí být převedena ze zdrojové znakové stránky na cílovou znakovou stránku.

Transact-SQL výsledky příkazu se mohou lišit, když se příkaz spustí v kontextu různých databází, které mají různá nastavení kolace. Pokud je to možné, použijte pro vaší organizaci standardizované řazení. Tímto způsobem nemusíte zadávat kolaci ve všech znakech nebo výrazech Unicode. Pokud musíte pracovat s objekty, které mají různá nastavení kolace a znakové stránky, navrhujte svoje dotazy tak, aby zohledňovaly pravidla přednosti kolace. Další informace naleznete v tématu Priorita kolace.

Mezi možnosti přidružené ke kolaci patří citlivost na velikost písmen, citlivost na diakritiku, citlivost na znak kana, citlivost šířky a citlivost na selektor variant. SQL Server 2019 (15.x) zavádí další možnost kódování UTF-8.

Tyto možnosti můžete zadat tak, že je připojíte k názvu řazení. Například třídění Japanese_Bushu_Kakusu_100_CS_AS_KS_WS_SC_UTF8 rozlišuje malá a velká písmena, rozlišuje diakritiku, je citlivé na rozlišování kana, šířku znaků a je kódováno v UTF-8. V dalším příkladu je kolace Japanese_Bushu_Kakusu_140_CI_AI_KS_WS_VSS nerozlišující velká a malá písmena, nerozeznávají se akcenty, rozlišující kana, citlivé na šířku, citlivé na selektor variant a používá starší znakovou stránku pro varchar.

Chování spojené s těmito různými možnostmi je popsáno v následující tabulce:

Možnost	Popis
Malá a velká písmena (_CS)	Rozlišuje velká a malá písmena. Pokud je tato možnost vybrána, malá písmena jsou seřazena před jejich velkými verzemi. Pokud tato možnost není vybraná, kolace nerozlišuje velikost písmen. To znamená, že SQL Server považuje velká a malá písmena za stejné pro účely řazení. Zadáním _CI můžete explicitně vybrat nerozlišování velkých a malých písmen.
Citlivá na zvýraznění (_AS)	Rozlišuje mezi znaky s diakritikou a bez diakritiky. Například a se nerovná ấ. Pokud tato možnost není vybraná, kolace je přízvukově necitlivá. To znamená, že SQL Server považuje zvýrazněné a neakcentované verze písmen za stejné pro účely řazení. Zadáním _AI můžete vybrat explicitně necitlivost na diakritiku.
Citlivá na Kana (_KS)	Rozlišuje mezi dvěma typy japonských znaků kana: Hiragana a Katakana. Pokud tato možnost není vybraná, kolace nerozlišuje kany. To znamená, že SQL Server považuje znaky Hiragana a Katakana za stejné pro účely řazení. Vynechání této možnosti je jediným způsobem, jak určit necitlivost na znaková písma.
Šířkově citlivá (_WS)	Rozlišuje mezi znaky s plnou šířkou a poloviční šířkou. Pokud tato možnost není vybraná, SQL Server považuje reprezentaci stejného znaku s plnou šířkou a poloviční šířkou za stejnou pro účely řazení. Vynechání této možnosti je jedinou metodou určení necitlivosti šířky.
Citlivý selektor variant (_VSS)	Rozlišuje různé ideografické selektory variant v japonských kolacích Japanese_Bushu_Kakusu_140 a Japanese_XJIS_140, které jsou zavedeny v SQL Serveru 2017 (14.x). Sekvence variant se skládá ze základního znaku a selektoru varianty. Pokud tato možnost _VSS není vybrána, kolace nereaguje na selektory variant a ty se při porovnávání neberou v úvahu. To znamená, že SQL Server považuje znaky založené na stejném základním znaku s různými selektory variant za identické při řazení. Další informace najdete v databázi ideografických variant Unicode. Kolace citlivé na výběr variant (_VSS) nejsou v indexech fulltextového vyhledávání podporované. Indexy fulltextového vyhledávání podporují pouze možnosti Accent-Sensitive (_AS), citlivé na Kana (_KS) a šířku (_WS). Sql Server XML a modulu CLR (Common Language Runtime) integrace moduly nepodporují selektory variant (_VSS).
Binární (_BIN) 1	Seřadí a porovná data v tabulkách SQL Serveru na základě bitových vzorů definovaných pro každý znak. Binární pořadí řazení rozlišuje malá a velká písmena a je citlivé na diakritiku. Binární je také nejrychlejší pořadí řazení. Další informace najdete v části binární kolace tohoto článku.
Binární bod kódu (_BIN2) 1	Seřadí a porovná data v tabulkách SQL Serveru na základě bodů kódu Unicode pro data Unicode. V případě dat, která nejsou unicode, používá bod binárního kódu porovnání, která jsou shodná s daty binárního řazení. Výhodou použití pořadí řazení bodů binárního kódu je, že v aplikacích, které porovnávají seřazená data SQL Serveru, není vyžadováno žádné resortování dat. V důsledku toho pořadí řazení bodu binárního kódu poskytuje jednodušší vývoj aplikací a možné zvýšení výkonu. Další informace najdete v části binární kolace tohoto článku.
UTF-8 (_UTF8)	Umožňuje ukládání dat kódování UTF-8 na SQL Serveru. Pokud tato možnost není vybraná, SQL Server pro příslušné datové typy používá výchozí formát kódování bez kódování Unicode. Další informace najdete v části podpora UTF-8 v tomto článku.

¹ Pokud je vybraný binární nebo binární kódový bod, nejsou dostupné možnosti rozlišující malá a velká písmena (_CS), rozlišování podle přízvuku (_AS), rozeznávání mezi verzemi Kana (_KS) a rozlišování podle šířky (_WS).

Příklady možností kolace

Každá kolace se zkombinuje jako řada přípon, které definují rozlišování malých a velkých písmen, diakritiky, šířky nebo citlivost na znaky kana. Následující příklady popisují chování pořadí řazení pro různé kombinace přípon.

Přípona kolace Windows	Popis pořadí řazení
_BIN 1	Binární třídění
_BIN2 1, 2	Pořadí řazení bodů binárního kódu
_CI_AI 2	Nerozlišující velká a malá písmena, nerozlišující diakritiku, nerozeznávající kana, nerozlišující šířku.
_CI_AI_KS 2	Nerozlišuje velikost písmen, nerozlišuje přízvuky, citlivá na kana, nerozlišuje šířku
_CI_AI_KS_WS 2	Nerozlišující velká a malá písmena, nerozlišující diakritiku, rozlišující kana, rozlišující šířku
_CI_AI_WS 2	Nerozlišující velká a malá písmena, nerozlišující diakritika, nerozlišující kana, citlivá na šířku
_CI_AS 2	Nerozlišující velikost písmen, rozlišující diakritiku, nerozlišující kana, nerozlišující šířku
_CI_AS_KS 2	Nerozlišují se malá a velká písmena, rozlišují se podle akcentů, rozlišují se znaky kana, nerozlišují se podle šířky
_CI_AS_KS_WS 2	Bez rozlišení velkých a malých písmen, citlivé na diakritiku, citlivé na kanu, citlivé na šířku
_CI_AS_WS 2	Nerozlišují velká a malá písmena, rozlišují se diakritická znaménka, nerozlišují se kana, rozlišují se podle šířky.
_CS_AI 2	Rozlišování malých a velkých písmen, nerozlišují se akcenty, nerozlišují se kana znaky, nerozlišují se šířky
_CS_AI_KS 2	Rozlišují se malá a velká písmena, nerozlišují se přízvuky, rozlišují se znaky kana, šířka se nerozlišuje.
_CS_AI_KS_WS 2	Rozlišují se malá a velká písmena, nerozlišují se akcenty, rozlišují se kana znaky, rozlišují se znaky podle šířky.
_CS_AI_WS 2	Rozlišující malá a velká písmena, nerozlišující diakritiku, nerozlišující kana, citlivé na šířku
_CS_AS 2	Rozlišovat velká a malá písmena, rozlišovat diakritiku, nerozlišovat kany, nerozlišovat šířky
_CS_AS_KS 2	Rozlišování velkých a malých písmen, rozlišování diakritiky, rozlišování kany, nerozlišující šířku
_CS_AS_KS_WS 2	Rozlišování velkých a malých písmen, rozlišování přízvuků, rozlišování kana, rozlišování šířky znaků
_CS_AS_WS 2	Rozlišující malá a velká písmena, rozlišující akcenty, nerozlišující kana, rozlišující šířku

¹ Pokud je vybraný binární nebo binární kódový bod, nejsou dostupné možnosti rozlišující malá a velká písmena (_CS), rozlišování podle přízvuku (_AS), rozeznávání mezi verzemi Kana (_KS) a rozlišování podle šířky (_WS).

² Přidání možnosti UTF-8 (_UTF8) umožňuje kódování dat Unicode pomocí UTF-8. Další informace najdete v části podpora UTF-8 v tomto článku.

Sady třídění

SQL Server podporuje následující sady řazení:

• kolace Windows
• binární kolace
• kolace SQL Serveru

Kolace Windows

Kolace systému Windows definují pravidla pro ukládání znakových dat založených na přidruženém národním prostředí systému Windows. Pro kolaci Windows můžete implementovat porovnání dat, která nejsou unicode, pomocí stejného algoritmu jako pro data Unicode. Základní pravidla kolace systému Windows určují, která abeceda nebo jazyk se používá při řazení slovníku. Pravidla také určují znakovou stránku, která se používá k ukládání dat bez znaků Unicode. Řazení Unicode i jiné než Unicode je kompatibilní s porovnáním řetězců v konkrétní verzi Windows. To poskytuje konzistenci napříč datovými typy v RÁMCI SQL Serveru a umožňuje vývojářům řadit řetězce ve svých aplikacích pomocí stejných pravidel, která používají SQL Server. Pro více informací se podívejte na název kolace systému Windows.

Binární kolace

Binární kolace seřadí data podle posloupnosti kódovaných hodnot definovaných národním prostředím a datovým typem. Rozlišují malá a velká písmena. Binární kolace v SQL Serveru definuje národní prostředí a znakovou stránku ANSI, které se používají. Tím se vynutí binární pořadí řazení. Vzhledem k tomu, že jsou poměrně jednoduché, binární kolace pomáhají zlepšit výkon aplikace. U datových typů, které nejsou unicode, jsou porovnání dat založená na bodech kódu definovaných na znakové stránce ANSI. U datových typů Unicode jsou porovnání dat založená na bodech kódu Unicode. U binárních kolací u datových typů Unicode se národní prostředí nepovažuje za řazení dat. Například Latin1_General_BIN a Japanese_BIN přinášejí identické výsledky řazení, když se použijí na datech Unicode. Pro více informací se podívejte na název kolace systému Windows.

SQL Server obsahuje dva typy binárních kolací:

• Starší verze BIN kolací, které pro data Unicode prováděly neúplné porovnání bod-po-bodu kódu. Starší binární kolace porovnávaly první znak jako WCHAR, následované porovnáním bajtů po bajtech. V kolaci BIN se seřadí pouze první znak podle bodu kódu a zbývající znaky se seřadí podle hodnot bajtů.

• Novější BIN2 kolace, které implementují čisté porovnání kódových bodů. V kolaci BIN2 jsou všechny znaky seřazené podle jejich bodů kódu. Vzhledem k tomu, že platforma Intel je architekturou typu little endian, znaky kódu Unicode jsou vždy uloženy v byte-swapped formátu.

Kolace SQL Serveru

Kolace SQL Serveru (SQL_*) zajišťují kompatibilitu pořadí řazení se staršími verzemi SQL Serveru. Pravidla řazení slovníku pro data jiného typu než Unicode nejsou kompatibilní s jakoukoli rutinou řazení poskytovanou operačními systémy Windows. Řazení dat Unicode je však kompatibilní s konkrétní verzí pravidel řazení systému Windows. Vzhledem k tomu, že kolace SQL Serveru používají různá srovnávací pravidla pro data jiného typu než Unicode a Unicode, zobrazí se různé výsledky porovnání stejných dat v závislosti na podkladovém datovém typu.

Pokud například používáte kolace SQL SQL_Latin1_General_CP1_CI_AS, je ne-Unicode řetězec 'a-c' menší než řetězec 'ab', protože spojovník (-) je seřazen jako samostatný znak, který přichází před b. Pokud však převedete tyto řetězce na Unicode a provedete stejné porovnání, řetězec Unicode N'a-c' je považován za větší než N'ab', protože pravidla řazení Unicode používají řazení slov, která ignoruje pomlčka.

Další informace naleznete v tématu název kolace SQL Serveru.

Během instalace SYSTÉMU SQL Server je výchozí nastavení kolace instalace určeno národním prostředím operačního systému . Kolaci na úrovni serveru můžete změnit buď během instalace, nebo změnou národního prostředí operačního systému před instalací. Z důvodu zpětné kompatibility je výchozí kolace nastavená na nejstarší dostupnou verzi přidruženou ke každému konkrétnímu národnímu prostředí. Tudíž to není vždy doporučené řazení. Pokud chcete plně využít výhod funkcí SQL Serveru, změňte výchozí nastavení instalace tak, aby používala kolace Systému Windows. Například pro národní prostředí operačního systému "Angličtina (Spojené státy)" (znaková stránka 1252), výchozí kolace během instalace je SQL_Latin1_General_CP1_CI_ASa lze ji změnit na nejbližší protějšek kolace Systému Windows, Latin1_General_100_CI_AS_SC.

Při upgradu instance SQL Serveru v angličtině můžete určit kolace SQL Serveru (SQL_*) kvůli kompatibilitě se stávajícími instancemi SQL Serveru. Vzhledem k tomu, že během instalace je definována výchozí kolace pro instanci SQL Serveru, nezapomeňte pečlivě zadat nastavení kolace, pokud jsou splněny následující podmínky:

• Kód aplikace závisí na chování předchozích kolací SQL Serveru.
• Data znaků, která odrážejí více jazyků, musíte uložit.

Úrovně kolace

Nastavení kolací se podporují na následujících úrovních instance SQL Serveru:

• Kolace na úrovni serveru
• kolace na úrovni databáze
• kolace na úrovni sloupců
• kolace na úrovni výrazů

Třídění na úrovni serveru

Výchozí kolace serveru se určí během instalace SQL Serveru a stane se výchozí kolací systémových databází a všech uživatelských databází.

Následující tabulka uvádí výchozí kolační označení určená národním prostředím operačního systému, včetně jejich identifikátorů kódu jazyka WINDOWS a JAZYKa SQL (LCID):

Místní nastavení Windows	Windows LCID	SQL LCID	Výchozí třídění
Afrikaánština (Jihoafrická republika)	0x0436	0x0409	Latin1_General_CI_AS
Albánština (Albánie)	0x041c	0x041c	Albanian_CI_AS
Alsatština (Francie)	0x0484	0x0409	Latin1_General_CI_AS
Amharština (Etiopie)	0x045e	0x0409	Latin1_General_CI_AS
Arabština (Alžírsko)	0x1401	0x0401	Arabic_CI_AS
Arabština (Bahrajn)	0x3c01	0x0401	Arabic_CI_AS
Arabština (Egypt)	0x0c01	0x0401	Arabic_CI_AS
Arabština (Irák)	0x0801	0x0401	Arabic_CI_AS
Arabština (Jordánsko)	0x2c01	0x0401	Arabic_CI_AS
Arabština (Kuvajt)	0x3401	0x0401	Arabic_CI_AS
Arabština (Libanon)	0x3001	0x0401	Arabic_CI_AS
Arabština (Libye)	0x1001	0x0401	Arabic_CI_AS
Arabština (Maroko)	0x1801	0x0401	Arabic_CI_AS
Arabština (Omán)	0x2001	0x0401	Arabic_CI_AS
Arabština (Katar)	0x4001	0x0401	Arabic_CI_AS
Arabština (Saúdská Arábie)	0x0401	0x0401	Arabic_CI_AS
Arabština (Sýrie)	0x2801	0x0401	Arabic_CI_AS
Arabština (Tunisko)	0x1c01	0x0401	Arabic_CI_AS
Arabština (USA)	0x3801	0x0401	Arabic_CI_AS
Arabština (Jemen)	0x2401	0x0401	Arabic_CI_AS
Arménština (Arménie)	0x042b	0x0419	Latin1_General_CI_AS
Assamština (Indie)	0x044d	0x044d	Není k dispozici na úrovni serveru
Ázerbájdžánština (Ázerbájdžán, cyrilice)	0x082c	0x082c	Zastaralé, není dostupné na úrovni serveru
Ázerbájdžánština (Ázerbájdžán, latinka)	0x042c	0x042c	Zastaralé, není dostupné na úrovni serveru
Bashkir (Rusko)	0x046d	0x046d	Latin1_General_CI_AI
Baskičtina (Baskičtina)	0x042d	0x0409	Latin1_General_CI_AS
Běloruský (Bělorusko)	0x0423	0x0419	Cyrillic_General_CI_AS
Bangla (Bangladéš)	0x0845	0x0445	Není k dispozici na úrovni serveru
Bengálština (Indie)	0x0445	0x0439	Není k dispozici na úrovni serveru
Bosenština (Bosna a Hercegovina, cyrilice)	0x201a	0x201a	Latin1_General_CI_AI
Bosenština (Bosna a Hercegovina, latinka)	0x141a	0x141a	Latin1_General_CI_AI
Breton (Francie)	0x047e	0x047e	Latin1_General_CI_AI
Bulharština (Bulharsko)	0x0402	0x0419	Cyrillic_General_CI_AS
Katalánština (Catalan)	0x0403	0x0409	Latin1_General_CI_AS
Čínština (Hongkong – zvláštní správní oblast, ČLR)	0x0c04	0x0404	Chinese_Taiwan_Stroke_CI_AS
Čínština (Macao SAR)	0x1404	0x1404	Latin1_General_CI_AI
Čínština (Macao SAR)	0x21404	0x21404	Latin1_General_CI_AI
Čínština (ČLR)	0x0804	0x0804	Čínština_PRK_CI_AS
Čínština (ČLR)	0x20804	0x20804	Čínská_PRCR_Stroke_CI_AS
Čínština (Singapur)	0x1004	0x0804	Čínština_PRK_CI_AS
Čínština (Singapur)	0x21004	0x20804	Čínská_PRCR_Stroke_CI_AS
Čínština (Tchaj-wan)	0x30404	0x30404	Chinese_Taiwan_Bopomofo_CI_AS
Čínština (Tchaj-wan)	0x0404	0x0404	Chinese_Taiwan_Stroke_CI_AS
Korsika (Francie)	0x0483	0x0483	Latin1_General_CI_AI
Chorvatština (Bosna a Hercegovina, latinka)	0x101a	0x041a	Croatian_CI_AS
Chorvatština (Chorvatsko)	0x041a	0x041a	Croatian_CI_AS
Čeština (Česká republika)	0x0405	0x0405	Czech_CI_AS
Dánština (Dánsko)	0x0406	0x0406	Danish_Norwegian_CI_AS
Dari (Afghánistán)	0x048c	0x048c	Latin1_General_CI_AI
Divehi (Maledivy)	0x0465	0x0465	Není k dispozici na úrovni serveru
Holandština (Belgie)	0x0813	0x0409	Latin1_General_CI_AS
Holandština (Nizozemsko)	0x0413	0x0409	Latin1_General_CI_AS
Angličtina (Austrálie)	0x0c09	0x0409	Latin1_General_CI_AS
Angličtina (Belize)	0x2809	0x0409	Latin1_General_CI_AS
Angličtina (Kanada)	0x1009	0x0409	Latin1_General_CI_AS
Angličtina (Karibská oblast)	0x2409	0x0409	Latin1_General_CI_AS
Angličtina (Indie)	0x4009	0x0409	Latin1_General_CI_AS
Angličtina (Irsko)	0x1809	0x0409	Latin1_General_CI_AS
Angličtina (Jamajka)	0x2009	0x0409	Latin1_General_CI_AS
Angličtina (Malajsie)	0x4409	0x0409	Latin1_General_CI_AS
Angličtina (Nový Zéland)	0x1409	0x0409	Latin1_General_CI_AS
Angličtina (Filipíny)	0x3409	0x0409	Latin1_General_CI_AS
Angličtina (Singapur)	0x4809	0x0409	Latin1_General_CI_AS
Angličtina (Jihoafrická republika)	0x1c09	0x0409	Latin1_General_CI_AS
Angličtina (Trinidad a Tobago)	0x2c09	0x0409	Latin1_General_CI_AS
Angličtina (Spojené království)	0x0809	0x0409	Latin1_General_CI_AS
Angličtina (Spojené státy)	0x0409	0x0409	SQL_Latin1_General_CP1_CI_AS
Angličtina (Zimbabwe)	0x3009	0x0409	Latin1_General_CI_AS
Estonština (Estonsko)	0x0425	0x0425	Estonian_CI_AS
Faerský jazyk (Faerské ostrovy)	0x0438	0x0409	Latin1_General_CI_AS
Filipínština (Filipíny)	0x0464	0x0409	Latin1_General_CI_AS
Finština (Finsko)	0x040b	0x040b	Finnish_Swedish_CI_AS
Francouzština (Belgie)	0x080c	0x040c	French_CI_AS
francouzština v Kanadě	0x0c0c	0x040c	French_CI_AS
Francouzština (Francie)	0x040c	0x040c	French_CI_AS
Francouzština (Lucembursko)	0x140c	0x040c	French_CI_AS
Francouzština (Monako)	0x180c	0x040c	French_CI_AS
Francouzština (Švýcarsko)	0x100c	0x040c	French_CI_AS
Frisian (Nizozemsko)	0x0462	0x0462	Latin1_General_CI_AI
Galicijština	0x0456	0x0409	Latin1_General_CI_AS
Gruzie (Georgie)	0x10437	0x10437	Georgian_Modern_Sort_CI_AS
Gruzie (Georgie)	0x0437	0x0419	Latin1_General_CI_AS
Němčina – řazení podle telefonního seznamu (DIN)	0x10407	0x10407	German_PhoneBook_CI_AS
Němčina (Rakousko)	0x0c07	0x0409	Latin1_General_CI_AS
Němčina (Německo)	0x0407	0x0409	Latin1_General_CI_AS
Němčina (Lichtenštejnsko)	0x1407	0x0409	Latin1_General_CI_AS
Němčina (Lucembursko)	0x1007	0x0409	Latin1_General_CI_AS
Němčina (Švýcarsko)	0x0807	0x0409	Latin1_General_CI_AS
Řečtina (Řecko)	0x0408	0x0408	Greek_CI_AS
Grónština (Grónsko)	0x046f	0x0406	Danish_Norwegian_CI_AS
Gudžarátí (Indie)	0x0447	0x0439	Není k dispozici na úrovni serveru
Hausa (Nigérie, latinka)	0x0468	0x0409	Latin1_General_CI_AS
Hebrejština (Izrael)	0x040d	0x040d	Hebrew_CI_AS
Hindština (Indie)	0x0439	0x0439	Není k dispozici na úrovni serveru
Maďarština (Maďarsko)	0x040e	0x040e	Hungarian_CI_AS
Maďarské technické třídění	0x1040e	0x1040e	Hungarian_Technical_CI_AS
Islandština (Island)	0x040f	0x040f	Icelandic_CI_AS
Igbo (Nigérie)	0x0470	0x0409	Latin1_General_CI_AS
Indonéština (Indonésie)	0x0421	0x0409	Latin1_General_CI_AS
Inuktitut (Kanada, latinka)	0x085d	0x0409	Latin1_General_CI_AS
Inuktitut (slabičné písmo) Kanada	0x045d	0x045d	Latin1_General_CI_AI
Irština (Irsko)	0x083c	0x0409	Latin1_General_CI_AS
Italština (Itálie)	0x0410	0x0409	Latin1_General_CI_AS
Italština (Švýcarsko)	0x0810	0x0409	Latin1_General_CI_AS
Japonština (Japonsko XJIS)	0x0411	0x0411	Japanese_CI_AS
Japonština (Japonsko)	0x040411	0x40411	Latin1_General_CI_AI
Kannada (Indie)	0x044b	0x0439	Není k dispozici na úrovni serveru
Kazaština (Kazachstán)	0x043f	0x043f	Kazakh_90_CI_AS
Khmer (Kambodža)	0x0453	0x0453	Není k dispozici na úrovni serveru
K'iche (Guatemala)	0x0486	0x0c0a	Modern_Spanish_CI_AS
Kinyarwanda (Rwanda)	0x0487	0x0409	Latin1_General_CI_AS
Konkani (Indie)	0x0457	0x0439	Není k dispozici na úrovni serveru
Korejské (Korejské třídění slovníku)	0x0412	0x0412	Korean_Wansung_CI_AS
Kyrgyz (Kyrgyzstán)	0x0440	0x0419	Cyrillic_General_CI_AS
Lao (Lao PDR)	0x0454	0x0454	Není k dispozici na úrovni serveru
Lotyština (Lotyšsko)	0x0426	0x0426	Latvian_CI_AS
litevština (Litva)	0x0427	0x0427	Lithuanian_CI_AS
Dolní Sorbština (Německo)	0x082e	0x0409	Latin1_General_CI_AS
Lucemburština (Lucembursko)	0x046e	0x0409	Latin1_General_CI_AS
Makedonština (Severní Makedonie)	0x042f	0x042f	Macedonian_FYROM_90_CI_AS
Malajština (Brunej Darussalam)	0x083e	0x0409	Latin1_General_CI_AS
Malajština (Malajsie)	0x043e	0x0409	Latin1_General_CI_AS
Malajálam (Indie)	0x044c	0x0439	Není k dispozici na úrovni serveru
Maltština (Malta)	0x043a	0x043a	Latin1_General_CI_AI
Maori (Nový Zéland)	0x0481	0x0481	Latin1_General_CI_AI
Mapudungun (Chile)	0x047a	0x047a	Latin1_General_CI_AI
Marathi (Indie)	0x044e	0x0439	Není k dispozici na úrovni serveru
Mohawk (Kanada)	0x047c	0x047c	Latin1_General_CI_AI
Mongolština (Mongolsko)	0x0450	0x0419	Cyrillic_General_CI_AS
Mongolština (ČLR)	0x0850	0x0419	Cyrillic_General_CI_AS
Nepálština (Nepál)	0x0461	0x0461	Není k dispozici na úrovni serveru
Norština (Bokmål, Norsko)	0x0414	0x0414	Latin1_General_CI_AI
Norština (Nynorsk, Norsko)	0x0814	0x0414	Latin1_General_CI_AI
Occitan (Francie)	0x0482	0x040c	French_CI_AS
Odia (Indie)	0x0448	0x0439	Není k dispozici na úrovni serveru
Pashto (Afghánistán)	0x0463	0x0463	Není k dispozici na úrovni serveru
Perština (Írán)	0x0429	0x0429	Latin1_General_CI_AI
Polština (Polsko)	0x0415	0x0415	Polish_CI_AS
Portugalština (Brazílie)	0x0416	0x0409	Latin1_General_CI_AS
Portugalština (Portugalsko)	0x0816	0x0409	Latin1_General_CI_AS
Pažábí (Indie)	0x0446	0x0439	Není k dispozici na úrovni serveru
Quechua (Brazílie)	0x046b	0x0409	Latin1_General_CI_AS
Quechua (Ekvádor)	0x086b	0x0409	Latin1_General_CI_AS
Quechua (Peru)	0x0c6b	0x0409	Latin1_General_CI_AS
Rumunština (Rumunsko)	0x0418	0x0418	Romanian_CI_AS
Romansh (Švýcarsko)	0x0417	0x0417	Latin1_General_CI_AI
Ruština (Rusko)	0x0419	0x0419	Cyrillic_General_CI_AS
Sahka (Rusko)	0x0485	0x0485	Latin1_General_CI_AI
Sami (Inari, Finsko)	0x243b	0x083b	Latin1_General_CI_AI
Sami (Lule, Norsko)	0x103b	0x043b	Latin1_General_CI_AI
Sami (Lule, Švédsko)	0x143b	0x083b	Latin1_General_CI_AI
Sami (severní, Finsko)	0x0c3b	0x083b	Latin1_General_CI_AI
Sami (severní, Norsko)	0x043b	0x043b	Latin1_General_CI_AI
Sami (Severní, Švédsko)	0x083b	0x083b	Latin1_General_CI_AI
Sami (Skolt, Finsko)	0x203b	0x083b	Latin1_General_CI_AI
Sami (jižní, Norsko)	0x183b	0x043b	Latin1_General_CI_AI
Sami (jižní, Švédsko)	0x1c3b	0x083b	Latin1_General_CI_AI
Sanskrit (Indie)	0x044f	0x0439	Není k dispozici na úrovni serveru
Srbština (Bosna a Hercegovina, cyrilice)	0x1c1a	0x0c1a	Latin1_General_CI_AI
Srbština (Bosna a Hercegovina, latinka)	0x181a	0x081a	Latin1_General_CI_AI
Srbština (Srbsko, cyrilice)	0x0c1a	0x0c1a	Latin1_General_CI_AI
Srbština (Srbsko, latinka)	0x081a	0x081a	Latin1_General_CI_AI
Sesotho sa Leboa/Northern Sotho (Jihoafrická republika)	0x046c	0x0409	Latin1_General_CI_AS
Setswana/Tswana (Jihoafrická republika)	0x0432	0x0409	Latin1_General_CI_AS
Sinhala (Srí Lanka)	0x045b	0x0439	Není k dispozici na úrovni serveru
Slovenština (Slovensko)	0x041b	0x041b	Slovak_CI_AS
Slovinština (Slovinsko)	0x0424	0x0424	Slovenian_CI_AS
Španělština (Argentina)	0x2c0a	0x0c0a	Modern_Spanish_CI_AS
Španělština (Brazílie)	0x400a	0x0c0a	Modern_Spanish_CI_AS
Španělština (Chile)	0x340a	0x0c0a	Modern_Spanish_CI_AS
Španělština (Kolumbie)	0x240a	0x0c0a	Modern_Spanish_CI_AS
Španělština (Kostarika)	0x140a	0x0c0a	Modern_Spanish_CI_AS
Španělština (Dominikánská republika)	0x1c0a	0x0c0a	Modern_Spanish_CI_AS
Španělština (Ekvádor)	0x300a	0x0c0a	Modern_Spanish_CI_AS
Španělština (Salvador)	0x440a	0x0c0a	Modern_Spanish_CI_AS
Španělština (Guatemala)	0x100a	0x0c0a	Modern_Spanish_CI_AS
Španělština (Honduras)	0x480a	0x0c0a	Modern_Spanish_CI_AS
Španělština (Mexiko)	0x080a	0x0c0a	Modern_Spanish_CI_AS
Španělština (Nikaragua)	0x4c0a	0x0c0a	Modern_Spanish_CI_AS
Španělština (Panama)	0x180a	0x0c0a	Modern_Spanish_CI_AS
Španělština (Paraguay)	0x3c0a	0x0c0a	Modern_Spanish_CI_AS
Španělština (Peru)	0x280a	0x0c0a	Modern_Spanish_CI_AS
Španělština (Portoriko)	0x500a	0x0c0a	Modern_Spanish_CI_AS
Španělština (Španělsko)	0x0c0a	0x0c0a	Modern_Spanish_CI_AS
Španělština (Španělsko, tradiční řazení)	0x040a	0x040a	Traditional_Spanish_CI_AS
Španělština (Spojené státy)	0x540a	0x0409	Latin1_General_CI_AS
Španělština (Uruguay)	0x380a	0x0c0a	Modern_Spanish_CI_AS
Španělština (Venezuela)	0x200a	0x0c0a	Modern_Spanish_CI_AS
Swahili (Keňa)	0x0441	0x0409	Latin1_General_CI_AS
Švédština (Finsko)	0x081d	0x040b	Finnish_Swedish_CI_AS
Švédština (Švédsko)	0x041d	0x040b	Finnish_Swedish_CI_AS
Sýrie (Sýrie)	0x045a	0x045a	Není k dispozici na úrovni serveru
Tajik (Tajikistan)	0x0428	0x0419	Cyrillic_General_CI_AS
Tamazight (Alžírsko, latinka)	0x085f	0x085f	Latin1_General_CI_AI
Tamilština (Indie)	0x0449	0x0439	Není k dispozici na úrovni serveru
Tatar (Rusko)	0x0444	0x0444	Cyrillic_General_CI_AS
Telugu (Indie)	0x044a	0x0439	Není k dispozici na úrovni serveru
Thajština (Thajsko)	0x041e	0x041e	Thai_CI_AS
Tibetský (ČLR)	0x0451	0x0451	Není k dispozici na úrovni serveru
Turečtina (Turecko)	0x041f	0x041f	Turkish_CI_AS
Turkmeni (Turkmenistán)	0x0442	0x0442	Latin1_General_CI_AI
Uighur (ČLR)	0x0480	0x0480	Latin1_General_CI_AI
Ukrajinština (Ukrajina)	0x0422	0x0422	Ukrainian_CI_AS
Horní Sorbština (Německo)	0x042e	0x042e	Latin1_General_CI_AI
Urdu (Pákistán)	0x0420	0x0420	Latin1_General_CI_AI
Uzbečtina (Uzbekistán, cyrilice)	0x0843	0x0419	Cyrillic_General_CI_AS
Uzbečtina (Uzbekistán, Latinka)	0x0443	0x0443	Uzbek_Latin_90_CI_AS
Vietnamština (Vietnam)	0x042a	0x042a	Vietnamese_CI_AS
Welsh (Velká Británie)	0x0452	0x0452	Latin1_General_CI_AI
Wolof (Senegal)	0x0488	0x040c	French_CI_AS
Xhosa/isiXhosa (Jihoafrická republika)	0x0434	0x0409	Latin1_General_CI_AS
Yi (ČLR)	0x0478	0x0409	Latin1_General_CI_AS
Yoruba (Nigérie)	0x046a	0x0409	Latin1_General_CI_AS
Zulu/isiZulu (Jihoafrická republika)	0x0435	0x0409	Latin1_General_CI_AS

Po přiřazení kolace k serveru ji můžete změnit pouze exportem všech databázových objektů a dat, opětovným sestavením databáze master a importem všech databázových objektů a dat. Místo změny výchozí kolace instance SQL Serveru můžete při vytváření nové databáze nebo databázového sloupce určit požadovanou kolaci.

K dotazování serverové kolace pro instanci SQL Serveru použijte funkci SERVERPROPERTY:

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

K dotazování serveru na všechny dostupné kolace použijte následující fn_helpcollations() předdefinovanou funkci:

SELECT *
FROM sys.fn_helpcollations();

Kolace ve službě Azure SQL Database

Kolaci logického serveru ve službě Azure SQL Database nemůžete změnit ani nastavit, ale můžete nakonfigurovat kolace jednotlivých databází pro data i pro katalog. Kolace katalogu určuje kolaci pro systémová metadata, například identifikátory objektů. Obě kolace je možné zadat nezávisle při vytvoření databáze na webu Azure Portal, v T-SQL s CREATE DATABASE, v PowerShellu s New-AzSqlDatabase.

Kolace ve službě Azure SQL Managed Instance

Kolace na úrovni serveru ve službě Azure SQL Managed Instance je možné zadat při vytvoření instance a později ji nelze změnit.

Další informace naleznete v tématu Nastavení nebo změna řazení serveru.

Řazení na úrovni databáze

Při vytváření nebo úpravě databáze můžete k určení výchozí kolace databáze použít klauzuli COLLATE příkazu CREATE DATABASE nebo ALTER DATABASE. Pokud není zadána žádná kolace, je databázi přiřazena kolace serveru.

Kolaci systémových databází nemůžete změnit, pokud nezměníte kolaci serveru.

• V SQL Serveru a azure SQL Managed Instance se kolace databáze používá pro všechna metadata v databázi a kolace je výchozí pro všechny řetězcové sloupce, dočasné objekty, názvy proměnných a všechny další řetězce použité v databázi.
• Ve službě Azure SQL Database neexistuje žádná kolace serverů, takže každá databáze obsahuje kolaci dat a kolaci katalogu. CATALOG_COLLATION se používá pro všechna metadata v databázi a kolace je výchozí pro všechny řetězcové sloupce, dočasné objekty, názvy proměnných a všechny další řetězce použité v databázi. CATALOG_COLLATION se nastaví při vytváření a nedá se změnit.

Když změníte kolaci uživatelské databáze, může dojít ke konfliktům kolace při dotazech na dočasné tabulky v databázi. Dočasné tabulky jsou vždy uloženy v systémové databázi tempdb, která používá kolaci instance. Dotazy, které porovnávají data znaků mezi uživatelskou databází a tempdb mohou selhat, pokud kolace způsobí konflikt při vyhodnocování dat znaků. Tento problém můžete vyřešit zadáním klauzule COLLATE v dotazu. Další informace naleznete v tématu COLLATE.

Kolaci uživatelské databáze můžete změnit pomocí příkazu ALTER DATABASE podobný následujícímu vzorci kódu:

ALTER DATABASE myDB COLLATE Greek_CS_AI;

Důležitý

Změna kolace na úrovni databáze nemá vliv na kolace na úrovni sloupců nebo výrazů. Nemá vliv na data ve stávajících sloupcích.

Aktuální kolaci databáze můžete načíst pomocí příkazu podobného následujícímu vzorci kódu:

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

Srovnání na úrovni sloupců

Při vytváření nebo změně tabulky můžete pomocí klauzule COLLATE zadat kolace pro každý sloupec řetězce znaků. Pokud neurčíte kolaci, sloupci se přiřadí výchozí kolace databáze.

Kolaci sloupce můžete změnit pomocí příkazu ALTER TABLE podobného následující ukázce kódu:

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

Kolace na úrovni výrazů

Kolace na úrovni výrazů se nastavují při spuštění příkazu a ovlivňují způsob vrácení sady výsledků. To umožňuje ORDER BY řazení výsledků s ohledem na národní prostředí. K implementaci kolací na úrovni výrazů použijte klauzuli COLLATE, jako je například následující ukázka kódu:

SELECT name
FROM customer
ORDER BY name COLLATE Latin1_General_CS_AI;

Místo

Národní prostředí je sada informací přidružených k umístění nebo jazykové verzi. Informace můžou obsahovat název a identifikátor mluveného jazyka, skript, který se používá k psaní jazyka a kulturní konvence. Kolace lze přidružit k jednomu nebo více národním prostředím. Další informace naleznete v tématu ID národního prostředí přiřazené společností Microsoft.

Kódová stránka

Znaková stránka je uspořádaná sada znaků daného skriptu, ve kterém je ke každému znaku přidružen číselný index nebo hodnota bodu kódu. Znaková stránka Systému Windows se obvykle označuje jako znaková sada nebo znaková sada . Znakové stránky slouží k zajištění podpory znakových sad a rozložení klávesnice, které používají různá národní prostředí systému Windows.

Pořadí řazení

Pořadí řazení určuje způsob řazení hodnot dat. Pořadí ovlivňuje výsledky porovnání dat. Data se seřadí pomocí kolací a dají se optimalizovat pomocí indexů.

Podpora kódování Unicode

Unicode je standard pro mapování bodů kódu na znaky. Vzhledem k tomu, že je navržený tak, aby pokrývala všechny znaky všech jazyků světa, nepotřebujete k zpracování různých sad znaků různé znakové stránky.

Základy kódování Unicode

Ukládání dat v několika jazycích v rámci jedné databáze je obtížné spravovat, když používáte jenom data znaků a znakové stránky. Pro databázi je také obtížné najít jednu znakovou stránku, která může ukládat všechny požadované znaky specifické pro jazyk. Kromě toho je obtížné zaručit správný překlad speciálních znaků při jejich čtení nebo aktualizaci různými klienty, kteří používají různé znakové stránky. Databáze, které podporují mezinárodní klienty, by měly vždy používat datové typy Unicode místo datových typů jiných než Unicode.

Představte si například databázi zákazníků v Severní Americe, která musí zpracovávat tři hlavní jazyky:

• Španělská jména a adresy pro Mexiko
• Francouzské názvy a adresy pro Quebec
• Anglické názvy a adresy pro zbytek Kanady a Usa

Pokud používáte pouze sloupce znaků a znakové stránky, je nutné zajistit, aby byla databáze nainstalována se znakovou stránkou, která bude zpracovávat znaky všech tří jazyků. Při čtení znaků klienty, kteří používají znakovou stránku pro jiný jazyk, musíte také zajistit správný překlad znaků z libovolného jazyka.

Poznámka

Znakové stránky, které klient používá, jsou určeny nastavením operačního systému (OS). Chcete-li nastavit stránky kódu klienta v operačním systému Windows, použijte místní nastavení v Ovládacích panelech.

Pro datové typy znaků by bylo obtížné vybrat znakovou stránku, která bude podporovat všechny znaky vyžadované celosvětovou cílovou skupinou. Nejjednodušší způsob, jak spravovat data znaků v mezinárodních databázích, je vždy použít datový typ, který podporuje Unicode.

Datové typy Unicode

Pokud ukládáte data znaků, která odrážejí více jazyků v SYSTÉMU SQL Server (SQL Server 2005 (9.x) a novější), použijte datové typy Unicode (nchar, nvarchara ntext) místo datových typů, které nejsou unicode (znak, varchara text).

Poznámka

Pro datové typy Unicode může databázový stroj reprezentovat až 65 536 znaků pomocí UCS-2, nebo celý rozsah Unicode (1 114 112 znaků), pokud se používají doplňkové znaky. Další informace o povolení doplňkových znaků naleznete v tématu Doplňkové znaky.

Alternativně platí, že počínaje SQL Serverem 2019 (15.x), pokud se používá kolace s podporou UTF-8 (_UTF8), dříve datové typy, které nejsou unicode (char a varchar) se stanou datovými typy Unicode pomocí kódování UTF-8. SQL Server 2019 (15.x) nemění chování dříve existujících datových typů Unicode (nchar, nvarchara ntext), které nadále používají kódování UCS-2 nebo UTF-16. Další informace najdete v tématu Rozdíly mezi UTF-8 a UTF-16.

Důležité informace o kódování Unicode

K datovým typům, které nejsou unicode, jsou přidružena významná omezení. Důvodem je to, že počítač, který není unicode, je omezen na použití jedné znakové stránky. Můžete zaznamenat zvýšení výkonu pomocí kódování Unicode, protože vyžaduje méně převodů na znakové stránky. Kolace Unicode musí být vybrány jednotlivě na úrovni databáze, sloupce nebo výrazu, protože nejsou podporovány na úrovni serveru.

Při přesouvání dat ze serveru do klienta nemusí být kolace serveru rozpoznána staršími klientskými ovladači. K tomu může dojít, když přesunete data ze serveru Unicode do klienta, který není unicode. Nejlepší možností může být upgrade klientského operačního systému tak, aby se aktualizovaly základní kolace systému. Pokud má klient nainstalovaný databázový klientský software, můžete zvážit použití aktualizace služby na databázový klientský software.

Spropitné

Můžete se také pokusit použít jinou kolaci dat na serveru. Zvolte kolaci, která se mapuje na znakovou stránku v klientovi. Chcete-li použít kolace UTF-16, které jsou k dispozici na SQL Serveru (SQL Server 2012 (11.x) a novější) ke zlepšení vyhledávání a řazení některých znaků Unicode (pouze kolace Systému Windows), můžete vybrat jeden z doplňkových znaků (_SC) kolace nebo jednu z kolací verze 140.

Chcete-li použít kolace UTF-8, které jsou k dispozici v SQL Serveru 2019 (15.x) a zlepšit vyhledávání a řazení některých znaků Unicode (pouze kolace Systému Windows), je nutné vybrat kolace s kódováním UTF-8 (_UTF8).

• Příznak UTF8 lze použít na:

  • Lingvistické kolace, které již podporují doplňkové znaky (_SC) nebo citlivost na selektory variant (_VSS)
  • Binární kolace BIN2

• Příznak UTF8 nejde použít pro:

  • Lingvistické kolace, které nepodporují doplňkové znaky (_SC) nebo nerozlišují selektory variant (_VSS)
  • Binární kolace BIN
  • Kolace SQL_*

Pokud chcete vyhodnotit problémy související s používáním datových typů Unicode nebo jiných než Unicode, otestujte svůj scénář a změřte rozdíly v výkonu ve vašem prostředí. Je vhodné standardizovat kolaci, která se používá v systémech ve vaší organizaci, a nasazovat servery a klienty Unicode všude, kde je to možné.

V mnoha situacích SQL Server komunikuje s jinými servery nebo klienty a vaše organizace může používat více standardů přístupu k datům mezi aplikacemi a instancemi serveru. Klienti SQL Serveru jsou jedním ze dvou hlavních typů:

• klienti Unicode, kteří používají OLE DB a rozhraní ODBC (Open Database Connectivity) verze 3.7 nebo novější.
• klienti bez kódování Unicode, kteří používají DB-Library a ODBC verze 3.6 nebo starší.

Následující tabulka obsahuje informace o používání vícejazyčných dat s různými kombinacemi serverů Unicode a jiných serverů než Unicode:

Server	Klient	Výhody nebo omezení
Unicode	Unicode	Vzhledem k tomu, že se data Unicode používají v celém systému, poskytuje tento scénář nejlepší výkon a ochranu před poškozením načtených dat. Jedná se o situaci s datovými objekty ActiveX (ADO), OLE DB a ODBC verze 3.7 nebo novější.
Unicode	Jiné než Unicode	V tomto scénáři, zejména u připojení mezi serverem, na kterém běží novější operační systém, a klientem se starší verzí SQL Serveru nebo starším operačním systémem můžou být při přesunu dat do klientského počítače určitá omezení nebo chyby. Data Unicode na serveru se pokusí namapovat na odpovídající znakovou stránku na ne-Unicode klientu, aby se data převedla.
Jiné než Unicode	Unicode	Toto není ideální konfigurace pro použití vícejazyčných dat. Data Unicode nelze zapisovat na server, který není unicode. K problémům může dojít, když se data odesílají na servery, které jsou mimo znakovou stránku serveru.
Jiné než Unicode	Jiné než Unicode	Jedná se o velmi omezující scénář pro vícejazyčná data. Můžete použít jenom jednu znakovou stránku.

Doplňkové znaky

Konsorcium Unicode přiděluje každému znaku jedinečný bod kódu, což je hodnota v rozsahu 000000 – 10FFFF. Nejčastěji používané znaky mají hodnoty bodů kódu v rozsahu 000000 –00FFFF (65 536 znaků), které se vejdou do 8bitového nebo 16bitového slova v paměti a na disku. Tento rozsah je obvykle určen jako základní vícejazyčná rovina (BMP).

Konsorcium Unicode však vytvořilo 16 dalších "rovin" znaků, přičemž každá má stejnou velikost jako BMP. Tato definice umožňuje kódování Unicode, které může představovat 1 114 112 znaků (tj. 2¹⁶ * 17 znaků) v rozsahu 0000000 až 10FFFF. Znaky s hodnotou bodu kódu větší než 00FFFF vyžadují dvě až čtyři po sobě jdoucí 8bitová slova (UTF-8) nebo dvě po sobě jdoucí 16bitová slova (UTF-16). Tyto znaky umístěné mimo BMP se nazývají doplňkové znakya další po sobě jdoucí 8bitová nebo 16bitová slova se nazývají náhradní dvojice. Další informace o doplňkových znacích, náhradních znacích a náhradních dvojicích naleznete v tématu Unicode Standard.

SQL Server poskytuje datové typy, jako je nchar a nvarchar k ukládání dat Unicode v rozsahu BMP (000000 – 00FFFF), který databázový stroj kóduje pomocí UCS-2.

SQL Server 2012 (11.x) zavedl novou řadu doplňkových kompletací znaků (_SC), které lze použít s nchar, nvarchara sql_variant datových typů, které představují úplný rozsah znaků Unicode (000000 – 10FFFF). Například: Latin1_General_100_CI_AS_SC, nebo pokud používáte japonskou kolaci, Japanese_Bushu_Kakusu_100_CI_AS_SC.

SQL Server 2019 (15.x) rozšiřuje podporu doplňkových znaků na datové typy char a varchar s novými kolacemi s podporou UTF-8 (_UTF8). Tyto datové typy jsou také schopné reprezentovat celý rozsah znaků Unicode.

Poznámka

Počínaje SQL Serverem 2017 (14.x) všechny nové kolace automaticky podporují doplňkové znaky.

Pokud používáte doplňkové znaky:

• Doplňkové znaky lze použít v operacích řazení a porovnání ve verzích kolace 90 nebo vyšších.

• Všechna kolace verze 100 podporují lingvistické řazení s doplňkovými znaky.

• Doplňkové znaky se nepodporují pro použití v metadatech, jako jsou názvy databázových objektů.

• Příznak SC lze použít pro:

  • Verze 90 - řazení
  • Kolace verze 100

• Příznak SC se nedá použít pro:

  • Kolace Windows verze 80 bez verzí
  • Binární kolace typu BIN nebo BIN2
  • Kolace SQL*
  • Uspořádání verze 140 (tyto nevyžadují příznak SC, protože již podporují doplňkové znaky)

Následující tabulka porovnává chování některých řetězcových funkcí a řetězcových operátorů, když používají doplňkové znaky s a bez kolace vnímající doplňkové znaky (SCA).

Řetězcová funkce nebo operátor	S řazením SCA	Bez třídění SCA
CHARINDEX délka PATINDEX	Náhradní dvojice UTF-16 se počítá jako jediný bod kódu.	Náhradní dvojice UTF-16 se počítá jako dva znaky Unicode.
vlevo nahradit REVERZNÍ PRAVO podřetězec STUFF	Tyto funkce zachází s každou náhradní dvojicí jako s jedním bodem kódu a fungují podle očekávání.	Tyto funkce můžou rozdělit všechny náhradní páry a vést k neočekávaným výsledkům.
NCHAR	Vrátí znak odpovídající zadané hodnotě bodu kódu Unicode v rozsahu 0 – 0x10FFFF. Pokud zadaná hodnota leží v rozsahu 0 – 0xFFFF, vrátí se jeden znak. U vyšších hodnot se vrátí odpovídající náhradní hodnota.	Hodnota vyšší než 0xFFFF vrátí NULL místo odpovídající náhradní hodnoty.
UNICODE	Vrátí bod kódu UTF-16 v rozsahu 0 – 0x10FFFF.	Vrátí bod kódu UCS-2 v rozsahu 0 – 0xFFFF.
shoda s jedním zástupným znakem Určení znaků, které nemají odpovídat	Doplňkové znaky jsou podporovány pro všechny operace s použitím zástupných znaků.	Tyto operace se zástupnými znaky nepodporují doplňkové znaky. Podporují se další zástupné operátory.

podpora GB18030

GB18030 je samostatný standard, který se používá v Čínské lidové republice pro kódování čínských znaků. V GB18030 mohou být znaky delší než 1, 2 nebo 4 bajty. SQL Server poskytuje podporu pro znaky kódované ve formátu GB18030 tím, že je rozpoznává, když vstupují na server příchozí z aplikace na straně klienta, a poté jsou převedeny a uloženy nativně jako znaky Unicode. Po uložení na serveru se v dalších operacích považují za znaky Unicode.

Můžete použít libovolnou čínskou kolaci, nejlépe nejnovější verzi 100. Všechna kolace verze 100 podporují lingvistické řazení se znaky GB18030. Pokud data obsahují doplňkové znaky (náhradní páry), můžete ke zlepšení vyhledávání a řazení použít kolace SC, které jsou k dispozici na SQL Serveru.

Poznámka

Ujistěte se, že klientské nástroje, například SQL Server Management Studio, používají písmo Dengxian k správnému zobrazení řetězců, které obsahují GB18030 kódované znaky.

Podpora složitých skriptů

SQL Server může podporovat zadávání, ukládání, změnu a zobrazování složitých skriptů. Mezi složité skripty patří následující typy:

• Skripty, které obsahují kombinaci textu zprava doleva i zleva doprava, například kombinace arabského a anglického textu.
• Písma, jejichž znaky mění tvar v závislosti na umístění nebo v kombinaci s jinými znaky, jako jsou arabské, indické a thajské znaky.
• Jazyky, jako je thajština, které vyžadují, aby interní slovníky rozpoznaly slova, protože mezi nimi nejsou žádné přestávky.

Databázové aplikace, které pracují s SQL Serverem, musí používat ovládací prvky, které podporují složité skripty. Standardní ovládací prvky formuláře Windows vytvořené ve spravovaném kódu jsou s podporou komplexního skriptu.

Japonské kolace byly přidány do SQL Serveru 2017

Počínaje SQL Serverem 2017 (14.x) je podporována nová rodina japonských kolací s permutacemi různých možností (_CS, _AS, _KS, _WSa _VSS), stejně jako _BIN a _BIN2.

Pokud chcete zobrazit seznam těchto kolací, můžete dotazovat databázový stroj SQL Serveru:

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

Všechny nové kolace mají integrovanou podporu pro doplňkové znaky, takže žádná z nových kolací 140 nemá (ani nepotřebuje) příznak SC.

Tato kolace jsou podporována v indexech databázového stroje, tabulkách optimalizovaných pro paměť, indexech columnstore a nativně kompilovaných modulech.

Podpora UTF-8

SQL Server 2019 (15.x) zavádí plnou podporu široce používaného kódování znaků UTF-8 jako kódování importu nebo exportu a jako kolace na úrovni databáze nebo sloupce pro řetězcová data. UTF-8 je povolen v char a varchar datových typů a je povolen při vytváření nebo změně kolace objektu na kolaci, která má příponu UTF8. Jedním z příkladů je změna Latin1_General_100_CI_AS_SC na Latin1_General_100_CI_AS_SC_UTF8.

UTF-8 je k dispozici pouze pro kolace Windows, které podporují doplňkové znaky, jak je uvedeno v SQL Serveru 2012 (11.x). Datové typy nchar a nvarchar umožňují kódování UCS-2 nebo UTF-16 pouze a zůstanou beze změny.

Azure SQL Database a Azure SQL Managed Instance také podporují UTF-8 na úrovni databáze a sloupců, zatímco SQL Managed Instance ji podporuje i na úrovni serveru.

Rozdíly v úložišti mezi UTF-8 a UTF-16

Konsorcium Unicode přiděluje každému znaku jedinečný bod kódu, což je hodnota v rozsahu 000000 – 10FFFF. S SQL Serverem 2019 (15.x) jsou k dispozici kódování UTF-8 i UTF-16, které představují celý rozsah:

• Při kódování UTF-8 vyžadují znaky v rozsahu ASCII (000000 – 00007F) 1 bajt, body kódu 000080 - 0007FF vyžadují 2 bajty, body kódu 000800 – 00FFFF vyžadují 3 bajty a body kódu 0010000 - 0010FFFF vyžadují 4 bajty.
• Při kódování UTF-16 vyžadují kódové body 000000 – 00FFFF 2 bajty a body kódu 0010000 - 0010FFFF vyžadují 4 bajty.

Následující tabulka uvádí bajty kódování úložiště pro jednotlivé typy znaků a typ kódování:

Rozsah kódu (šestnáctková soustava)	Rozsah kódu (desítkové číslo)	Bajty úložiště 1 s UTF-8	Úložné bajty 1 s 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 - 03FFFF 2 040000 - 10FFFF 2	65 536 - 262 143 2 262 144 - 1 114 111 2	4	4

¹bajty úložiště odkazují na zakódovanou délku bajtu, nikoli velikost datového typu na disku. Další informace o velikostech úložiště na disku najdete v tématu nchar a nvarchar a char a varchar.

² rozsah kódových bodů pro doplňkové znaky.

Spropitné

Běžně se myslí, že u char a varchar nebo v případě nchar a nvarcharn definuje množství znaků. Důvodem je, že v příkladu sloupce se znakem (10) lze uložit 10 znaků ASCII v rozsahu 0 až 127 při použití kolace, jako je Latin1_General_100_CI_AI, protože každý znak v tomto rozsahu používá pouze 1 bajt. V char a varcharale n definuje velikost řetězce v bajtech (0 – 8 000) a v nchar a nvarchar, n definuje velikost řetězce v bajtové páry (0 – 4 000). n nikdy nedefinuje počet znaků, které lze uložit.

Volba vhodného kódování Unicode a datového typu vám může v závislosti na používané znakové sadě poskytnout významné úspory úložiště nebo zvýšit nároky na aktuální úložiště. Pokud například použijete kolaci latinky, která je povolená UTF-8, například Latin1_General_100_CI_AI_SC_UTF8, znak (10) sloupci ukládá 10 bajtů a může obsahovat 10 znaků ASCII v rozsahu 0 až 127. Může ale obsahovat pouze pět znaků v rozsahu 128 –2047 a pouze tři znaky v rozsahu 2048 – 65535. Vzhledem k tomu, že sloupec nchar(10) ukládá 10 bajtových párů (20 bajtů), může obsahovat 10 znaků v rozsahu 0 až 65535.

Než se rozhodnete, zda použít kódování UTF-8 nebo UTF-16 pro databázi nebo sloupec, zvažte distribuci řetězcových dat, která budou uložena:

• Pokud je většinou v rozsahu ASCII 0 až 127 (například v angličtině), každý znak vyžaduje 1 bajt s UTF-8 a 2 bajty s UTF-16. Použití UTF-8 poskytuje výhody úložiště. Změna existujícího datového typu sloupce se znaky ASCII v rozsahu 0 až 127 z nchar(10) na char(10)a použití kolace s podporou UTF-8 se přeloží na 50% snížení požadavků na úložiště. Toto snížení je způsobeno tím, že nchar(10) vyžaduje pro úložiště 20 bajtů ve srovnání s char(10), což vyžaduje 10 bajtů pro stejné vyjádření řetězce Unicode.
• Nad rozsahem ASCII vyžadují téměř všechny skripty založené na latince i řečtina, cyrilice, koptština, arménština, hebrejština, arabština, syrština, Tāna a N'Ko 2 bajty na jeden znak v UTF-8 i UTF-16. V těchto případech neexistují žádné významné rozdíly mezi úložištěm srovnatelných datových typů (například mezi použitím char nebo nchar).
• Pokud je to většinou východoasijský skript (například korejština, čínština a japonština), každý znak vyžaduje 3 bajty s UTF-8 a 2 bajty s UTF-16. Použití UTF-16 poskytuje výhody úložiště.
• Znaky v rozsahu 010000 až 10FFFF vyžadují 4 bajty v UTF-8 i UTF-16. V těchto případech neexistují žádné rozdíly mezi úložištěm srovnatelných datových typů (například mezi použitím char nebo nchar).

Ohledně dalších aspektů se podívejte na Psaní mezinárodních prohlášení Transact-SQL.

Převod na UTF-8

Protože v char a varchar nebo v nchar a nvarchar, n definuje velikost bajtového úložiště, nikoli počet znaků, které lze uložit, je důležité určit velikost datového typu, na kterou je nutné převést. Znaky, které překračují povolenou velikost, budou zkráceny.

Představte si například sloupec definovaný jako nvarchar(100), který uchovává 180 bajtů japonských znaků. V tomto příkladu jsou data sloupců aktuálně kódována pomocí UCS-2 nebo UTF-16, která používá 2 bajty na znak. Převod typu sloupce na varchar(200) nestačí, aby se zabránilo zkrácení dat, protože nový datový typ může ukládat pouze 200 bajtů, ale japonské znaky při kódování v UTF-8 vyžadují 3 bajty. Sloupec musí být definován jako varchar(270), aby nedošlo ke ztrátě dat prostřednictvím zkrácení dat.

Proto musíte předem vědět, jaká je projektovaná velikost bajtu pro definici sloupce, před převodem existujících dat na UTF-8 a odpovídajícím způsobem upravit novou velikost datového typu. Projděte si Transact-SQL skript nebo poznámkový blok SQL v ukázkách dat na GitHubu, který používá funkci DATALENGTH a příkaz COLLATE, a zjistěte odpovídající požadavky na délku dat pro operace převodu UTF-8 ve stávající databázi.

Chcete-li změnit kolaci sloupců a datový typ v existující tabulce, použijte jednu z metod popsaných v Set nebo změňte kolaci sloupců.

Chcete-li změnit kolaci databáze, což umožňuje novým objektům dědit kolaci databáze ve výchozím nastavení nebo změnit kolaci serveru, což umožňuje novým databázím ve výchozím nastavení dědit systémovou kolaci, podívejte se na související úlohy části tohoto článku.

Související úkoly

Úkol	Článek
Popisuje, jak nastavit nebo změnit kolaci instance SQL Serveru. Změna kolace serveru nemění kolaci existujících databází.	Nastavit nebo změnit kolaci serveru
Popisuje, jak nastavit nebo změnit kolaci uživatelské databáze. Při změně kolace databáze nedojde ke změně kolace stávajících sloupců v tabulkách.	Nastavení nebo změna databázové kolace
Popisuje, jak nastavit nebo změnit kolaci sloupce v databázi.	Nastavení nebo změna kolace sloupce
Popisuje, jak vrátit informace o kolaci na úrovni serveru, databáze nebo sloupce.	Zobrazit informace o kolaci
Popisuje, jak psát Transact-SQL příkazy, které jsou přenosnější z jednoho jazyka do jiného nebo podporují více jazyků snadněji.	psaní mezinárodních Transact-SQL příkazů
Popisuje, jak změnit jazyk chybových zpráv a nastavení předvoleb pro způsob, jakým se informace o datu, čase a měně používají a zobrazují.	Nastavení jazyka relace

Související obsah

• Osvědčené postupy pro změnu kolace SQL Serveru
• Import nebo export dat (SQL Server) pomocí formátu znaků Unicode
• psaní mezinárodních Transact-SQL příkazů
• Osvědčené postupy migrace SQL Serveru na Unicode
• Konsorcium Unicode
• Unicode Standard
• podpora UTF-8 v ovladači OLE DB pro SQL Server
• název kolace SQL Serveru (Transact-SQL)
• název kolace Windows (Transact-SQL)
• Představujeme podporu UTF-8 pro SQL Server
• COLLATE (Transact-SQL)
• priorita řazení
• Obsahující kolace databáze
• Zvolte jazyk při vytváření Full-Text indexu
• sys.fn_helpcollations (Transact-SQL)
• Single-Byte a vícebajtové znakové sady