Stöd för sortering och Unicode
gäller för:
SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)SQL-analysslutpunkt i Microsoft FabricWarehouse i Microsoft Fabric
Kollektioner i SQL Server innehåller sorteringsregler, skiftläges- och accentkänslighet av dina data. Sorteringar som används med teckendatatyper, såsom char och varchar, bestämmer kodsidan och motsvarande tecken som kan representeras för den datatypen.
Oavsett om du installerar en ny instans av SQL Server, återställer en databassäkerhetskopia eller ansluter servern till klientdatabaser är det viktigt att du förstår språkkraven, sorteringsordningen och skiftläges- och accentkänsligheten för de data som du arbetar med. Om du vill visa en lista över sorteringar som är tillgängliga på din instans av SQL Server, se sys.fn_helpcollations.
När du väljer en sortering för servern, databasen, kolumnen eller uttrycket tilldelar du vissa egenskaper till dina data. Dessa egenskaper påverkar resultatet av många åtgärder i databasen. När du till exempel skapar en fråga med hjälp av ORDER BYkan sorteringsordningen för resultatuppsättningen bero på den sortering som tillämpas på databasen eller dikteras i en COLLATE-sats på frågans uttrycksnivå.
Om du vill använda sorteringsstöd på bästa sätt i SQL Server bör du förstå de termer som definieras i den här artikeln och hur de relaterar till egenskaperna hos dina data.
Sorteringsvillkor
Sammanställning
En sortering anger de bitmönster som representerar varje tecken i en datamängd. Kollationeringar avgör också de regler som sorterar och jämför data. SQL Server stöder lagring av objekt som har olika sortering i en enda databas. För icke-Unicode-kolumner anger sorteringsinställningen kodsidan för data och vilka tecken som kan representeras. Data som du flyttar mellan icke-Unicode-kolumner måste konverteras från källkodssidan till målkodsidan.
Transact-SQL-instruktionsresultat kan variera när -instruktionen körs i kontexten för olika databaser som har olika sorteringsinställningar. Använd om möjligt en standardiserad sortering för din organisation. På så sätt behöver du inte ange sorteringen i varje tecken eller Unicode-uttryck. Om du måste arbeta med objekt som har olika sorterings- och kodsideinställningar kodar du dina frågor för att överväga reglerna för sorteringsprioritet. Mer information finns i sorteringsprioritet.
Alternativen som är associerade med en sortering är skiftlägeskänslighet, accentkänslighet, kana-känslighet, breddkänslighet och känslighet för variantväljare. SQL Server 2019 (15.x) introducerar ytterligare ett alternativ för UTF-8 kodning.
Du kan ange de här alternativen genom att lägga till dem i sorteringsnamnet. Sorteringen Japanese_Bushu_Kakusu_100_CS_AS_KS_WS_SC_UTF8 till exempel är skiftlägeskänslig, accentkänslig, kana-känslig, breddkänslig och UTF-8-kodad. Som ett annat exempel är sorteringen Japanese_Bushu_Kakusu_140_CI_AI_KS_WS_VSS skiftlägesokänslig, accentokänslig, kana-känslig, breddkänslig, variantväljare-känslig och använder en äldre kodsida för varchar.
Beteendet som är associerat med dessa olika alternativ beskrivs i följande tabell:
| Alternativ | Beskrivning |
|---|---|
| Skiftlägeskänsligt (_CS) | Skiljer mellan versaler och gemener. Om du väljer det här alternativet, sorteras gemener före deras versaler. Om det här alternativet inte är markerat är sorteringen icke skiftlägeskänslig. SQL Server anser att stora och små bokstäver är identiska i syfte att sortera. Du kan uttryckligen välja icke skiftlägeskänslighet genom att ange _CI. |
| Accentkänsligt (_AS) | Skiljer mellan betydda och obetydda tecken.
a är till exempel inte lika med ấ. Om det här alternativet inte är markerat är sorteringen okänslig för accenter. Det vill säga, SQL Server anser att de accenterade och oaccenterade versionerna av bokstäver är identiska för sorteringsändamål. Du kan uttryckligen välja accentokänslighet genom att ange _AI. |
| Kana-känslig (_KS) | Skiljer mellan de två typerna av japanska kana-tecken: Hiragana och Katakana. Om det här alternativet inte är markerat är sorteringen kana-okänslig. Det vill säga att SQL Server anser att Hiragana- och Katakana-tecken är lika för sortering. Att utelämna det här alternativet är den enda metoden för att ange insensitivitet för kana. |
| Breddkänslig (_WS) | Skiljer mellan tecken med full bredd och halv bredd. Om det här alternativet inte är markerat anser SQL Server att representationen med full bredd och halv bredd av samma tecken är identisk i sorteringssyfte. Att utelämna det här alternativet är den enda metoden för att ange width-insensitivity. |
| Variantväljarkänslig (_VSS) | Skiljer mellan olika ideografiska variantväljare i de japanska sorteringarna Japanese_Bushu_Kakusu_140 och Japanese_XJIS_140, som introduceras i SQL Server 2017 (14.x). En variantsekvens består av ett bastecken plus en variantväljare. Om det här _VSS alternativet inte är markerat är sorteringen variant-selector-insensitiv och variantväljaren beaktas inte i jämförelsen. Sql Server anser alltså att tecken som bygger på samma grundtecken med olika variantväljare är identiska i sorteringssyfte. Mer information finns i Unicode Ideographic Variant Database.Sorteringsordningar med variantselektor (_VSS) stöds inte i fulltextsökningsindex. Fulltextindex stöder endast Accent-Sensitive (_AS), Kana-känsliga (_KS) och breddkänsliga (_WS) alternativ. SQL Server XML och CLR () integration (Common Language Runtime) motorer stöder inte (_VSS) variantväljare. |
| Binärt (_BIN) 1 | Sorterar och jämför data i SQL Server-tabeller baserat på bitmönster som definierats för varje tecken. Binär sorteringsordning är skiftlägeskänslig och accentkänslig. Binärt är också den snabbaste sorteringsordningen. Mer information finns i avsnittet Binära sorteringar i den här artikeln. |
| Binärkodspunkt (_BIN2) 1 | Sorterar och jämför data i SQL Server-tabeller baserat på Unicode-kodpunkter för Unicode-data. För icke-Unicode-data använder binärkodspunkten jämförelser som är identiska med dem för binära sorteringar. Fördelen med att använda en sorteringsordning för binärkodspunkter är att ingen omsortering av data krävs i program som jämför data som sorterats i SQL Server. Därför ger en sorteringsordning för binärkodspunkter enklare programutveckling och möjliga prestandaökningar. Mer information finns i avsnittet Binära sorteringar i den här artikeln. |
| UTF-8 (_UTF8) | Gör att UTF-8-kodade data kan lagras i SQL Server. Om det här alternativet inte är markerat använder SQL Server standardformatet för icke-Unicode-kodning för tillämpliga datatyper. Mer information finns i avsnittet UTF-8 Support i den här artikeln. |
1 Om binär- eller binärkodspunkt har valts är alternativen Skiftlägeskänsliga (_CS), dekorkänsliga (_AS), Kana-känsliga (_KS) och Breddkänsliga (_WS) inte tillgängliga.
Exempel på sorteringsalternativ
Varje sortering kombineras som en serie suffix för att definiera skiftläges-, accent-, bredd- eller kana-känslighet. I följande exempel beskrivs sorteringsordningens beteende för olika kombinationer av suffix.
| Windows-sorteringssuffix | Beskrivning av sorteringsordning |
|---|---|
| _BIN 1 | Binär sortering |
| _BIN2 1, 2 | Sorteringsordning för binär kodpunkt |
| _CI_AI 2 | Skiftlägesokänslig, accentokänslig, kanaokänslig, breddokänslig |
| _CI_AI_KS 2 | Skiftlägesokänslig, accentokänslig, kana-känslig, breddokänslig |
| _CI_AI_KS_WS 2 | Skiftlägesokänslig, accentokänslig, kana-känslig, breddkänslig |
| _CI_AI_WS 2 | Okänslig för skiftläge, okänslig för accenter, kana-okänslig, breddkänslig |
| _CI_AS 2 | Skiftlägesokänslig, accentkänslig, kana-okänslig, breddokänslig |
| _CI_AS_KS 2 | Skiftlägesokänslig, accentkänslig, kana-känslig, breddokänslig |
| _CI_AS_KS_WS 2 | Okänslig för skiftläge, accentkänslig, kana-känslig, breddkänslig |
| _CI_AS_WS 2 | Skiftlägesokänslig, accentkänslig, kana-okänslig, breddkänslig |
| _CS_AI 2 | Skiftläges-känslig, accent-okänslig, kana-okänslig, bredd-okänslig |
| _CS_AI_KS 2 | Skiftlägeskänslig, accentokänslig, kana-känslig, breddokänslig |
| _CS_AI_KS_WS 2 | Skiftlägeskänslig, accent-känslig, kana-känslig, breddkänslig |
| _CS_AI_WS 2 | Skiftlägeskänslig, accent-okänslig, kana-okänslig, breddkänslig |
| _CS_AS 2 | Skiftlägeskänslig, accentkänslig, kana-okänslig, breddokänslig |
| _CS_AS_KS 2 | Skiftlägeskänslig, accentkänslig, kanakänslig, breddokänslig |
| _CS_AS_KS_WS 2 | Skiftlägeskänslig, accentkänslig, kanakänslig, breddkänslig |
| _CS_AS_WS 2 | Skiftlägeskänslig, accentkänslig, kanaokänslig, breddkänslig |
1 Om binär- eller binärkodspunkt har valts är alternativen Skiftlägeskänsliga (_CS), dekorkänsliga (_AS), Kana-känsliga (_KS) och Breddkänsliga (_WS) inte tillgängliga.
2 Om du lägger till UTF-8-alternativet (_UTF8) kan du koda Unicode-data med hjälp av UTF-8. Mer information finns i avsnittet UTF-8 Support i den här artikeln.
Sorteringsuppsättningar
SQL Server stöder följande sorteringsuppsättningar:
Windows-kollationer
Windows-sorteringsordningar definierar regler för lagring av teckendata som baseras på systemets associerade nationella inställningar i Windows. För en Windows-sortering kan du implementera en jämförelse av icke-Unicode-data med hjälp av samma algoritm som för Unicode-data. De grundläggande Windows-sorteringsreglerna anger vilket alfabet eller språk som används när ordlistesortering tillämpas. Reglerna anger också den kodsida som används för att lagra teckendata som inte är Unicode-tecken. Både Unicode- och icke-Unicode-sortering är kompatibla med strängjämförelser i en viss version av Windows. Detta ger konsekvens mellan datatyper i SQL Server och gör att utvecklare kan sortera strängar i sina program med hjälp av samma regler som används av SQL Server. För mer information, se Windows-sammanställningsnamn.
Binär sortering
Binär sortering sorterar data baserat på sekvensen med kodade värden som definieras av nationella inställningar och datatyp. De är skiftlägeskänsliga. En binär sortering i SQL Server definierar språkvarianten och ansi-kodsidan som används. Detta framtvingar en binär sorteringsordning. Eftersom de är relativt enkla kan binära sorteringar förbättra programmets prestanda. För datatyper som inte är Unicode baseras datajämförelser på de kodpunkter som definieras på ANSI-kodsidan. För Unicode-datatyper baseras datajämförelser på Unicode-kodpunkterna. För binära sorteringar på Unicode-datatyper beaktas inte nationella inställningar i datasortering. Till exempel ger Latin1_General_BIN och Japanese_BIN identiska sorteringsresultat när de används på Unicode-data. För mer information, se Windows-sammanställningsnamn.
Det finns två typer av binära sorteringsordningar i SQL Server.
De äldre
BINsorteringar, som utförde en ofullständig jämförelse av kodpunkt-till-kodpunkt för Unicode-data. Äldre binära sorteringar jämförde det första tecknet som WCHAR, följt av en jämförelse mellan byte och byte. I en BIN-sortering sorteras endast det första tecknet enligt kodpunkten och återstående tecken sorteras enligt bytevärdena.De nyare
BIN2sorteringarna, som implementerar en ren jämförelse av kodpunkter. I en BIN2-sortering sorteras alla tecken enligt deras kodpunkter. Eftersom Intel-plattformen är lite endiansk arkitektur lagras unicode-kodtecken alltid byte-växlade.
SQL Server-sortering
SQL Server-sortering (SQL_*) ger sorteringsordningskompatibilitet med tidigare versioner av SQL Server. Sorteringsreglerna för icke-Unicode-data är inte kompatibla med sorteringsrutiner som tillhandahålls av Windows-operativsystem. Att sortera Unicode-data är dock kompatibelt med en viss version av Windows-sorteringsregler. Eftersom SQL Server-sortering använder olika jämförelseregler för icke-Unicode- och Unicode-data ser du olika resultat för jämförelser av samma data, beroende på den underliggande datatypen.
Om du till exempel använder SQL-sortering SQL_Latin1_General_CP1_CI_ASär strängen som inte är Unicode 'a-c' mindre än strängen 'ab' eftersom bindestrecket (-) sorteras som ett separat tecken som kommer före b. Men om du konverterar dessa strängar till Unicode och utför samma jämförelse anses Unicode-strängen N'a-c' vara större än N'ab'eftersom Unicode-sorteringsreglerna använder en ordsortering som ignorerar bindestrecket.
Mer information finns i SQL Server-sorteringsnamn.
Under konfigurationen av SQL Server bestäms standardinställningen för installationssortering av operativsystemets nationella inställningar. Du kan ändra sortering på servernivå antingen under installationen eller genom att ändra operativsystemets nationella inställningar före installationen. Av bakåtkompatibilitetsskäl är standardsortering inställd på den äldsta tillgängliga versionen som är associerad med varje specifik språkvariant. Därför är detta inte alltid den rekommenderade sorteringen. Om du vill dra full nytta av SQL Server-funktioner ändrar du standardinstallationsinställningarna för att använda Windows-sortering. För exempelvis den lokala inställningen "Engelska (USA)" (kodsida 1252) är standardsorteringen SQL_Latin1_General_CP1_CI_ASvid installationen, och den kan ändras till närmaste motsvarighet för Windows-sortering, Latin1_General_100_CI_AS_SC.
När du uppgraderar en engelskspråkig instans av SQL Server kan du ange SQL Server-sortering (SQL_*) för kompatibilitet med befintliga instanser av SQL Server. Eftersom standardsortering för en instans av SQL Server definieras under installationen kontrollerar du att du anger sorteringsinställningarna noggrant när följande villkor är uppfyllda:
- Din programkod beror på beteendet för tidigare SQL Server-sortering.
- Du måste lagra teckendata som återspeglar flera språk.
Sorteringsnivåer
Inställningssortering stöds på följande nivåer i en instans av SQL Server:
- sorteringsregler på servernivå
- Sorteringsordningar på databasnivå
- kollationer på kolumnnivå
- Kollationering på uttrycksnivå
Sortering på servernivå
Standardserversortering bestäms under SQL Server-konfigurationen och blir standardsortering av systemdatabaserna och alla användardatabaser.
I följande tabell visas standardsorteringsbeteckningarna enligt operativsystemets nationella inställningar, inklusive deras Windows- och SQL Language Code-identifierare (LCID):
| Nationella inställningar för Windows | Windows LCID (lokaliserings-ID) | SQL LCID | Standardsorteringsordning |
|---|---|---|---|
| Afrikaans (Sydafrika) | 0x0436 | 0x0409 | Latin1_General_CI_AS |
| Albanska (Albanien) | 0x041c | 0x041c | Albanian_CI_AS |
| Alsatian (Frankrike) | 0x0484 | 0x0409 | Latin1_General_CI_AS |
| Amhariska (Etiopien) | 0x045e | 0x0409 | Latin1_General_CI_AS |
| Arabiska (Algeriet) | 0x1401 | 0x0401 | Arabic_CI_AS |
| Arabiska (Bahrain) | 0x3c01 | 0x0401 | Arabic_CI_AS |
| Arabiska (Egypten) | 0x0c01 | 0x0401 | Arabic_CI_AS |
| Arabiska (Irak) | 0x0801 | 0x0401 | Arabic_CI_AS |
| Arabiska (Jordanien) | 0x2c01 | 0x0401 | Arabic_CI_AS |
| Arabiska (Kuwait) | 0x3401 | 0x0401 | Arabic_CI_AS |
| Arabiska (Libanon) | 0x3001 | 0x0401 | Arabic_CI_AS |
| Arabiska (Libyen) | 0x1001 | 0x0401 | Arabic_CI_AS |
| Arabiska (Marocko) | 0x1801 | 0x0401 | Arabic_CI_AS |
| Arabiska (Oman) | 0x2001 | 0x0401 | Arabic_CI_AS |
| Arabiska (Qatar) | 0x4001 | 0x0401 | Arabic_CI_AS |
| Arabiska (Saudiarabien) | 0x0401 | 0x0401 | Arabic_CI_AS |
| Arabiska (Syrien) | 0x2801 | 0x0401 | Arabic_CI_AS |
| Arabiska (Tunisien) | 0x1c01 | 0x0401 | Arabic_CI_AS |
| Arabiska (U.A.E.) | 0x3801 | 0x0401 | Arabic_CI_AS |
| Arabiska (Jemen) | 0x2401 | 0x0401 | Arabic_CI_AS |
| Armeniska (Armenien) | 0x042b | 0x0419 | Latin1_General_CI_AS |
| Assamese (Indien) | 0x044d | 0x044d | Inte tillgängligt på servernivå |
| Azerbajdzjan (Azerbajdzjan, kyrillisk) | 0x082c | 0x082c | Inaktuell, inte tillgänglig på servernivå |
| Azerbajdzjan (Azerbajdzjan, latinsk) | 0x042c | 0x042c | Inaktuell, inte tillgänglig på servernivå |
| Bashkir (Ryssland) | 0x046d | 0x046d | Latin1_General_CI_AI |
| Baskiska | 0x042d | 0x0409 | Latin1_General_CI_AS |
| Vitryska (Vitryssland) | 0x0423 | 0x0419 | Cyrillic_General_CI_AS |
| Bangla (Bangladesh) | 0x0845 | 0x0445 | Inte tillgängligt på servernivå |
| Bengali (Indien) | 0x0445 | 0x0439 | Inte tillgängligt på servernivå |
| Bosniska (Bosnien och Hercegovina, kyrillisk) | 0x201a | 0x201a | Latin1_General_CI_AI |
| Bosniska (Bosnien och Hercegovina, latin) | 0x141a | 0x141a | Latin1_General_CI_AI |
| Breton (Frankrike) | 0x047e | 0x047e | Latin1_General_CI_AI |
| Bulgariska (Bulgarien) | 0x0402 | 0x0419 | Cyrillic_General_CI_AS |
| Katalanska (katalanska) | 0x0403 | 0x0409 | Latin1_General_CI_AS |
| Kinesiska (Hongkong SAR, Folkrepubliken Kina) | 0x0c04 | 0x0404 | Kinesiska_Taiwan_Stroke_CI_AS |
| Kinesiska (Macao Särskild Administrativ Region) | 0x1404 | 0x1404 | Latin1_General_CI_AI |
| Kinesiska (Macao Särskild Administrativ Region) | 0x21404 | 0x21404 | Latin1_General_CI_AI |
| Kinesiska (Folkrepubliken Kina) | 0x0804 | 0x0804 | Chinese_PRC_CI_AS |
| Kinesiska (Folkrepubliken Kina) | 0x20804 | 0x20804 | Chinese_PRC_Stroke_CI_AS |
| Kinesiska (Singapore) | 0x1004 | 0x0804 | Chinese_PRC_CI_AS |
| Kinesiska (Singapore) | 0x21004 | 0x20804 | Chinese_PRC_Stroke_CI_AS |
| Kinesiska (Taiwan) | 0x30404 | 0x30404 | Chinese_Taiwan_Bopomofo_CI_AS |
| Kinesiska (Taiwan) | 0x0404 | 0x0404 | Kinesiska_Taiwan_Stroke_CI_AS |
| Korsikan (Frankrike) | 0x0483 | 0x0483 | Latin1_General_CI_AI |
| Kroatiska (Bosnien och Hercegovina, latin) | 0x101a | 0x041a | Croatian_CI_AS |
| Kroatiska (Kroatien) | 0x041a | 0x041a | Croatian_CI_AS |
| Tjeckiska (Tjeckien) | 0x0405 | 0x0405 | Czech_CI_AS |
| Danska (Danmark) | 0x0406 | 0x0406 | Danish_Norwegian_CI_AS |
| Dari (Afghanistan) | 0x048c | 0x048c | Latin1_General_CI_AI |
| Divehi (Maldiverna) | 0x0465 | 0x0465 | Inte tillgängligt på servernivå |
| Nederländska (Belgien) | 0x0813 | 0x0409 | Latin1_General_CI_AS |
| Nederländska (Nederländerna) | 0x0413 | 0x0409 | Latin1_General_CI_AS |
| Engelska (Australien) | 0x0c09 | 0x0409 | Latin1_General_CI_AS |
| Engelska (Belize) | 0x2809 | 0x0409 | Latin1_General_CI_AS |
| Engelska (Kanada) | 0x1009 | 0x0409 | Latin1_General_CI_AS |
| Engelska (Karibien) | 0x2409 | 0x0409 | Latin1_General_CI_AS |
| Engelska (Indien) | 0x4009 | 0x0409 | Latin1_General_CI_AS |
| Engelska (Irland) | 0x1809 | 0x0409 | Latin1_General_CI_AS |
| Engelska (Jamaica) | 0x2009 | 0x0409 | Latin1_General_CI_AS |
| Engelska (Malaysia) | 0x4409 | 0x0409 | Latin1_General_CI_AS |
| Engelska (Nya Zeeland) | 0x1409 | 0x0409 | Latin1_General_CI_AS |
| Engelska (Filippinerna) | 0x3409 | 0x0409 | Latin1_General_CI_AS |
| Engelska (Singapore) | 0x4809 | 0x0409 | Latin1_General_CI_AS |
| Engelska (Sydafrika) | 0x1c09 | 0x0409 | Latin1_General_CI_AS |
| Engelska (Trinidad och Tobago) | 0x2c09 | 0x0409 | Latin1_General_CI_AS |
| Engelska (Storbritannien) | 0x0809 | 0x0409 | Latin1_General_CI_AS |
| Engelska (USA) | 0x0409 | 0x0409 | SQL_Latin1_General_CP1_CI_AS |
| Engelska (Zimbabwe) | 0x3009 | 0x0409 | Latin1_General_CI_AS |
| Estniska (Estland) | 0x0425 | 0x0425 | Estonian_CI_AS |
| Färöiska (Färöarna) | 0x0438 | 0x0409 | Latin1_General_CI_AS |
| Filipino (Filippinerna) | 0x0464 | 0x0409 | Latin1_General_CI_AS |
| Finska (Finland) | 0x040b | 0x040b | Finnish_Swedish_CI_AS |
| Franska (Belgien) | 0x080c | 0x040c | French_CI_AS |
| Franska (Kanada) | 0x0c0c | 0x040c | French_CI_AS |
| Franska (Frankrike) | 0x040c | 0x040c | French_CI_AS |
| Franska (Luxemburg) | 0x140c | 0x040c | French_CI_AS |
| Franska (Monaco) | 0x180c | 0x040c | French_CI_AS |
| Franska (Schweiz) | 0x100c | 0x040c | French_CI_AS |
| Frisian (Nederländerna) | 0x0462 | 0x0462 | Latin1_General_CI_AI |
| Galiciska | 0x0456 | 0x0409 | Latin1_General_CI_AS |
| Georgiska (Georgien) | 0x10437 | 0x10437 | Georgian_Modern_Sort_CI_AS |
| Georgiska (Georgien) | 0x0437 | 0x0419 | Latin1_General_CI_AS |
| Tyska – Sortering enligt telefonkatalog (DIN) | 0x10407 | 0x10407 | German_PhoneBook_CI_AS |
| Tyska (Österrike) | 0x0c07 | 0x0409 | Latin1_General_CI_AS |
| Tyska (Tyskland) | 0x0407 | 0x0409 | Latin1_General_CI_AS |
| Tyska (Liechtenstein) | 0x1407 | 0x0409 | Latin1_General_CI_AS |
| Tyska (Luxemburg) | 0x1007 | 0x0409 | Latin1_General_CI_AS |
| Tyska (Schweiz) | 0x0807 | 0x0409 | Latin1_General_CI_AS |
| Grekiska (Grekland) | 0x0408 | 0x0408 | Greek_CI_AS |
| Grönländska (Grönland) | 0x046f | 0x0406 | Danish_Norwegian_CI_AS |
| Gujarati (Indien) | 0x0447 | 0x0439 | Inte tillgängligt på servernivå |
| Hausa (Nigeria, Latin) | 0x0468 | 0x0409 | Latin1_General_CI_AS |
| Hebreiska (Israel) | 0x040d | 0x040d | Hebrew_CI_AS |
| Hindi (Indien) | 0x0439 | 0x0439 | Inte tillgängligt på servernivå |
| Ungerska (Ungern) | 0x040e | 0x040e | Hungarian_CI_AS |
| Ungersk teknisk sortering | 0x1040e | 0x1040e | Hungarian_Technical_CI_AS |
| Isländska (Island) | 0x040f | 0x040f | Icelandic_CI_AS |
| Igbo (Nigeria) | 0x0470 | 0x0409 | Latin1_General_CI_AS |
| Indonesiska (Indonesien) | 0x0421 | 0x0409 | Latin1_General_CI_AS |
| Inuktitut (Kanada, Latin) | 0x085d | 0x0409 | Latin1_General_CI_AS |
| Inuktitut (Syllabics) Kanada | 0x045d | 0x045d | Latin1_General_CI_AI |
| Irländska (Irland) | 0x083c | 0x0409 | Latin1_General_CI_AS |
| Italienska (Italien) | 0x0410 | 0x0409 | Latin1_General_CI_AS |
| Italienska (Schweiz) | 0x0810 | 0x0409 | Latin1_General_CI_AS |
| Japanska (Japan XJIS) | 0x0411 | 0x0411 | Japanese_CI_AS |
| Japanska (Japan) | 0x040411 | 0x40411 | Latin1_General_CI_AI |
| Kannada (Indien) | 0x044b | 0x0439 | Inte tillgängligt på servernivå |
| Kazakiska (Kazakstan) | 0x043f | 0x043f | Kazakh_90_CI_AS |
| Khmer (Kambodja) | 0x0453 | 0x0453 | Inte tillgängligt på servernivå |
| K'iche (Guatemala) | 0x0486 | 0x0c0a | Modern_Spanish_CI_AS |
| Kinyarwanda (Rwanda) | 0x0487 | 0x0409 | Latin1_General_CI_AS |
| Konkani (Indien) | 0x0457 | 0x0439 | Inte tillgängligt på servernivå |
| Koreanska (Ordlistesortering i Korea) | 0x0412 | 0x0412 | Korean_Wansung_CI_AS |
| Kirgiziska (Kirgizistan) | 0x0440 | 0x0419 | Cyrillic_General_CI_AS |
| Lao (Lao PDR) | 0x0454 | 0x0454 | Inte tillgängligt på servernivå |
| Lettiska (Lettland/Latvia) | 0x0426 | 0x0426 | Latvian_CI_AS |
| Litauiska (Litauen) | 0x0427 | 0x0427 | Lithuanian_CI_AS |
| Lägre sorbian (Tyskland) | 0x082e | 0x0409 | Latin1_General_CI_AS |
| Luxemburgska (Luxemburg) | 0x046e | 0x0409 | Latin1_General_CI_AS |
| Makedonska språket (Nordmakedonien) | 0x042f | 0x042f | Macedonian_FYROM_90_CI_AS |
| Malay (Brunei Darussalam) | 0x083e | 0x0409 | Latin1_General_CI_AS |
| Malaysiska (Malaysia) | 0x043e | 0x0409 | Latin1_General_CI_AS |
| Malayalam (Indien) | 0x044c | 0x0439 | Inte tillgängligt på servernivå |
| Maltesiska (Malta) | 0x043a | 0x043a | Latin1_General_CI_AI |
| Maori (Nya Zeeland) | 0x0481 | 0x0481 | Latin1_General_CI_AI |
| Mapudungun (Chile) | 0x047a | 0x047a | Latin1_General_CI_AI |
| Marathi (Indien) | 0x044e | 0x0439 | Inte tillgängligt på servernivå |
| Mohawk (Kanada) | 0x047c | 0x047c | Latin1_General_CI_AI |
| Mongoliska (Mongoliet) | 0x0450 | 0x0419 | Cyrillic_General_CI_AS |
| Mongoliska (Folkrepubliken Kina) | 0x0850 | 0x0419 | Cyrillic_General_CI_AS |
| Nepali (Nepal) | 0x0461 | 0x0461 | Inte tillgängligt på servernivå |
| Norska (Bokmål, Norge) | 0x0414 | 0x0414 | Latin1_General_CI_AI |
| Norska (Nynorsk, Norge) | 0x0814 | 0x0414 | Latin1_General_CI_AI |
| Occitan (Frankrike) | 0x0482 | 0x040c | French_CI_AS |
| Odia (Indien) | 0x0448 | 0x0439 | Inte tillgängligt på servernivå |
| Pashto (Afghanistan) | 0x0463 | 0x0463 | Inte tillgängligt på servernivå |
| Persiska (Iran) | 0x0429 | 0x0429 | Latin1_General_CI_AI |
| Polska (Polen) | 0x0415 | 0x0415 | Polish_CI_AS |
| Portugisiska (Brasilien) | 0x0416 | 0x0409 | Latin1_General_CI_AS |
| Portugisiska (Portugal) | 0x0816 | 0x0409 | Latin1_General_CI_AS |
| Punjabi (Indien) | 0x0446 | 0x0439 | Inte tillgängligt på servernivå |
| Quechua (Bolivia) | 0x046b | 0x0409 | Latin1_General_CI_AS |
| Quechua (Ecuador) | 0x086b | 0x0409 | Latin1_General_CI_AS |
| Quechua (Peru) | 0x0c6b | 0x0409 | Latin1_General_CI_AS |
| Rumänska (Rumänien) | 0x0418 | 0x0418 | Romanian_CI_AS |
| Romansh (Schweiz) | 0x0417 | 0x0417 | Latin1_General_CI_AI |
| Ryska (Ryssland) | 0x0419 | 0x0419 | Cyrillic_General_CI_AS |
| Sakha (Ryssland) | 0x0485 | 0x0485 | Latin1_General_CI_AI |
| Samiska (Inari, Finland) | 0x243b | 0x083b | Latin1_General_CI_AI |
| Samiska (Lule, Norge) | 0x103b | 0x043b | Latin1_General_CI_AI |
| Samiska (Lule, Sverige) | 0x143b | 0x083b | Latin1_General_CI_AI |
| Samiska (norra, Finland) | 0x0c3b | 0x083b | Latin1_General_CI_AI |
| Samiska (norra, Norge) | 0x043b | 0x043b | Latin1_General_CI_AI |
| Samiska (norra, Sverige) | 0x083b | 0x083b | Latin1_General_CI_AI |
| Samiska (Skolt, Finland) | 0x203b | 0x083b | Latin1_General_CI_AI |
| Samiska (södra, Norge) | 0x183b | 0x043b | Latin1_General_CI_AI |
| Samiska (Södra, Sverige) | 0x1c3b | 0x083b | Latin1_General_CI_AI |
| Sanskrit (Indien) | 0x044f | 0x0439 | Inte tillgängligt på servernivå |
| Serbiska (Bosnien och Hercegovina, kyrillisk) | 0x1c1a | 0x0c1a | Latin1_General_CI_AI |
| Serbiska (Bosnien och Hercegovina, latin) | 0x181a | 0x081a | Latin1_General_CI_AI |
| Serbiska (Serbien, kyrillisk) | 0x0c1a | 0x0c1a | Latin1_General_CI_AI |
| Serbiska (Serbien, latin) | 0x081a | 0x081a | Latin1_General_CI_AI |
| Sesotho sa Leboa/Northern Sotho (Sydafrika) | 0x046c | 0x0409 | Latin1_General_CI_AS |
| Setswana/Tswana (Sydafrika) | 0x0432 | 0x0409 | Latin1_General_CI_AS |
| Sinhala (Sri Lanka) | 0x045b | 0x0439 | Inte tillgängligt på servernivå |
| Slovakiska (Slovakien) | 0x041b | 0x041b | Slovak_CI_AS |
| Slovenska (Slovenien) | 0x0424 | 0x0424 | Slovenian_CI_AS |
| Spanska (Argentina) | 0x2c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanska (Bolivia) | 0x400a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanska (Chile) | 0x340a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanska (Colombia) | 0x240a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanska (Costa Rica) | 0x140a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanska (Dominikanska republiken) | 0x1c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanska (Ecuador) | 0x300a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanska (El Salvador) | 0x440a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanska (Guatemala) | 0x100a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanska (Honduras) | 0x480a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanska (Mexiko) | 0x080a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanska (Nicaragua) | 0x4c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanska (Panama) | 0x180a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanska (Paraguay) | 0x3c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanska (Peru) | 0x280a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanska (Puerto Rico) | 0x500a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanska (Spanien) | 0x0c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanska (Spanien, traditionell sortering) | 0x040a | 0x040a | Traditional_Spanish_CI_AS |
| Spanska (USA) | 0x540a | 0x0409 | Latin1_General_CI_AS |
| Spanska (Uruguay) | 0x380a | 0x0c0a | Modern_Spanish_CI_AS |
| Spanska (Venezuela) | 0x200a | 0x0c0a | Modern_Spanish_CI_AS |
| Swahili (Kenya) | 0x0441 | 0x0409 | Latin1_General_CI_AS |
| Svenska (Finland) | 0x081d | 0x040b | Finnish_Swedish_CI_AS |
| Svenska (Sverige) | 0x041d | 0x040b | Finnish_Swedish_CI_AS |
| Syrien (Syrien) | 0x045a | 0x045a | Inte tillgängligt på servernivå |
| Tadzjikistan | 0x0428 | 0x0419 | Cyrillic_General_CI_AS |
| Tamazight (Algeriet, Latin) | 0x085f | 0x085f | Latin1_General_CI_AI |
| Tamil (Indien) | 0x0449 | 0x0439 | Inte tillgängligt på servernivå |
| Tatar (Ryssland) | 0x0444 | 0x0444 | Cyrillic_General_CI_AS |
| Telugu (Indien) | 0x044a | 0x0439 | Inte tillgängligt på servernivå |
| Thai (Thailand) | 0x041e | 0x041e | Thai_CI_AS |
| Tibetansk (Kina, folkrepubliken) | 0x0451 | 0x0451 | Inte tillgängligt på servernivå |
| Turkiska (Turkiet) | 0x041f | 0x041f | Turkish_CI_AS |
| Turkmen (Turkmenistan) | 0x0442 | 0x0442 | Latin1_General_CI_AI |
| Uiguriska (Folkrepubliken Kina) | 0x0480 | 0x0480 | Latin1_General_CI_AI |
| Ukrainska (Ukraina) | 0x0422 | 0x0422 | Ukrainian_CI_AS |
| Övre sorbiska (Tyskland) | 0x042e | 0x042e | Latin1_General_CI_AI |
| Urdu (Pakistan) | 0x0420 | 0x0420 | Latin1_General_CI_AI |
| Uzbekiska (Uzbekistan, kyrillisk) | 0x0843 | 0x0419 | Cyrillic_General_CI_AS |
| Uzbekiska (Uzbekistan, latinskt) | 0x0443 | 0x0443 | Uzbek_Latin_90_CI_AS |
| Vietnamesiska (Vietnam) | 0x042a | 0x042a | Vietnamese_CI_AS |
| Welsh (Storbritannien) | 0x0452 | 0x0452 | Latin1_General_CI_AI |
| Wolof (Senegal) | 0x0488 | 0x040c | French_CI_AS |
| Xhosa/isiXhosa (Sydafrika) | 0x0434 | 0x0409 | Latin1_General_CI_AS |
| Yi (Folkrepubliken Kina) | 0x0478 | 0x0409 | Latin1_General_CI_AS |
| Yoruba (Nigeria) | 0x046a | 0x0409 | Latin1_General_CI_AS |
| Zulu/isiZulu (Sydafrika) | 0x0435 | 0x0409 | Latin1_General_CI_AS |
När du har tilldelat en sortering till servern kan du bara ändra den genom att exportera alla databasobjekt och data, återskapa master-databasen och importera alla databasobjekt och data. I stället för att ändra standardsortering för en instans av SQL Server kan du ange önskad sortering när du skapar en ny databas eller databaskolumn.
För att kontrollera serversorteringen för en instans av SQL Server använder du funktionen SERVERPROPERTY:
SELECT CONVERT (NVARCHAR (128), SERVERPROPERTY('collation'));
Om du vill fråga servern efter alla tillgängliga sorteringar använder du följande fn_helpcollations() inbyggd funktion:
SELECT *
FROM sys.fn_helpcollations();
Teckenuppsättningar i Azure SQL Database
Du kan inte ändra eller ange den logiska serversorteringen i Azure SQL Database, men du kan konfigurera varje databassortering både för data och för katalogen. Katalogsortering avgör sortering för systemmetadata, till exempel objektidentifierare. Båda sorteringarna kan anges oberoende av varandra när du skapa databasen i Azure-portaleni T-SQL med CREATE DATABASEi PowerShell med New-AzSqlDatabase.
Sorteringsordningar i Azure SQL Managed Instance
Sortering på servernivå i Azure SQL Managed Instance kan anges när instansen skapas och kan inte ändras senare.
Mer information finns i Ange eller Ändra serversortering.
Sortering på databasnivå
När du skapar eller ändrar en databas kan du använda COLLATE-satsen i instruktionen CREATE DATABASE eller ALTER DATABASE för att ange standarddatabassortering. Om ingen sortering har angetts tilldelas databasen serversortering.
Du kan inte ändra sortering av systemdatabaser om du inte ändrar sortering för servern.
- I SQL Server och Azure SQL Managed Instance används databassortering för alla metadata i databasen och sorteringen är standard för alla strängkolumner, temporära objekt, variabelnamn och andra strängar som används i databasen.
- I Azure SQL Database finns det ingen serversortering, så varje databas har en sortering för data och en sortering för katalogen. CATALOG_COLLATION används för alla metadata i databasen och sorteringen är standard för alla strängkolumner, temporära objekt, variabelnamn och andra strängar som används i databasen. Den CATALOG_COLLATION har angetts när den skapas och kan inte ändras.
När du ändrar sortering av en användardatabas kan det uppstå sorteringskonflikter när frågor i databasen får åtkomst till tillfälliga tabeller. Temporära tabeller lagras alltid i tempdb systemdatabas, som använder sortering för instansen. Frågor som jämför teckendata mellan användardatabasen och tempdb kan misslyckas om sorteringarna orsakar en konflikt vid utvärdering av teckendata. Du kan lösa det här problemet genom att ange COLLATE-satsen i frågan. Mer information finns i COLLATE.
Du kan ändra sortering av en användardatabas med hjälp av en ALTER DATABASE-instruktion som liknar följande kodexempel:
ALTER DATABASE myDB COLLATE Greek_CS_AI;
Viktig
Att ändra sortering på databasnivå påverkar inte sortering på kolumnnivå eller uttrycksnivå. Det påverkar inte data i befintliga kolumner.
Du kan hämta den aktuella sorteringen av en databas med hjälp av en instruktion som liknar följande kodexempel:
SELECT CONVERT (NVARCHAR (128), DATABASEPROPERTYEX('database_name', 'collation'));
Sortering på kolumnnivå
När du skapar eller ändrar en tabell kan du ange sortering för varje kolumn med teckensträngar med hjälp av COLLATE-satsen. Om du inte anger någon sortering tilldelas kolumnen standardsortering av databasen.
Du kan ändra sortering av en kolumn med hjälp av en ALTER TABLE-instruktion som liknar följande kodexempel:
ALTER TABLE myTable ALTER COLUMN mycol NVARCHAR (10) COLLATE Greek_CS_AI;
Sortering på uttrycksnivå
Sortering på uttrycksnivå anges när en instruktion körs och de påverkar hur en resultatuppsättning returneras. På så sätt kan ORDER BY sorteringsresultat vara språkspecifika. Om du vill implementera sortering på uttrycksnivå använder du en COLLATE-sats, till exempel följande kodexempel:
SELECT name
FROM customer
ORDER BY name COLLATE Latin1_General_CS_AI;
Platsinställning
En lokalitet är en uppsättning information som är associerad med en plats eller en kultur. Informationen kan innehålla namnet och identifieraren för det talade språket, skriptet som används för att skriva språket och kulturella konventioner. Kollationeringar kan associeras med en eller flera lokala inställningar. För mer information, se lokala ID:n tilldelade av Microsoft.
Kodsida
En kodsida är en ordnad uppsättning tecken i ett visst skript där ett numeriskt index eller kodpunktsvärde associeras med varje tecken. En Windows-kodsida kallas vanligtvis för en teckenuppsättning eller en teckenuppsättning. Kodsidor används för att ge stöd för teckenuppsättningar och tangentbordslayouter som används av olika Windows-systemspråk.
Sorteringsordning
Sorteringsordning anger hur datavärden sorteras. Ordningen påverkar resultatet av datajämförelsen. Data sorteras med hjälp av sorteringsordningar och kan optimeras med hjälp av index.
Unicode-stöd
Unicode är en standard för att mappa kodpunkter till tecken. Eftersom den är utformad för att täcka alla tecken i alla språk i världen behöver du inte olika kodsidor för att hantera olika uppsättningar tecken.
Grunderna i Unicode
Det är svårt att lagra data på flera språk i en databas när du endast använder teckendata och kodsidor. Det är också svårt att hitta en kodsida för databasen som kan lagra alla språkspecifika tecken som krävs. Dessutom är det svårt att garantera korrekt översättning av specialtecken när de läss eller uppdateras av en mängd olika klienter som kör olika kodsidor. Databaser som stöder internationella klienter bör alltid använda Unicode-datatyper i stället för icke-Unicode-datatyper.
Tänk dig till exempel en databas med kunder i Nordamerika som måste hantera tre huvudspråk:
- Spanska namn och adresser för Mexiko
- Franska namn och adresser för Quebec
- Engelska namn och adresser för resten av Kanada och USA
När du bara använder teckenkolumner och kodsidor måste du se till att databasen installeras med en kodsida som hanterar tecknen i alla tre språken. Du måste också se till att garantera korrekt översättning av tecken från något av språken när tecknen läss av klienter som kör en kodsida för ett annat språk.
Anteckning
De kodsidor som en klient använder bestäms av inställningarna för operativsystemet (OS). Om du vill ange klientkodsidor i Windows-operativsystemet använder du regionala inställningar på Kontrollpanelen.
Det skulle vara svårt att välja en kodsida för teckendatatyper som stöder alla tecken som krävs av en global målgrupp. Det enklaste sättet att hantera teckendata i internationella databaser är att alltid använda en datatyp som stöder Unicode.
Unicode-datatyper
Om du lagrar teckendata som återspeglar flera språk i SQL Server (SQL Server 2005 (9.x) och senare) använder du Unicode-datatyper (nchar, nvarcharntext) i stället för icke-Unicode-datatyper (char, varcharoch text).
Anteckning
För Unicode-datatyper kan databasmotorn representera upp till 65 536 tecken med UCS-2 eller hela Unicode-intervallet (1 114 112 tecken) om kompletterande tecken används. Mer information om hur du aktiverar tilläggstecken finns i kompletterande tecken.
Du kan också börja med SQL Server 2019 (15.x), och om en UTF-8-aktiverad sortering (_UTF8) används, betyder det att tidigare icke-Unicode-datatyper (char och varchar) blir Unicode-datatyper med UTF-8-kodning. SQL Server 2019 (15.x) ändrar inte beteendet för tidigare befintliga Unicode-datatyper (nchar, nvarcharoch ntext), som fortsätter att använda UCS-2- eller UTF-16-kodning. Mer information finns i Skillnader i lagring mellan UTF-8 och UTF-16.
Unicode-överväganden
Betydande begränsningar är associerade med icke-Unicode-datatyper. Det beror på att en icke-Unicode-dator är begränsad till att använda en enda kodsida. Du kan få prestanda genom att använda Unicode eftersom det kräver färre kodsidekonverteringar. Unicode-sortering måste väljas individuellt på databas-, kolumn- eller uttrycksnivå eftersom de inte stöds på servernivå.
När du flyttar data från en server till en klient kanske inte din serverns sorteringsordning identifieras av äldre klientdrivrutiner. Detta kan inträffa när du flyttar data från en Unicode-server till en icke-Unicode-klient. Det bästa alternativet kan vara att uppgradera klientoperativsystemet så att de underliggande systemsorteringarna uppdateras. Om klienten har databasklientprogramvara installerad kan du överväga att tillämpa en tjänstuppdatering på databasklientprogramvaran.
Tips
Du kan också försöka använda en annan sorteringsordning för data på servern. Välj en sortering som mappar till en kodsida på klienten. Om du vill använda UTF-16-sorteringarna som är tillgängliga i SQL Server (SQL Server 2012 (11.x) och senare) för att förbättra sökningen och sortering av vissa Unicode-tecken (endast Windows-sortering) kan du välja antingen ett av de kompletterande tecknen (_SC) eller någon av sorteringarna i version 140.
Om du vill använda UTF-8-sorteringarna som är tillgängliga i SQL Server 2019 (15.x) och för att förbättra sökningen och sortering av vissa Unicode-tecken (endast Windows-sortering) måste du välja UTF-8-kodningsaktiverade sortering (_UTF8).
UTF8-flaggan kan tillämpas på:
- Språkliga kollationeringar som redan stöder tilläggstecken (_SC) eller variationsväljarkänslighet (_VSS)
- "BIN2"-binär sorteringsordning
UTF8-flaggan kan inte tillämpas på:
- Språkliga sorteringsordningar som inte stöder kompletterande tecken (_SC) eller variationsväljarkänslighet (_VSS)
- BIN binära kollationer
- SQL_*-teckenuppsättningar
Om du vill utvärdera problem som rör användning av Unicode- eller icke-Unicode-datatyper testar du ditt scenario för att mäta prestandaskillnader i din miljö. Det är en bra idé att standardisera sortering som används på system i hela organisationen och att distribuera Unicode-servrar och -klienter där det är möjligt.
I många situationer interagerar SQL Server med andra servrar eller klienter, och din organisation kan använda flera dataåtkomststandarder mellan program och serverinstanser. SQL Server-klienter är en av två huvudtyper:
- Unicode-klienter som använder OLE DB- och ODBC-version 3.7 eller senare.
- icke-Unicode-klienter som använder DB-Library och ODBC version 3.6 eller tidigare.
Följande tabell innehåller information om hur du använder flerspråkiga data med olika kombinationer av Unicode- och icke-Unicode-servrar:
| Server | Klient | Fördelar eller begränsningar |
|---|---|---|
| Unicode | Unicode | Eftersom Unicode-data används i hela systemet ger det här scenariot bästa prestanda och skydd mot skadade hämtade data. Det här är situationen med ActiveX-dataobjekt (ADO), OLE DB och ODBC version 3.7 eller senare. |
| Unicode | Icke-Unicode | I det här scenariot, särskilt med anslutningar mellan en server som kör ett nyare operativsystem och en klient som kör en tidigare version av SQL Server, eller på ett äldre operativsystem, kan det finnas begränsningar eller fel när du flyttar data till en klientdator. Unicode-data på servern försöker mappa till en motsvarande kodsida på den icke-Unicode-klienten för att konvertera data. |
| Icke-Unicode | Unicode | Det här är inte en idealisk konfiguration för att använda flerspråkiga data. Du kan inte skriva Unicode-data till icke-Unicode-servern. Det är troligt att det uppstår problem när data skickas till servrar som ligger utanför serverns kodsida. |
| Icke-Unicode | Icke-Unicode | Det här är ett mycket begränsande scenario för flerspråkiga data. Du kan bara använda en enda kodsida. |
Tilläggstecken
Unicode Consortium allokerar till varje tecken en unik kodpunkt, vilket är ett värde i intervallet 000000–10FFFF. De vanligaste tecknen har kodpunktsvärden i intervallet 000000–00FF (65 536 tecken) som passar in i ett 8-bitars eller 16-bitars ord i minnet och på disken. Det här intervallet betecknas vanligtvis som det grundläggande flerspråkiga planet (BMP).
Men Unicode Consortium har upprättat ytterligare 16 "plan" med tecken, var och en samma storlek som BMP. Med den här definitionen kan Unicode representera 1 114 112 tecken (det vill säga 216 * 17 tecken) inom kodpunktsintervallet 000000–10FFFF. Tecken med kodpunktsvärde som är större än 00FFFF kräver två till fyra på varandra följande 8-bitars ord (UTF-8) eller två på varandra följande 16-bitars ord (UTF-16). Dessa tecken utanför BMP kallas kompletterande tecken, och de ytterligare efterföljande 8-bitars eller 16-bitars orden kallas surrogatpar. Mer information om tilläggstecken, surrogater och surrogatpar finns i Unicode Standard-.
SQL Server tillhandahåller datatyper som nchar och nvarchar för att lagra Unicode-data i BMP-intervallet (000000–00FFFF), som databasmotorn kodar med UCS-2.
SQL Server 2012 (11.x) introducerade en ny serie extra teckensortering (_SC) som kan användas med nchar, nvarcharoch sql_variant datatyper för att representera det fullständiga Unicode-teckenintervallet (000000–10FFFF). Till exempel: Latin1_General_100_CI_AS_SC eller, om du använder en japansk sortering, Japanese_Bushu_Kakusu_100_CI_AS_SC.
SQL Server 2019 (15.x) utökar ytterligare teckenstöd till tecken och varchar datatyper med de nya UTF-8-aktiverade sorteringarna (_UTF8). Dessa datatyper kan också representera hela Unicode-teckenintervallet.
Anteckning
Från och med SQL Server 2017 (14.x) stöder alla nya sorteringar automatiskt ytterligare tecken.
Om du använder tilläggstecken:
Supplementära tecken kan användas i sorterings- och jämförelseoperationer i sorteringsversioner 90 eller senare.
Alla sorteringar i version 100 stöder språklig sortering med tilläggstecken.
Tilläggstecken stöds inte för användning i metadata, till exempel i namn på databasobjekt.
SC-flaggan kan tillämpas på:
- Kollationeringar för version 90
- Version 100 sorteringsordningar
SC-flaggan kan inte tillämpas på:
- Version 80 av Windows-sorteringar utan specifik version
- Binära kollationer för BIN eller BIN2
- SQL*-kollationerna
- Sorteringsordningar för version 140 (dessa behöver inte SC-flaggan eftersom de redan stöder kompletterande tecken)
I följande tabell jämförs beteendet för vissa strängfunktioner och strängoperatorer när de använder tilläggstecken med och utan extra teckenmedveten sortering (SCA):
| Strängfunktion eller operator | Med en standardiserad SCA-sortering | Utan SCA-sortering |
|---|---|---|
|
CHARINDEX LEN PATINDEX |
Surrogatparet UTF-16 räknas som en enda kodpunkt. | Surrogatparet UTF-16 räknas som två kodpunkter. |
|
VÄNSTER REPLACE OMVÄND HÖGER DELSTRÄNG SAKER |
Dessa funktioner behandlar varje surrogatpar som en enda kodpunkt och fungerar som förväntat. | Dessa funktioner kan dela upp eventuella surrogatpar och leda till oväntade resultat. |
| NCHAR | Returnerar det tecken som motsvarar det angivna Unicode-kodpunktsvärdet i intervallet 0 – 0x10FFFF. Om det angivna värdet ligger i intervallet 0 – 0xFFFF returneras ett tecken. För högre värden returneras motsvarande surrogat. | Ett värde som är högre än 0xFFFF returnerar NULL i stället för motsvarande surrogat. |
| UNICODE | Returnerar en UTF-16-kodpunkt i intervallet 0 – 0x10FFFF. | Returnerar en UCS-2-kodpunkt i intervallet 0 – 0xFFFF. |
|
Matcha ett tecken med jokertecken Jokertecken – Tecken som inte ska matchas |
Supplementära tecken stöds för alla jokerteckenoperationer. | Kompletterande tecken stöds inte för dessa jokerteckenoperationer. Andra jokerteckenoperatorer stöds. |
GB18030 stöd
GB18030 är en separat standard som används i Folkrepubliken Kina för kodning av kinesiska tecken. I GB18030 kan tecken vara 1, 2 eller 4 byte långa. SQL Server har stöd för GB18030 kodade tecken genom att känna igen dem när de kommer in på servern från ett program på klientsidan och konverterar och lagrar dem internt som Unicode-tecken. När de har lagrats på servern behandlas de som Unicode-tecken i efterföljande åtgärder.
Du kan använda valfri kinesisk sortering, helst den senaste 100-versionen. Alla sorteringar av version 100 stöder språklig sortering med GB18030 tecken. Om data innehåller tilläggstecken (surrogatpar) kan du använda SC-sorteringarna som är tillgängliga i SQL Server för att förbättra sökningen och sortering.
Anteckning
Se till att dina klientverktyg, till exempel SQL Server Management Studio, använder teckensnittet Dengxian för att korrekt visa strängar som innehåller GB18030 kodade tecken.
Stöd för komplexa skript
SQL Server har stöd för inmatning, lagring, ändring och visning av komplexa skript. Komplexa skript innehåller följande typer:
- Skript som innehåller kombinationen av text från höger till vänster och från vänster till höger, till exempel en kombination av arabisk och engelsk text.
- Skript vars tecken ändrar form beroende på deras position eller när de kombineras med andra tecken, till exempel arabiska, indiciska och thailändska tecken.
- Språk, till exempel thailändska, som kräver interna ordlistor för att känna igen ord eftersom det inte finns några pauser mellan dem.
Databasprogram som interagerar med SQL Server måste använda kontroller som stöder komplexa skript. Standardkontroller för Windows-formulär som skapas i hanterad kod är komplexskriptaktiverade.
Japanska kollationeringar har lagts till i SQL Server 2017
Från och med SQL Server 2017 (14.x) stöds nya japanska sorteringsfamiljer, med permutationer av olika alternativ (_CS, _AS, _KS, _WSoch _VSS), samt _BIN och _BIN2.
Om du vill visa en lista över dessa sorteringar kan du fråga SQL Server Database Engine:
SELECT name,
description
FROM sys.fn_helpcollations()
WHERE COLLATIONPROPERTY(name, 'Version') = 3;
Alla nya sorteringar har inbyggt stöd för tilläggstecken, så ingen av de nya 140 sorteringar har (eller behöver) SC-flaggan.
Dessa sorteringar stöds i Databasmotorindex, minnesoptimerade tabeller, kolumnlagringsindex och inbyggda kompilerade moduler.
STÖD FÖR UTF-8
SQL Server 2019 (15.x) ger fullständigt stöd för kodning av utf-8-tecken som en import- eller exportkodning och som sortering på databasnivå eller kolumnnivå för strängdata. UTF-8 tillåts i datatyperna tecken och varchar och aktiveras när du skapar eller ändrar ett objekts sortering till en sortering som har suffixet UTF8-. Ett exempel är att ändra Latin1_General_100_CI_AS_SC till Latin1_General_100_CI_AS_SC_UTF8.
UTF-8 är endast tillgängligt för Windows-sorteringar som stöder tilläggstecken (supplementära tecken), som introducerades i SQL Server 2012 (11.x). nchar och nvarchar datatyper tillåter endast UCS-2- eller UTF-16-kodning, och de förblir oförändrade.
Azure SQL Database och Azure SQL Managed Instance stöder även UTF-8 på databas- och kolumnnivå, medan SQL Managed Instance stöder detta även på servernivå.
Lagringsskillnader mellan UTF-8 och UTF-16
Unicode Consortium allokerar till varje tecken en unik kodpunkt, vilket är ett värde i intervallet 000000–10FFFF. Med SQL Server 2019 (15.x) är både UTF-8- och UTF-16-kodningar tillgängliga för att representera hela intervallet:
- Med UTF-8-kodning kräver tecken i ASCII-intervallet (000000–00007F) 1 byte, kodpunkterna 000080–0007FF kräver 2 byte, kodpunkterna 000800 – 00FFFF kräver 3 byte och kodpunkterna 0010000–0010FFFF kräver 4 byte.
- Med UTF-16-kodning kräver kodpunkterna 000000–00FFFF 2 byte och kodpunkterna 0010000–0010FFFF kräver 4 byte.
I följande tabell visas kodningslagringsbyte för varje teckenintervall och kodningstyp:
| Kodintervall (hexadecimalt) | Kodintervall (decimal) | Lagringsbyte 1 med UTF-8 | Lagringsbyte 1 med 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 |
1Lagringsbyte referera till den kodade bytelängden, inte lagringsstorleken för datatypen på disken. Mer information om lagringsstorlekar på disk finns i nchar och nvarchar samt char och varchar.
2 Kodpunktsintervallet för kompletterande tecken.
Tips
Det är en vanlig uppfattning i char och varchar eller i nchar och nvarchar, att n definierar antalet tecken. Det beror på att i exemplet med en tecken(10) kolumn kan 10 ASCII-tecken i intervallet 0–127 lagras med hjälp av en sortering, till exempel Latin1_General_100_CI_AI, eftersom varje tecken i det här intervallet endast använder 1 byte. Men i char och varchardefinierar n strängstorleken i byte (0–8 000), och i nchar och nvarchardefinierar n strängstorleken i par av byte (0–4 000).
n definierar aldrig antal tecken som kan lagras.
Om du väljer rätt Unicode-kodning och datatyp kan det ge dig betydande lagringsbesparingar eller öka ditt aktuella lagringsfotavtryck, beroende på vilket tecken som används. När du till exempel använder en latinsk sortering som är UTF-8 aktiverad, till exempel Latin1_General_100_CI_AI_SC_UTF8, lagrar en tecken(10) kolumn 10 byte och kan innehålla 10 ASCII-tecken i intervallet 0–127. Men den kan bara innehålla fem tecken i intervallet 128 – 2047 och endast tre tecken i intervallet 2048 – 65535. Eftersom en nchar(10) kolumn lagrar 10 bytepar (20 byte) kan den innehålla 10 tecken i intervallet 0–65535.
Innan du bestämmer dig för om du vill använda UTF-8- eller UTF-16-kodning för en databas eller kolumn bör du överväga fördelningen av strängdata som ska lagras:
- Om det mest är i ASCII-intervallet 0–127 (till exempel engelska) kräver varje tecken 1 byte med UTF-8 och 2 byte med UTF-16. Användning av UTF-8 ger lagringsfördelar. Om du ändrar en befintlig kolumndatatyp med ASCII-tecken i intervallet 0–127 från nchar(10) till tecken(10)och med hjälp av en UTF-8-aktiverad sortering innebär det en 50-procentig minskning av lagringskraven. Den här minskningen beror på att nchar(10) kräver 20 byte för lagring, jämfört med tecken(10), vilket kräver 10 byte för samma Unicode-strängrepresentation.
- Ovanför ASCII-intervallet kräver nästan alla latinska skript och grekiska, kyrilliska, koptiska, armeniska, hebreiska, arabiska, syriska, tāna och N'Ko 2 byte per tecken i både UTF-8 och UTF-16. I dessa fall finns det inga betydande lagringsskillnader för jämförbara datatyper (till exempel mellan att använda tecken eller nchar).
- Om det mest är östasiatiska skript (till exempel koreanska, kinesiska och japanska) kräver varje tecken 3 byte med UTF-8 och 2 byte med UTF-16. Användning av UTF-16 ger lagringsfördelar.
- Tecken i intervallet 010000 –10FFFF kräver 4 byte i både UTF-8 och UTF-16. I dessa fall finns det inga lagringsskillnader för jämförbara datatyper (till exempel mellan att använda tecken eller nchar).
Andra överväganden finns i Write International Transact-SQL Statements.
Konvertera till UTF-8
Eftersom i tecken och varchar eller i nchar och nvarchardefinierar n bytelagringsstorleken, inte antalet tecken som kan lagras, är det viktigt att fastställa den datatypstorlek som du måste konvertera till. De tecken som överskrider storleken ska trunkeras.
Anta till exempel att en kolumn definieras som nvarchar(100) som lagrar 180 byte japanska tecken. I det här exemplet kodas kolumndata för närvarande med UCS-2 eller UTF-16, som använder 2 byte per tecken. Att konvertera kolumntypen till varchar(200) räcker inte för att förhindra datatrunkering, eftersom den nya datatypen bara kan lagra 200 byte, men japanska tecken kräver 3 byte när de kodas i UTF-8. Kolumnen måste definieras som varchar(270) för att undvika dataförlust via datatrunkering.
Därför måste du i förväg veta vilken beräknad bytestorlek för kolumndefinitionen är innan du konverterar befintliga data till UTF-8 och justerar den nya datatypens storlek i enlighet med detta. Se Transact-SQL-skriptet eller SQL Notebook i GitHub-Dataexempel
Om du vill ändra kolumnsortering och datatyp i en befintlig tabell använder du någon av metoderna som beskrivs i Ange eller Ändra kolumnsortering.
Om du vill ändra databassortering, tillåta att nya objekt ärver databassortering som standard eller ändra serversortering, så att nya databaser kan ärva systemsortering som standard, kan du läsa avsnittet Relaterade uppgifter i den här artikeln.
Relaterade uppgifter
| Uppgift | Artikel |
|---|---|
| Beskriver hur du ställer in eller ändrar sortering av instansen av SQL Server. Om du ändrar serversortering ändras inte sortering av befintliga databaser. | Ange eller ändra serverns teckenuppsättning |
| Beskriver hur du anger eller ändrar sortering av en användardatabas. Om du ändrar en databassortering ändras inte sortering av befintliga tabellkolumner. | Ange eller ändra databassortering |
| Beskriver hur du anger eller ändrar sortering av en kolumn i databasen. | ange eller ändra kolumnsortering |
| Beskriver hur du returnerar sorteringsinformation på server-, databas- eller kolumnnivå. | Visa teckenuppsättningsinformation |
| Beskriver hur du skriver Transact-SQL-instruktioner som är mer portabla från ett språk till ett annat, eller stöder flera språk enklare. | Write International Transact-SQL Statements |
| Beskriver hur du ändrar språket för felmeddelanden och inställningar för hur datum, tid och valutadata används och visas. | ange ett sessionsspråk |
Relaterat innehåll
- Bästa praxis för sorteringsändring i SQL Server
- Använd unicode-teckenformat för att importera eller exportera data (SQL Server)
- Write International Transact-SQL Statements
- metodtips för SQL Server-migrering till Unicode
- Unicode Consortium
- Unicode Standard
- UTF-8-stöd i OLE DB-drivrutin för SQL Server
- SQL Server-sorteringsnamn (Transact-SQL)
- Windows-sorteringsnamn (Transact-SQL)
- Introduktion till UTF-8-stöd för SQL Server
- COLLATE (Transact-SQL)
- sorteringsföreträde
- Innehållna databaskollationer
- Välj ett språk när du skapar ett Full-Text index
- sys.fn_helpcollations (Transact-SQL)
- Single-Byte och flerbytesteckenuppsättningar