Sortering en Unicode-ondersteuning
van toepassing op:
SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)SQL Analytics-eindpunt in Microsoft FabricWarehouse in Microsoft Fabric
Sorteringen in SQL Server bieden sorteerregels, hoofdlettergevoeligheid en accentgevoeligheid voor uw gegevens. Collaties die worden gebruikt met karaktergegevens typen, zoals char en varchar, bepalen de codepagina en de overeenkomstige tekens die voor dat gegevenstype kunnen worden weergegeven.
Of u nu een nieuw exemplaar van SQL Server installeert, een databaseback-up herstelt of een server verbindt met clientdatabases, het is belangrijk om inzicht te krijgen in de landinstellingen, sorteervolgorde en hoofdlettergevoeligheid van de gegevens waarmee u werkt. Zie sys.fn_helpcollationsom de sorteringen weer te geven die beschikbaar zijn op uw exemplaar van SQL Server.
Wanneer u een sortering selecteert voor uw server, database, kolom of expressie, wijst u bepaalde kenmerken toe aan uw gegevens. Deze kenmerken zijn van invloed op de resultaten van veel bewerkingen in de database. Wanneer u bijvoorbeeld een query maakt met behulp van ORDER BY, kan de sorteervolgorde van de resultatenset afhankelijk zijn van de sortering die op de database is toegepast of is bepaald in een COLLATE-component op het expressieniveau van de query.
Voor het beste gebruik van sorteringsondersteuning in SQL Server moet u de termen begrijpen die in dit artikel zijn gedefinieerd en hoe deze betrekking hebben op de kenmerken van uw gegevens.
Sorteervolgorde
Collatie
Met een sortering worden de bitpatronen opgegeven die elk teken in een gegevensset vertegenwoordigen. Sorteringen bepalen ook de regels waarmee gegevens worden gesorteerd en vergeleken. SQL Server ondersteunt het opslaan van objecten met verschillende sorteringen in één database. Voor niet-Unicode-kolommen geeft de sorteringsinstelling de codepagina op voor de gegevens en welke tekens kunnen worden weergegeven. De gegevens die u tussen niet-Unicode-kolommen verplaatst, moeten worden geconverteerd van de broncodepagina naar de doelcodepagina.
Transact-SQL instructieresultaten kunnen variëren wanneer de instructie wordt uitgevoerd in de context van verschillende databases met verschillende sorteringsinstellingen. Gebruik indien mogelijk een gestandaardiseerde sortering voor uw organisatie. Op deze manier hoeft u de sortering niet op te geven in elk teken of Unicode-expressie. Als u moet werken met objecten met verschillende sorterings- en codepagina-instellingen, codeert u uw query's om rekening te houden met de regels van sorteringsprioriteit. Zie sorteringsprioriteitvoor meer informatie.
De opties die aan een sortering zijn gekoppeld, zijn hoofdlettergevoeligheid, accentgevoeligheid, kanagevoeligheid, breedtegevoeligheid en variatieselectorgevoeligheid. SQL Server 2019 (15.x) introduceert een extra optie voor UTF-8 codering.
U kunt deze opties opgeven door ze toe te voegen aan de sorteringsnaam. De sortering Japanese_Bushu_Kakusu_100_CS_AS_KS_WS_SC_UTF8 is bijvoorbeeld hoofdlettergevoelig, accentgevoelig, kana-gevoelig, breedtegevoelig en UTF-8 gecodeerd. Een ander voorbeeld is de sortering Japanese_Bushu_Kakusu_140_CI_AI_KS_WS_VSS, die hoofdletterongevoelig, accentongevoelig, kana-gevoelig, breedte-gevoelig en variatie-selector-gevoelig is en gebruik maakt van een verouderde codepagina voor varchar.
Het gedrag dat aan deze verschillende opties is gekoppeld, wordt beschreven in de volgende tabel:
| Optie | Beschrijving |
|---|---|
| Hoofdlettergevoelig (_CS) | Onderscheid tussen hoofdletters en kleine letters. Als deze optie is geselecteerd, worden kleine letters vóór hun hoofdletterversies gesorteerd. Als deze optie niet is geselecteerd, is de sortering niet hoofdlettergevoelig. Sql Server beschouwt de hoofdletters en kleine letters als identiek voor sorteerdoeleinden. U kunt expliciet hoofdletterongevoeligheid selecteren door _CI op te geven. |
| Accentgevoelig (_AS) | Onderscheidt tussen geaccentueerde en niet-geaccentueerde tekens.
a is bijvoorbeeld niet gelijk aan ấ. Als deze optie niet is geselecteerd, is de sortering accentongevoelig. Dat wil zeggen, SQL Server beschouwt de geaccentueerde en niet-geaccentueerde versies van tekens als identiek bij het sorteren. U kunt accentongevoeligheid expliciet selecteren door _AI op te geven. |
| Kana-gevoelig (_KS) | Onderscheid tussen de twee typen Japanse kana-tekens: Hiragana en Katakana. Als deze optie niet is geselecteerd, is de sortering kana-niet gevoelig. Dat wil zeggen, SQL Server beschouwt Hiragana- en Katakana-tekens als gelijk voor sorteerdoeleinden. Het weglaten van deze optie is de enige methode om kana-insensitiviteit op te geven. |
| Breedtegevoelig (_WS) | Onderscheid tussen tekens met volledige breedte en halve breedte. Als deze optie niet is geselecteerd, houdt SQL Server rekening met de volledige breedte en halve breedte van hetzelfde teken dat identiek is voor sorteerdoeleinden. Het weglaten van deze optie is de enige methode om breedte-ongevoeligheid op te geven. |
| Variatieselectorgevoelig (_VSS) | Onderscheidt tussen verschillende ideografische variatie-selectors in de Japanse sorteringen Japanese_Bushu_Kakusu_140 en Japanese_XJIS_140, die in SQL Server 2017 (14.x) worden geïntroduceerd. Een variatiereeks bestaat uit een basisteken plus een variatieselector. Als deze _VSS optie niet is geselecteerd, is de sortering niet gevoelig voor variatieselector en wordt de variatiekiezer niet meegenomen in de vergelijking. Sql Server beschouwt tekens die zijn gebaseerd op hetzelfde basisteken met verschillende variatieselectors die identiek zijn voor sorteerdoeleinden. Zie Unicode Ideographic Variation Databasevoor meer informatie.Sorteringen voor variatieselectiegevoelige (_VSS) worden niet ondersteund in zoekindexen in volledige tekst. Zoekindexen voor volledige tekst ondersteunen alleen Accent-Sensitive (_AS), Kana-gevoelig (_KS), en breedtegevoelig (_WS). Integratie van SQL Server XML en Common Language Runtime (CLR) engines biedt geen ondersteuning voor variatie-selectoren (_VSS). |
| Binair (_BIN) 1 | Hiermee worden gegevens in SQL Server-tabellen gesorteerd en vergeleken op basis van de bitpatronen die voor elk teken zijn gedefinieerd. Binaire sorteervolgorde is hoofdlettergevoelig en accentgevoelig. Binair is ook de snelste sorteervolgorde. Zie de sectie Binaire sorteringen in dit artikel voor meer informatie. |
| Binair codepunt (_BIN2) 1 | Hiermee worden gegevens in SQL Server-tabellen gesorteerd en vergeleken op basis van Unicode-codepunten voor Unicode-gegevens. Voor niet-Unicode-gegevens, gebruikt het binaire codepunt vergelijkingen die identiek zijn aan die voor binaire sorteringen. Het voordeel van het gebruik van een sorteervolgorde op basis van binair-codes is dat er in toepassingen die gesorteerde SQL Server-gegevens vergelijken, geen herordening van de gegevens nodig is. Als gevolg hiervan biedt een sorteervolgorde voor binaire codepunten eenvoudigere ontwikkeling van toepassingen en mogelijke prestatieverbeteringen. Zie de sectie Binaire sorteringen in dit artikel voor meer informatie. |
| UTF-8 (_UTF8) | Hiermee kunnen met UTF-8 gecodeerde gegevens worden opgeslagen in SQL Server. Als deze optie niet is geselecteerd, gebruikt SQL Server de standaardindeling voor niet-Unicode-codering voor de toepasselijke gegevenstypen. Zie de sectie UTF-8 Support in dit artikel voor meer informatie. |
1 Als binair of binair codepunt is geselecteerd, zijn de opties Hoofdlettergevoelig (_CS), Accentgevoelig (_AS), Kana-gevoelig (_KS) en Breedtegevoelig (_WS) niet beschikbaar.
Voorbeelden van sorteringsopties
Elke sorteervolgorde wordt gecombineerd als een reeks achtervoegsels om hoofdletter-, accent-, breedte- of kana-gevoeligheid te definiëren. In de volgende voorbeelden wordt het gedrag van sorteervolgorde beschreven voor verschillende combinaties van achtervoegsels.
| Windows-collatieachtervoegsel | Beschrijving van sorteervolgorde |
|---|---|
| _BIN 1 | Binaire sortering |
| _BIN2 1, 2 | Sorteervolgorde voor binaire codepunten |
| _CI_AI 2 | Hoofdletterongevoelig, accentongevoelig, kana-ongevoelig, breedte-ongevoelig |
| _CI_AI_KS 2 | Hoofdletterongevoelig, accentongevoelig, kana-gevoelig, breedte-ongevoelig |
| _CI_AI_KS_WS 2 | Hoofdletterongevoelig, accentongevoelig, kana-gevoelig, breedtegevoelig |
| _CI_AI_WS 2 | Hoofdletterongevoelig, accentongevoelig, kana-ongevoelig, breedtegevoelig |
| _CI_AS 2 | Hoofdletterongevoelig, accentgevoelig, kana-ongevoelig, breedte-ongevoelig |
| _CI_AS_KS 2 | Hoofdletterongevoelig, accentgevoelig, kana-gevoelig, breedte-ongevoelig |
| _CI_AS_KS_WS 2 | Niet-hoofdlettergevoelig, accentgevoelig, kanagevoelig, breedtegevoelig |
| _CI_AS_WS 2 | Hoofdletterongevoelig, accentgevoelig, kanaongevoelig, breedtegevoelig |
| _CS_AI 2 | Hoofdlettergevoelig, accentongevoelig, kana-ongevoelig, breedte-ongevoelig |
| _CS_AI_KS 2 | Hoofdlettergevoelig, accentongevoelig, kana-gevoelig, breedteongevoelig |
| _CS_AI_KS_WS 2 | Hoofdlettergevoelig, accentongevoelig, kanagevoelig, breedtegevoelig |
| _CS_AI_WS 2 | Hoofdlettergevoelig, accent-ongevoelig, kana-ongevoelig, breedtegevoelig |
| _CS_AS 2 | Hoofdlettergevoelig, accentgevoelig, kana-ongevoelig, breedte-ongevoelig |
| _CS_AS_KS 2 | Hoofdlettergevoelig, accentgevoelig, kanagevoelig, breedteonafhankelijk |
| _CS_AS_KS_WS 2 | Hoofdlettergevoelig, accentgevoelig, kana-gevoelig, breedtegevoelig |
| _CS_AS_WS 2 | Hoofdlettergevoelig, accentgevoelig, kana-ongevoelig, breedtegevoelig |
1 Als binair of binair codepunt is geselecteerd, zijn de opties Hoofdlettergevoelig (_CS), Accentgevoelig (_AS), Kana-gevoelig (_KS) en Breedtegevoelig (_WS) niet beschikbaar.
2 Door de optie UTF-8 (_UTF8) toe te voegen, kunt u Unicode-gegevens coderen met behulp van UTF-8. Zie de sectie UTF-8 Support in dit artikel voor meer informatie.
Collatie-instellingen
SQL Server ondersteunt de volgende sorteringssets:
Windows-sorteringen
Windows-sorteringen definiëren regels voor het opslaan van tekengegevens die zijn gebaseerd op een gekoppelde landinstelling van het Windows-systeem. Voor een Windows-sortering kunt u een vergelijking van niet-Unicode-gegevens implementeren met hetzelfde algoritme als voor Unicode-gegevens. De basisregels voor Windows-sortering geven aan welk alfabet of welke taal wordt gebruikt wanneer woordenlijstsortering wordt toegepast. De regels geven ook de codepagina op die wordt gebruikt voor het opslaan van niet-Unicode-tekengegevens. Zowel Unicode- als niet-Unicode-sortering zijn compatibel met tekenreeksvergelijkingen in een bepaalde versie van Windows. Dit biedt consistentie tussen gegevenstypen in SQL Server en hiermee kunnen ontwikkelaars tekenreeksen in hun toepassingen sorteren met behulp van dezelfde regels die worden gebruikt door SQL Server. Zie Windows-sorteringsnaamvoor meer informatie.
Binaire sorteringen
Binaire sorteringen sorteren gegevens op basis van de reeks gecodeerde waarden die zijn gedefinieerd door de landinstelling en het gegevenstype. Ze zijn hoofdlettergevoelig. Een binaire collatie in SQL Server definieert de landinstelling en de ANSI-codepagina die worden gebruikt. Hiermee wordt een binaire sorteervolgorde afgedwongen. Omdat ze relatief eenvoudig zijn, helpen binaire sorteringen de prestaties van toepassingen te verbeteren. Voor niet-Unicode-gegevenstypen zijn gegevensvergelijkingen gebaseerd op de codepunten die zijn gedefinieerd op de ANSI-codepagina. Voor Unicode-gegevenstypen zijn gegevensvergelijkingen gebaseerd op de Unicode-codepunten. Voor binaire sorteringen voor Unicode-gegevenstypen wordt de landinstelling niet meegenomen in gegevenssorteringen.
Latin1_General_BIN en Japanese_BIN bijvoorbeeld identieke sorteerresultaten opleveren wanneer ze worden gebruikt voor Unicode-gegevens. Zie Windows-sorteringsnaamvoor meer informatie.
Er zijn twee typen binaire sorteringen in SQL Server:
De verouderde
BINcollaties, die een onvolledige code-punt-op-code-punt vergelijking van Unicode-gegevens uitvoerde. Verouderde binaire sorteringen vergeleken het eerste teken als WCHAR, gevolgd door een byte-voor-bytevergelijking. In een BIN-sortering wordt alleen het eerste teken gesorteerd op basis van het codepunt en worden de resterende tekens gesorteerd op basis van de bytewaarden.De nieuwere
BIN2collaties, die een pure codepuntvergelijking uitvoeren. In een BIN2-sortering worden alle tekens gesorteerd op basis van hun codepunten. Omdat het Intel-platform een little-endian architectuur is, worden Unicode-codetekens altijd in omgekeerde bytevolgorde opgeslagen.
SQL Server-sorteringen
SQL Server-sorteringen (SQL_*) bieden sorteervolgordecompatibiliteit met eerdere versies van SQL Server. De sorteerregels voor woordenlijst voor niet-Unicode-gegevens zijn niet compatibel met een sorteerroutine die wordt geleverd door Windows-besturingssystemen. Het sorteren van Unicode-gegevens is echter compatibel met een bepaalde versie van Windows-sorteerregels. Omdat SQL Server-sorteringen verschillende vergelijkingsregels gebruiken voor niet-Unicode- en Unicode-gegevens, ziet u verschillende resultaten voor vergelijkingen van dezelfde gegevens, afhankelijk van het onderliggende gegevenstype.
Als u bijvoorbeeld de SQL-sortering SQL_Latin1_General_CP1_CI_ASgebruikt, is de niet-Unicode-tekenreeks 'a-c' kleiner dan de tekenreeks 'ab' omdat het afbreekstreepje (-) wordt gesorteerd als een afzonderlijk teken dat vóór bkomt. Als u deze tekenreeksen echter converteert naar Unicode en dezelfde vergelijking uitvoert, wordt de Unicode-tekenreeks N'a-c' als groter dan N'ab'beschouwd, omdat de Unicode-sorteerregels een woordsortering gebruiken waarmee het afbreekstreepje wordt genegeerd.
Zie SQL Server-sorteringsnaamvoor meer informatie.
Tijdens de installatie van SQL Server wordt de standaardinstelling voor installatiesortering bepaald door de landinstelling van het besturingssysteem . U kunt de sortering op serverniveau wijzigen tijdens de installatie of door de landinstelling van het besturingssysteem te wijzigen vóór de installatie. Om achterwaartse compatibiliteitsredenen wordt de standaardsortering ingesteld op de oudste beschikbare versie die is gekoppeld aan elke specifieke landinstelling. Daarom is dit niet altijd de aanbevolen sortering. Als u optimaal gebruik wilt maken van SQL Server-functies, wijzigt u de standaardinstallatie-instellingen voor het gebruik van Windows-sorteringen. Voor de landinstelling van het besturingssysteem 'Engels (Verenigde Staten)' (codepagina 1252) is de standaardsortering tijdens de installatie SQL_Latin1_General_CP1_CI_ASen kan deze worden gewijzigd in de dichtstbijzijnde Windows-sorteervariant, Latin1_General_100_CI_AS_SC.
Wanneer u een Engels exemplaar van SQL Server upgradet, kunt u SQL Server-collaties (SQL_*) opgeven voor compatibiliteit met bestaande exemplaren van SQL Server. Omdat de standaardsortering voor een exemplaar van SQL Server tijdens de installatie is gedefinieerd, moet u ervoor zorgen dat u de sorteringsinstellingen zorgvuldig opgeeft wanneer aan de volgende voorwaarden wordt voldaan:
- Uw toepassingscode is afhankelijk van het gedrag van eerdere SQL Server-sorteringen.
- U moet tekengegevens opslaan die meerdere talen weerspiegelen.
Sorteringsniveaus
Het instellen van sorteringen wordt ondersteund op de volgende niveaus van een exemplaar van SQL Server:
- sorteringen op serverniveau
- sorteringen op databaseniveau
- sorteringen op kolomniveau
- sorteringen op expressieniveau
Sorteringen op serverniveau
De standaardsortering van de server wordt bepaald tijdens het instellen van SQL Server en wordt de standaardsortering van de systeemdatabases en alle gebruikersdatabases.
In de volgende tabel ziet u de standaardsorteringsaanduidingen, zoals wordt bepaald door de landinstelling van het besturingssysteem (OS), met inbegrip van hun Windows- en SQL Language Code Identifiers (LCID):
| Windows-landinstellingen | Windows LCID | SQL LCID | Standaardsortering |
|---|---|---|---|
| Afrikaans (Zuid-Afrika) | 0x0436 | 0x0409 | Latin1_General_CI_AS |
| Albanese (Albanië) | 0x041c | 0x041c | Albanian_CI_AS |
| Alsatian (Frankrijk) | 0x0484 | 0x0409 | Latin1_General_CI_AS |
| Amharisch (Ethiopië) | 0x045e | 0x0409 | Latin1_General_CI_AS |
| Arabisch (Algerije) | 0x1401 | 0x0401 | Arabic_CI_AS |
| Arabisch (Bahrein) | 0x3c01 | 0x0401 | Arabic_CI_AS |
| Arabisch (Egypte) | 0x0c01 | 0x0401 | Arabic_CI_AS |
| Arabisch (Irak) | 0x0801 | 0x0401 | Arabic_CI_AS |
| Arabisch (Jordanië) | 0x2c01 | 0x0401 | Arabic_CI_AS |
| Arabisch (Koeweit) | 0x3401 | 0x0401 | Arabic_CI_AS |
| Arabisch (Libanon) | 0x3001 | 0x0401 | Arabic_CI_AS |
| Arabisch (Libië) | 0x1001 | 0x0401 | Arabic_CI_AS |
| Arabisch (Marokko) | 0x1801 | 0x0401 | Arabic_CI_AS |
| Arabisch (Oman) | 0x2001 | 0x0401 | Arabic_CI_AS |
| Arabisch (Qatar) | 0x4001 | 0x0401 | Arabic_CI_AS |
| Arabisch (Saoedi-Arabië) | 0x0401 | 0x0401 | Arabic_CI_AS |
| Arabisch (Syrië) | 0x2801 | 0x0401 | Arabic_CI_AS |
| Arabisch (Tunesië) | 0x1c01 | 0x0401 | Arabic_CI_AS |
| Arabisch (U.A.E.) | 0x3801 | 0x0401 | Arabic_CI_AS |
| Arabisch (Jemen) | 0x2401 | 0x0401 | Arabic_CI_AS |
| Armeens (Armenië) | 0x042b | 0x0419 | Latin1_General_CI_AS |
| Assamese (India) | 0x044d | 0x044d | Niet beschikbaar op serverniveau |
| Azerbeidzjaans (Azerbeidzjaans, Cyrillisch) | 0x082c | 0x082c | Afgeschaft, niet beschikbaar op serverniveau |
| Azerbeidzjaans (Azerbeidzjaans, Latijns) | 0x042c | 0x042c | Afgeschaft, niet beschikbaar op serverniveau |
| Bashkir (Rusland) | 0x046d | 0x046d | Latin1_General_CI_AI |
| Baskisch (Baskisch) | 0x042d | 0x0409 | Latin1_General_CI_AS |
| Belarussisch (Wit-Rusland) | 0x0423 | 0x0419 | Cyrillic_General_CI_AS |
| Bangla (Bangladesh) | 0x0845 | 0x0445 | Niet beschikbaar op serverniveau |
| Bengaals (India) | 0x0445 | 0x0439 | Niet beschikbaar op serverniveau |
| Bosnisch (Bosnië en Herzegovina, Cyrillisch) | 0x201a | 0x201a | Latin1_General_CI_AI |
| Bosnisch (Bosnië en Herzegovina, Latijns) | 0x141a | 0x141a | Latin1_General_CI_AI |
| Bretagne (Frankrijk) | 0x047e | 0x047e | Latin1_General_CI_AI |
| Bulgaars (Bulgarije) | 0x0402 | 0x0419 | Cyrillic_General_CI_AS |
| Catalaans (Catalaans) | 0x0403 | 0x0409 | Latin1_General_CI_AS |
| Chinees (Hongkong SAR, Volksrepubliek China) | 0x0c04 | 0x0404 | Chinese_Taiwan_Stroke_CI_AS |
| Chinees (Macao SAR) | 0x1404 | 0x1404 | Latin1_General_CI_AI |
| Chinees (Macao SAR) | 0x21404 | 0x21404 | Latin1_General_CI_AI |
| Chinees (Volksrepubliek China) | 0x0804 | 0x0804 | Chinese_PRC_CI_AS |
| Chinees (Volksrepubliek China) | 0x20804 | 0x20804 | Chinese_PRC_Stroke_CI_AS |
| Chinees (Singapore) | 0x1004 | 0x0804 | Chinese_PRC_CI_AS |
| Chinees (Singapore) | 0x21004 | 0x20804 | Chinese_PRC_Stroke_CI_AS |
| Chinees (Taiwan) | 0x30404 | 0x30404 | Chinese_Taiwan_Bopomofo_CI_AS |
| Chinees (Taiwan) | 0x0404 | 0x0404 | Chinese_Taiwan_Stroke_CI_AS |
| Corsicaans (Frankrijk) | 0x0483 | 0x0483 | Latin1_General_CI_AI |
| Kroatisch (Bosnië en Herzegovina, Latijns) | 0x101a | 0x041a | Croatian_CI_AS |
| Kroatisch (Kroatië) | 0x041a | 0x041a | Croatian_CI_AS |
| Tsjechisch (Tsjechische Republiek) | 0x0405 | 0x0405 | Czech_CI_AS |
| Deens (Denemarken) | 0x0406 | 0x0406 | Danish_Norwegian_CI_AS |
| Dari (Afghanistan) | 0x048c | 0x048c | Latin1_General_CI_AI |
| Divehi (Malediven) | 0x0465 | 0x0465 | Niet beschikbaar op serverniveau |
| Nederlands (België) | 0x0813 | 0x0409 | Latin1_General_CI_AS |
| Nederlands (Nederland) | 0x0413 | 0x0409 | Latin1_General_CI_AS |
| Engels (Australië) | 0x0c09 | 0x0409 | Latin1_General_CI_AS |
| Engels (Belize) | 0x2809 | 0x0409 | Latin1_General_CI_AS |
| Engels (Canada) | 0x1009 | 0x0409 | Latin1_General_CI_AS |
| Engels (Caribisch gebied) | 0x2409 | 0x0409 | Latin1_General_CI_AS |
| Engels (India) | 0x4009 | 0x0409 | Latin1_General_CI_AS |
| Engels (Ierland) | 0x1809 | 0x0409 | Latin1_General_CI_AS |
| Engels (Jamaica) | 0x2009 | 0x0409 | Latin1_General_CI_AS |
| Engels (Maleisië) | 0x4409 | 0x0409 | Latin1_General_CI_AS |
| Engels (Nieuw-Zeeland) | 0x1409 | 0x0409 | Latin1_General_CI_AS |
| Engels (Filipijnen) | 0x3409 | 0x0409 | Latin1_General_CI_AS |
| Engels (Singapore) | 0x4809 | 0x0409 | Latin1_General_CI_AS |
| Engels (Zuid-Afrika) | 0x1c09 | 0x0409 | Latin1_General_CI_AS |
| Engels (Trinidad en Tobago) | 0x2c09 | 0x0409 | Latin1_General_CI_AS |
| Engels (Verenigd Koninkrijk) | 0x0809 | 0x0409 | Latin1_General_CI_AS |
| Engels (Verenigde Staten) | 0x0409 | 0x0409 | SQL_Latin1_General_CP1_CI_AS |
| Engels (Zimbabwe) | 0x3009 | 0x0409 | Latin1_General_CI_AS |
| Estisch (Estland) | 0x0425 | 0x0425 | Estonian_CI_AS |
| Faerøers (Faeröer eilanden) | 0x0438 | 0x0409 | Latin1_General_CI_AS |
| Filipijns (Filipijnen) | 0x0464 | 0x0409 | Latin1_General_CI_AS |
| Fins (Finland) | 0x040b | 0x040b | Finnish_Swedish_CI_AS |
| Frans (België) | 0x080c | 0x040c | French_CI_AS |
| Frans (Canada) | 0x0c0c | 0x040c | French_CI_AS |
| Frans (Frankrijk) | 0x040c | 0x040c | French_CI_AS |
| Frans (Luxemburg) | 0x140c | 0x040c | French_CI_AS |
| Frans (Monaco) | 0x180c | 0x040c | French_CI_AS |
| Frans (Zwitserland) | 0x100c | 0x040c | French_CI_AS |
| Fries (Nederland) | 0x0462 | 0x0462 | Latin1_General_CI_AI |
| Galicisch | 0x0456 | 0x0409 | Latin1_General_CI_AS |
| Georgisch (Georgië) | 0x10437 | 0x10437 | Georgian_Modern_Sort_CI_AS |
| Georgisch (Georgië) | 0x0437 | 0x0419 | Latin1_General_CI_AS |
| Duits - Telefoonboekvolgorde (DIN) | 0x10407 | 0x10407 | German_PhoneBook_CI_AS |
| Duits (Oostenrijk) | 0x0c07 | 0x0409 | Latin1_General_CI_AS |
| Duits (Duitsland) | 0x0407 | 0x0409 | Latin1_General_CI_AS |
| Duits (Liechtenstein) | 0x1407 | 0x0409 | Latin1_General_CI_AS |
| Duits (Luxemburg) | 0x1007 | 0x0409 | Latin1_General_CI_AS |
| Duits (Zwitserland) | 0x0807 | 0x0409 | Latin1_General_CI_AS |
| Grieks (Griekenland) | 0x0408 | 0x0408 | Greek_CI_AS |
| Groenlands (Groenland) | 0x046f | 0x0406 | Danish_Norwegian_CI_AS |
| Gujarati (India) | 0x0447 | 0x0439 | Niet beschikbaar op serverniveau |
| Hausa (Nigeria, Latijns) | 0x0468 | 0x0409 | Latin1_General_CI_AS |
| Hebreeuws (Israël) | 0x040d | 0x040d | Hebrew_CI_AS |
| Hindi (India) | 0x0439 | 0x0439 | Niet beschikbaar op serverniveau |
| Hongaars (Hongarije) | 0x040e | 0x040e | Hungarian_CI_AS |
| Hongaarse technische categorisering | 0x1040e | 0x1040e | Hungarian_Technical_CI_AS |
| IJslands (IJsland) | 0x040f | 0x040f | Icelandic_CI_AS |
| Igbo (Nigeria) | 0x0470 | 0x0409 | Latin1_General_CI_AS |
| Indonesisch (Indonesië) | 0x0421 | 0x0409 | Latin1_General_CI_AS |
| Inuktitut (Canada, Latijn) | 0x085d | 0x0409 | Latin1_General_CI_AS |
| Inuktitut (Syllabics) Canada | 0x045d | 0x045d | Latin1_General_CI_AI |
| Iers (Ierland) | 0x083c | 0x0409 | Latin1_General_CI_AS |
| Italiaans (Italië) | 0x0410 | 0x0409 | Latin1_General_CI_AS |
| Italiaans (Zwitserland) | 0x0810 | 0x0409 | Latin1_General_CI_AS |
| Japans (Japan XJIS) | 0x0411 | 0x0411 | Japanese_CI_AS |
| Japans (Japan) | 0x040411 | 0x40411 | Latin1_General_CI_AI |
| Kannada (India) | 0x044b | 0x0439 | Niet beschikbaar op serverniveau |
| Kazachs (Kazachstan) | 0x043f | 0x043f | Kazakh_90_CI_AS |
| Khmer (Cambodja) | 0x0453 | 0x0453 | Niet beschikbaar op serverniveau |
| K'iche (Guatemala) | 0x0486 | 0x0c0a | Modern_Spanish_CI_AS |
| Kinyarwanda (Rwanda) | 0x0487 | 0x0409 | Latin1_General_CI_AS |
| Konkani (India) | 0x0457 | 0x0439 | Niet beschikbaar op serverniveau |
| Koreaans (Korea Woordenboekvolgorde) | 0x0412 | 0x0412 | Korean_Wansung_CI_AS |
| Kirgizisch (Kirgistan) | 0x0440 | 0x0419 | Cyrillic_General_CI_AS |
| Lao (Lao PDR) | 0x0454 | 0x0454 | Niet beschikbaar op serverniveau |
| Lets (Letland) | 0x0426 | 0x0426 | Latvian_CI_AS |
| Litouws (Litouwen) | 0x0427 | 0x0427 | Lithuanian_CI_AS |
| Lower Sorbian (Duitsland) | 0x082e | 0x0409 | Latin1_General_CI_AS |
| Luxemburgs (Luxemburg) | 0x046e | 0x0409 | Latin1_General_CI_AS |
| Macedonisch (Noord-Macedonië) | 0x042f | 0x042f | Macedonian_FYROM_90_CI_AS |
| Maleis (Brunei Darussalam) | 0x083e | 0x0409 | Latin1_General_CI_AS |
| Maleis (Maleisië) | 0x043e | 0x0409 | Latin1_General_CI_AS |
| Malayalam (India) | 0x044c | 0x0439 | Niet beschikbaar op serverniveau |
| Maltees (Malta) | 0x043a | 0x043a | Latin1_General_CI_AI |
| Maori (Nieuw-Zeeland) | 0x0481 | 0x0481 | Latin1_General_CI_AI |
| Mapudungun (Chili) | 0x047a | 0x047a | Latin1_General_CI_AI |
| Marathi (India) | 0x044e | 0x0439 | Niet beschikbaar op serverniveau |
| Mohawk (Canada) | 0x047c | 0x047c | Latin1_General_CI_AI |
| Mongools (Mongolië) | 0x0450 | 0x0419 | Cyrillic_General_CI_AS |
| Mongools (Volksrepubliek China) | 0x0850 | 0x0419 | Cyrillic_General_CI_AS |
| Nepalee (Nepalee) | 0x0461 | 0x0461 | Niet beschikbaar op serverniveau |
| Noors (Bokmål, Noorwegen) | 0x0414 | 0x0414 | Latin1_General_CI_AI |
| Noors (Nynorsk, Noorwegen) | 0x0814 | 0x0414 | Latin1_General_CI_AI |
| Occitaan (Frankrijk) | 0x0482 | 0x040c | French_CI_AS |
| Odia (India) | 0x0448 | 0x0439 | Niet beschikbaar op serverniveau |
| Pashto (Afghanistan) | 0x0463 | 0x0463 | Niet beschikbaar op serverniveau |
| Perzisch (Iran) | 0x0429 | 0x0429 | Latin1_General_CI_AI |
| Pools (Polen) | 0x0415 | 0x0415 | Polish_CI_AS |
| Portugees (Brazilië) | 0x0416 | 0x0409 | Latin1_General_CI_AS |
| Portugees (Portugal) | 0x0816 | 0x0409 | Latin1_General_CI_AS |
| Punjabi (India) | 0x0446 | 0x0439 | Niet beschikbaar op serverniveau |
| Quechua (Bolivia) | 0x046b | 0x0409 | Latin1_General_CI_AS |
| Quechua (Ecuador) | 0x086b | 0x0409 | Latin1_General_CI_AS |
| Quechua (Peru) | 0x0c6b | 0x0409 | Latin1_General_CI_AS |
| Roemeens (Roemenië) | 0x0418 | 0x0418 | Romanian_CI_AS |
| Romeinen (Zwitserland) | 0x0417 | 0x0417 | Latin1_General_CI_AI |
| Russisch (Rusland) | 0x0419 | 0x0419 | Cyrillic_General_CI_AS |
| Sahka (Rusland) | 0x0485 | 0x0485 | Latin1_General_CI_AI |
| Sami (Inari, Finland) | 0x243b | 0x083b | Latin1_General_CI_AI |
| Sami (Lule, Noorwegen) | 0x103b | 0x043b | Latin1_General_CI_AI |
| Sami (Lule, Zweden) | 0x143b | 0x083b | Latin1_General_CI_AI |
| Sami (Noord, Finland) | 0x0c3b | 0x083b | Latin1_General_CI_AI |
| Sami (Noord, Noorwegen) | 0x043b | 0x043b | Latin1_General_CI_AI |
| Sami (Noord, Zweden) | 0x083b | 0x083b | Latin1_General_CI_AI |
| Sami (Skolt, Finland) | 0x203b | 0x083b | Latin1_General_CI_AI |
| Sami (Zuid, Noorwegen) | 0x183b | 0x043b | Latin1_General_CI_AI |
| Sami (Zuid, Zweden) | 0x1c3b | 0x083b | Latin1_General_CI_AI |
| Sanskrit (India) | 0x044f | 0x0439 | Niet beschikbaar op serverniveau |
| Servisch (Bosnië en Herzegovina, Cyrillisch) | 0x1c1a | 0x0c1a | Latin1_General_CI_AI |
| Servisch (Bosnië en Herzegovina, Latijns) | 0x181a | 0x081a | Latin1_General_CI_AI |
| Servisch (Servië, Cyrillisch) | 0x0c1a | 0x0c1a | Latin1_General_CI_AI |
| Servisch (Servië, Latijns) | 0x081a | 0x081a | Latin1_General_CI_AI |
| Sesotho sa Leboa/Noord-Sotho (Zuid-Afrika) | 0x046c | 0x0409 | Latin1_General_CI_AS |
| Setswana/Tswana (Zuid-Afrika) | 0x0432 | 0x0409 | Latin1_General_CI_AS |
| Sinhala (Sri Lanka) | 0x045b | 0x0439 | Niet beschikbaar op serverniveau |
| Slowaaks (Slowakije) | 0x041b | 0x041b | Slovak_CI_AS |
| Sloveens (Slovenië) | 0x0424 | 0x0424 | Slovenian_CI_AS |
| Spaans (Argentinië) | 0x2c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spaans (Bolivia) | 0x400a | 0x0c0a | Modern_Spanish_CI_AS |
| Spaans (Chili) | 0x340a | 0x0c0a | Modern_Spanish_CI_AS |
| Spaans (Colombia) | 0x240a | 0x0c0a | Modern_Spanish_CI_AS |
| Spaans (Costa Rica) | 0x140a | 0x0c0a | Modern_Spanish_CI_AS |
| Spaans (Dominicaanse Republiek) | 0x1c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spaans (Ecuador) | 0x300a | 0x0c0a | Modern_Spanish_CI_AS |
| Spaans (El Salvador) | 0x440a | 0x0c0a | Modern_Spanish_CI_AS |
| Spaans (Guatemala) | 0x100a | 0x0c0a | Modern_Spanish_CI_AS |
| Spaans (Honduras) | 0x480a | 0x0c0a | Modern_Spanish_CI_AS |
| Spaans (Mexico) | 0x080a | 0x0c0a | Modern_Spanish_CI_AS |
| Spaans (Nicaragua) | 0x4c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spaans (Panama) | 0x180a | 0x0c0a | Modern_Spanish_CI_AS |
| Spaans (Paraguay) | 0x3c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spaans (Peru) | 0x280a | 0x0c0a | Modern_Spanish_CI_AS |
| Spaans (Puerto Rico) | 0x500a | 0x0c0a | Modern_Spanish_CI_AS |
| Spaans (Spanje) | 0x0c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spaans (Spanje, traditionele sortering) | 0x040a | 0x040a | Traditional_Spanish_CI_AS |
| Spaans (Verenigde Staten) | 0x540a | 0x0409 | Latin1_General_CI_AS |
| Spaans (Uruguay) | 0x380a | 0x0c0a | Modern_Spanish_CI_AS |
| Spaans (Venezuela) | 0x200a | 0x0c0a | Modern_Spanish_CI_AS |
| Swahili (Kenia) | 0x0441 | 0x0409 | Latin1_General_CI_AS |
| Zweeds (Finland) | 0x081d | 0x040b | Finnish_Swedish_CI_AS |
| Zweeds (Zweden) | 0x041d | 0x040b | Finnish_Swedish_CI_AS |
| Syriër (Syrië) | 0x045a | 0x045a | Niet beschikbaar op serverniveau |
| Tadzjiik (Tadzjikistan) | 0x0428 | 0x0419 | Cyrillic_General_CI_AS |
| Tamazight (Algerije, Latijns) | 0x085f | 0x085f | Latin1_General_CI_AI |
| Tamil (India) | 0x0449 | 0x0439 | Niet beschikbaar op serverniveau |
| Tatar (Rusland) | 0x0444 | 0x0444 | Cyrillic_General_CI_AS |
| Telugu (India) | 0x044a | 0x0439 | Niet beschikbaar op serverniveau |
| Thai (Thailand) | 0x041e | 0x041e | Thai_CI_AS |
| Tibetaans (Volksrepubliek China) | 0x0451 | 0x0451 | Niet beschikbaar op serverniveau |
| Turks (Türkiye) | 0x041f | 0x041f | Turkish_CI_AS |
| Turkmen (Turkmenistan) | 0x0442 | 0x0442 | Latin1_General_CI_AI |
| Uighur (Volksrepubliek China) | 0x0480 | 0x0480 | Latin1_General_CI_AI |
| Oekraïens (Oekraïne) | 0x0422 | 0x0422 | Ukrainian_CI_AS |
| Upper Sorbian (Duitsland) | 0x042e | 0x042e | Latin1_General_CI_AI |
| Urdu (Pakistan) | 0x0420 | 0x0420 | Latin1_General_CI_AI |
| Oezbeeks (Oezbekistan, Cyrillisch) | 0x0843 | 0x0419 | Cyrillic_General_CI_AS |
| Oezbeeks (Oezbekistan, Latijns) | 0x0443 | 0x0443 | Uzbek_Latin_90_CI_AS |
| Vietnamees (Vietnam) | 0x042a | 0x042a | Vietnamese_CI_AS |
| Welsh (Verenigd Koninkrijk) | 0x0452 | 0x0452 | Latin1_General_CI_AI |
| Wolof (Senegal) | 0x0488 | 0x040c | French_CI_AS |
| Xhosa/isiXhosa (Zuid-Afrika) | 0x0434 | 0x0409 | Latin1_General_CI_AS |
| Yi (Volksrepubliek China) | 0x0478 | 0x0409 | Latin1_General_CI_AS |
| Yoruba (Nigeria) | 0x046a | 0x0409 | Latin1_General_CI_AS |
| Zulu/isiZulu (Zuid-Afrika) | 0x0435 | 0x0409 | Latin1_General_CI_AS |
Nadat u een sortering aan de server hebt toegewezen, kunt u deze alleen wijzigen door alle databaseobjecten en -gegevens te exporteren, de master-database opnieuw te bouwen en alle databaseobjecten en -gegevens te importeren. In plaats van de standaardsortering van een exemplaar van SQL Server te wijzigen, kunt u de gewenste sortering opgeven wanneer u een nieuwe database of databasekolom maakt.
Als u een query wilt uitvoeren op de serversortering voor een exemplaar van SQL Server, gebruikt u de functie SERVERPROPERTY:
SELECT CONVERT (NVARCHAR (128), SERVERPROPERTY('collation'));
Als u een query wilt uitvoeren op de server voor alle beschikbare sorteringen, gebruikt u de volgende fn_helpcollations() ingebouwde functie:
SELECT *
FROM sys.fn_helpcollations();
Sorteringen in Azure SQL Database
U kunt de sortering van logische servers in Azure SQL Database niet wijzigen of instellen, maar u kunt de sorteringen van elke database configureren voor zowel gegevens als voor de catalogus. De catalogussortering bepaalt de sortering voor systeemmetagegevens, zoals object-id's. Beide sorteringen kunnen onafhankelijk worden opgegeven wanneer u de database maken in Azure Portal, in T-SQL met CREATE DATABASE, in PowerShell met New-AzSqlDatabase.
Collation-instellingen in Azure SQL Managed Instance
Sortering op serverniveau in Azure SQL Managed Instance kan worden opgegeven wanneer de instantie wordt aangemaakt en kan later niet meer worden aangepast.
Zie De serversortering instellen of wijzigenvoor meer informatie.
Sorteringen op databaseniveau
Wanneer u een database maakt of wijzigt, kunt u de COLLATE component van de CREATE DATABASE of ALTER DATABASE instructie gebruiken om de standaarddatabasesortering op te geven. Als er geen sortering is opgegeven, wordt aan de database de serversortering toegewezen.
U kunt de sortering van systeemdatabases alleen wijzigen als u de sortering voor de server wijzigt.
- In SQL Server en Azure SQL Managed Instance wordt de databasesortering gebruikt voor alle metagegevens in de database en is de sortering de standaardinstelling voor alle tekenreekskolommen, tijdelijke objecten, variabele namen en andere tekenreeksen die in de database worden gebruikt.
- In Azure SQL Database is er geen serversortering, dus elke database heeft een sortering voor gegevens en een sortering voor de catalogus. De CATALOG_COLLATION wordt gebruikt voor alle metagegevens in de database en de sortering is de standaardinstelling voor alle tekenreekskolommen, tijdelijke objecten, variabelenamen en andere tekenreeksen die in de database worden gebruikt. De CATALOG_COLLATION is ingesteld bij het maken en kan niet worden gewijzigd.
Wanneer u de sortering van een gebruikersdatabase wijzigt, kunnen er sorteringsconflicten optreden wanneer query's in de database tijdelijke tabellen openen. Tijdelijke tabellen worden altijd opgeslagen in de tempdb systeemdatabase, die gebruikmaakt van de collatie voor de serverinstantie. Query's waarmee tekengegevens tussen de gebruikersdatabase en tempdb worden vergeleken, kunnen mislukken als de sorteringen een conflict veroorzaken bij het evalueren van de tekengegevens. U kunt dit probleem oplossen door de COLLATE component in de query op te geven. Zie COLLATEvoor meer informatie.
U kunt de sortering van een gebruikersdatabase wijzigen met behulp van een ALTER DATABASE instructie die vergelijkbaar is met het volgende codevoorbeeld:
ALTER DATABASE myDB COLLATE Greek_CS_AI;
Belangrijk
Het wijzigen van de sortering op databaseniveau heeft geen invloed op sorteringen op kolom- of expressieniveau. Dit heeft geen invloed op gegevens in bestaande kolommen.
U kunt de huidige sortering van een database ophalen met behulp van een instructie die vergelijkbaar is met het volgende codevoorbeeld:
SELECT CONVERT (NVARCHAR (128), DATABASEPROPERTYEX('database_name', 'collation'));
Sorteringen op kolomniveau
Wanneer u een tabel maakt of wijzigt, kunt u sorteringen opgeven voor elke kolom met tekenreeksen met behulp van de COLLATE-component. Als u geen sortering opgeeft, wordt aan de kolom de standaardsortering van de database toegewezen.
U kunt de sortering van een kolom wijzigen met behulp van een ALTER TABLE instructie die vergelijkbaar is met het volgende codevoorbeeld:
ALTER TABLE myTable ALTER COLUMN mycol NVARCHAR (10) COLLATE Greek_CS_AI;
Sorteringen op expressieniveau
Sorteringen op expressieniveau worden ingesteld wanneer een instructie wordt uitgevoerd en hebben invloed op de manier waarop een resultatenset wordt geretourneerd. Hierdoor kunnen ORDER BY sorteerresultaten lokaal specifiek zijn. Als u sorteringen op expressieniveau wilt implementeren, gebruikt u een COLLATE-component, zoals het volgende codevoorbeeld:
SELECT name
FROM customer
ORDER BY name COLLATE Latin1_General_CS_AI;
Oord
Een locale is een geheel aan informatie dat is gekoppeld aan een locatie of cultuur. De informatie kan bestaan uit de naam en id van de gesproken taal, het script dat wordt gebruikt voor het schrijven van de taal en culturele conventies. Collaties kunnen worden gekoppeld aan een of meer locaties. Voor meer informatie, zie Landinstellingen-id's die door Microsoftzijn toegewezen.
Codepagina
Een codepagina is een geordende set tekens van een bepaald script waarin een numerieke index of codepuntwaarde aan elk teken is gekoppeld. Een Windows-codepagina wordt meestal een tekenset of een tekensetgenoemd. Codepagina's worden gebruikt om ondersteuning te bieden voor de tekensets en toetsenbordindelingen die worden gebruikt door verschillende landinstellingen van het Windows-systeem.
Sorteervolgorde
Sorteervolgorde geeft aan hoe gegevenswaarden worden gesorteerd. De volgorde is van invloed op de resultaten van gegevensvergelijking. Gegevens worden gesorteerd met behulp van sorteringen en kunnen worden geoptimaliseerd met behulp van indexen.
Unicode-ondersteuning
Unicode is een standaard voor het toewijzen van codepunten aan tekens. Omdat het is ontworpen om alle tekens van alle talen van de wereld te behandelen, hebt u geen verschillende codepagina's nodig om verschillende sets tekens af te handelen.
Basisbeginselen van Unicode
Het opslaan van gegevens in meerdere talen in één database is moeilijk te beheren wanneer u alleen tekengegevens en codepagina's gebruikt. Het is ook moeilijk om één codepagina te vinden voor de database die alle vereiste taalspecifieke tekens kan opslaan. Daarnaast is het moeilijk om de juiste vertaling van speciale tekens te garanderen wanneer ze worden gelezen of bijgewerkt door verschillende clients waarop verschillende codepagina's worden uitgevoerd. Databases die internationale clients ondersteunen, moeten altijd Unicode-gegevenstypen gebruiken in plaats van niet-Unicode-gegevenstypen.
Denk bijvoorbeeld aan een database met klanten in Noord-Amerika die drie belangrijke talen moeten verwerken:
- Spaanse namen en adressen voor Mexico
- Franse namen en adressen voor Quebec
- Engelse namen en adressen voor de rest van Canada en de Verenigde Staten
Wanneer u alleen tekenkolommen en codepagina's gebruikt, moet u ervoor zorgen dat de database wordt geïnstalleerd met een codepagina die de tekens van alle drie de talen verwerkt. U moet er ook voor zorgen dat de juiste vertaling van tekens uit een van de talen wordt gegarandeerd wanneer de tekens worden gelezen door clients waarop een codepagina voor een andere taal wordt uitgevoerd.
Notitie
De codepagina's die een client gebruikt, worden bepaald door de besturingssysteeminstellingen. Als u clientcodepagina's op het Windows-besturingssysteem wilt instellen, gebruikt u Landinstellingen in het Configuratiescherm.
Het is lastig om een codepagina te selecteren voor tekengegevenstypen die alle tekens ondersteunen die vereist zijn voor een wereldwijd publiek. De eenvoudigste manier om tekengegevens in internationale databases te beheren, is door altijd een gegevenstype te gebruiken dat Unicode ondersteunt.
Unicode-gegevenstypen
Als u tekengegevens opslaat die meerdere talen weerspiegelen in SQL Server (SQL Server 2005 (9.x) en hoger), gebruikt u Unicode-gegevenstypen (nchar, nvarcharntext) in plaats van niet-Unicode-gegevenstypen (teken, varchar-en tekst).
Notitie
Voor Unicode-gegevens typen kan de Database-engine maximaal 65.536 tekens weergeven met behulp van UCS-2, of het volledige Unicode-bereik (1.114.112 tekens) als aanvullende tekens worden gebruikt. Zie Aanvullende tekensvoor meer informatie over het inschakelen van aanvullende tekens.
U kunt ook beginnen met SQL Server 2019 (15.x), als een UTF-8-sortering (_UTF8) wordt gebruikt, worden voorheen niet-Unicode-gegevenstypen (teken en varchar) Unicode-gegevenstypen met behulp van UTF-8-codering. SQL Server 2019 (15.x) wijzigt het gedrag van eerder bestaande Unicode-gegevenstypen (nchar, nvarcharen ntext), die UCS-2- of UTF-16-codering blijven gebruiken. Zie Storage-verschillen tussen UTF-8 en UTF-16voor meer informatie.
Unicode-overwegingen
Belangrijke beperkingen zijn gekoppeld aan niet-Unicode-gegevenstypen. Dit komt doordat een niet-Unicode-computer is beperkt tot het gebruik van één codepagina. U kunt prestatieverbeteringen ervaren door Unicode te gebruiken, omdat hiervoor minder codepaginaconversies nodig zijn. Unicode-sorteringen moeten afzonderlijk worden geselecteerd op database-, kolom- of expressieniveau, omdat ze niet worden ondersteund op serverniveau.
Wanneer u gegevens van een server naar een client verplaatst, wordt uw serversortering mogelijk niet herkend door oudere clientstuurprogramma's. Dit kan gebeuren wanneer u gegevens van een Unicode-server naar een niet-Unicode-client verplaatst. Het is mogelijk de beste optie om het clientbesturingssysteem te upgraden, zodat de onderliggende systeemsorteringen worden bijgewerkt. Als de client databaseclientsoftware heeft geïnstalleerd, kunt u overwegen om een service-update toe te passen op de databaseclientsoftware.
Tip
U kunt ook een andere sortering gebruiken voor de gegevens op de server. Kies een sortering die overeenkomt met een codepagina op de client. Als u de UTF-16-sorteringen wilt gebruiken die beschikbaar zijn in SQL Server (SQL Server 2012 (11.x) en hoger) om het zoeken en sorteren van bepaalde Unicode-tekens (alleen Windows-sorteringen) te verbeteren, kunt u een van de aanvullende tekens (_SC) of een van de sorteringen van versie 140 selecteren.
Als u de UTF-8-sorteringen wilt gebruiken die beschikbaar zijn in SQL Server 2019 (15.x) en om het zoeken en sorteren van bepaalde Unicode-tekens (alleen Windows-sorteringen) te verbeteren, moet u UTF-8-sorteringen (_UTF8) selecteren.
De UTF8-vlag kan worden toegepast op:
- Taalkundige sorteringen die al ondersteuning bieden voor aanvullende tekens (_SC) of gevoeligheid voor variatieselectoren (_VSS)
- BIN2 binaire collatie
De UTF8-vlag kan niet worden toegepast op:
- Taalkundige sorteringen die geen ondersteuning bieden voor aanvullende tekens (_SC) of variatieselectorgevoelige (_VSS) bewustzijn
- De BIN-binaire sorteringen
- De SQL_* sorteringen
Als u problemen wilt evalueren die betrekking hebben op het gebruik van Unicode- of niet-Unicode-gegevenstypen, test u uw scenario om prestatieverschillen in uw omgeving te meten. Het is een goede gewoonte om de sortering die wordt gebruikt op systemen in uw organisatie te standaardiseren en waar mogelijk Unicode-servers en -clients te implementeren.
In veel situaties communiceert SQL Server met andere servers of clients en uw organisatie kan meerdere standaarden voor gegevenstoegang tussen toepassingen en serverinstanties gebruiken. SQL Server-clients zijn een van de twee hoofdtypen:
- Unicode-clients die gebruikmaken van OLE DB en ODBC-versie (Open Database Connectivity) versie 3.7 of hoger.
- niet-Unicode-clients die gebruikmaken van DB-Library en ODBC versie 3.6 of eerder.
De volgende tabel bevat informatie over het gebruik van meertalige gegevens met verschillende combinaties van Unicode- en niet-Unicode-servers:
| Server | Cliënt | Voordelen of beperkingen |
|---|---|---|
| Unicode | Unicode | Omdat Unicode-gegevens in het hele systeem worden gebruikt, biedt dit scenario de beste prestaties en bescherming tegen beschadiging van opgehaalde gegevens. Dit is de situatie met ActiveX Data Objects (ADO), OLE DB en ODBC versie 3.7 of hoger. |
| Unicode | Niet-Unicode | In dit scenario, met name met verbindingen tussen een server waarop een nieuwer besturingssysteem wordt uitgevoerd en een client met een eerdere versie van SQL Server, of op een ouder besturingssysteem, kunnen er beperkingen of fouten optreden wanneer u gegevens naar een clientcomputer verplaatst. Unicode-gegevens op de server proberen toe te wijzen aan een bijbehorende codepagina op de niet-Unicode-client om de gegevens te converteren. |
| Niet-Unicode | Unicode | Dit is geen ideale configuratie voor het gebruik van meertalige gegevens. U kunt geen Unicode-gegevens schrijven naar de niet-Unicode-server. Er treden waarschijnlijk problemen op wanneer gegevens worden verzonden naar servers die zich buiten de codepagina van de server bevinden. |
| Niet-Unicode | Niet-Unicode | Dit is een zeer beperkt scenario voor meertalige gegevens. U kunt slechts één codepagina gebruiken. |
Aanvullende tekens
Het Unicode-consortium wijst aan elk teken een uniek codepunt toe. Dit is een waarde in het bereik 000000 - 10FFFFFF. De meest gebruikte tekens bevatten codepuntwaarden in het bereik 000000 - 00FFFF (65.536 tekens) die in een 8-bits of 16-bits woord in het geheugen en op de schijf passen. Dit bereik wordt meestal aangeduid als het BMP (Basic Multilingual Plane).
Maar het Unicode-consortium heeft 16 extra 'vlakjes' met tekens ingesteld, elk dezelfde grootte als de BMP. Met deze definitie kan Unicode 114.112 tekens (216 * 17 tekens) binnen het codepuntbereik 0000000 - 10FFFF vertegenwoordigen. Tekens met codepuntwaarde groter dan 00FFFF vereisen twee tot vier opeenvolgende 8-bits woorden (UTF-8) of twee opeenvolgende 16-bits woorden (UTF-16). Deze tekens die zich voorbij de BMP bevinden, worden aanvullende tekensgenoemd en de extra aaneengeschakelde 8-bits of 16-bits woorden worden surrogaatparengenoemd. Zie de Unicode Standard-voor meer informatie over aanvullende tekens, surrogaten en surrogaatparen.
SQL Server biedt gegevenstypen zoals nchar en nvarchar voor het opslaan van Unicode-gegevens in het BMP-bereik (000000 - 00FFFF), die de Database Engine codeert met UCS-2.
SQL Server 2012 (11.x) heeft een nieuwe reeks aanvullende tekens (_SC) sorteringen geïntroduceerd die kunnen worden gebruikt met de nchar-, nvarcharen sql_variant gegevenstypen die het volledige Unicode-tekenbereik (000000 - 10FFFF) vertegenwoordigen. Bijvoorbeeld: Latin1_General_100_CI_AS_SC of, als u een Japanse sortering gebruikt, Japanese_Bushu_Kakusu_100_CI_AS_SC.
SQL Server 2019 (15.x) breidt aanvullende tekenondersteuning uit naar de teken en varchar gegevenstypen met de nieuwe UTF-8 ingeschakelde sorteringen (_UTF8). Deze gegevenstypen kunnen ook het volledige Unicode-tekenbereik vertegenwoordigen.
Notitie
Vanaf SQL Server 2017 (14.x) ondersteunen alle nieuwe sorteringen automatisch aanvullende tekens.
Als u aanvullende tekens gebruikt:
Aanvullende tekens kunnen worden gebruikt in sorteer- en vergelijkingsbewerkingen in sorteringsversie 90 of hoger.
Alle versie 100-sorteringen ondersteunen taalkundige sortering met aanvullende tekens.
Aanvullende tekens worden niet ondersteund voor gebruik in metagegevens, zoals in namen van databaseobjecten.
De SC-vlag kan worden toegepast op:
- Sorteringen van versie 90
- Sorteringen van versie 100
De SC-vlag kan niet worden toegepast op:
- Windows-sorteringen zonder versie 80
- Binaire BIN- of BIN2-sorteringen
- De SQL*-sorteringen
- Versie 140-sorteringen (deze hebben de SC-vlag niet nodig, omdat ze al aanvullende tekens ondersteunen)
De volgende tabel vergelijkt het gedrag van sommige tekenreeksfuncties en tekenreeksoperatoren wanneer ze aanvullende tekens gebruiken met en zonder een aanvullende tekenbewuste sortering (SCA):
| Tekenreeksfunctie of operator | Met een SCA-sortering | Zonder SCA-sorteervolgorde |
|---|---|---|
|
CHARINDEX LEN PATINDEX |
Het UTF-16-surrogaatpaar wordt geteld als één codepunt. | Het UTF-16-surrogaatpaar wordt geteld als twee codepunten. |
|
LINKER Vervang REVERSE- RECHTS- SUBTEKENREEKS STUFF |
Deze functies behandelen elk surrogaatpaar als één codepunt en werken zoals verwacht. | Deze functies kunnen eventuele surrogaatparen splitsen en leiden tot onverwachte resultaten. |
| NCHAR | Retourneert het teken dat overeenkomt met de opgegeven Unicode-codepuntwaarde in het bereik 0 - 0x10FFFF. Als de opgegeven waarde in het bereik 0 - 0xFFFF ligt, wordt één teken geretourneerd. Voor hogere waarden wordt de bijbehorende surrogaat geretourneerd. | Een waarde die hoger is dan 0xFFFF retourneert NULL in plaats van de bijbehorende surrogaat. |
| UNICODE | Retourneert een UTF-16-codepunt in het bereik 0 - 0x10FFFF. | Retourneert een UCS-2-codepunt in het bereik 0 - 0xFFFF. |
|
Jokerteken voor het matchen van één teken jokerteken - tekens die niet overeenkomen met |
Aanvullende tekens worden ondersteund voor alle bewerkingen met wildcards. | Aanvullende tekens worden niet ondersteund voor deze wildcardbewerkingen. Andere wildcard-operators worden ondersteund. |
ondersteuning voor GB18030
GB18030 is een afzonderlijke standaard die wordt gebruikt in de Volksrepubliek China voor het coderen van Chinese tekens. In GB18030 kunnen tekens 1, 2 of 4 bytes lang zijn. SQL Server biedt ondersteuning voor GB18030-gecodeerde tekens door ze te herkennen wanneer ze de server binnenkomen vanuit een clienttoepassing en ze natively als Unicode-tekens te converteren en op te slaan. Nadat ze zijn opgeslagen op de server, worden ze behandeld als Unicode-tekens in eventuele volgende bewerkingen.
U kunt elke Chinese sortering gebruiken, bij voorkeur de nieuwste versie van 100. Alle versie 100-sorteringen ondersteunen taalkundige sortering met GB18030 tekens. Als de gegevens aanvullende tekens (surrogaatparen) bevatten, kunt u de SC-sorteringen gebruiken die beschikbaar zijn in SQL Server om het zoeken en sorteren te verbeteren.
Notitie
Zorg ervoor dat uw clienthulpprogramma's, zoals SQL Server Management Studio, het lettertype Dengxian gebruiken om tekenreeksen met GB18030-gecodeerde tekens correct weer te geven.
Ondersteuning voor complexe scripts
SQL Server kan ondersteuning bieden voor het invoeren, opslaan, wijzigen en weergeven van complexe scripts. Complexe scripts bevatten de volgende typen:
- Scripts die de combinatie van zowel van rechts naar links als van links naar rechts tekst bevatten, zoals een combinatie van Arabische en Engelse tekst.
- Scripts waarvan de tekens de vorm wijzigen, afhankelijk van hun positie, of wanneer ze worden gecombineerd met andere tekens, zoals Arabisch, Indic en Thais.
- Talen, zoals Thais, die interne woordenlijsten nodig hebben om woorden te herkennen, omdat er geen onderbrekingen tussen deze woorden zijn.
Databasetoepassingen die communiceren met SQL Server moeten gebruikmaken van besturingselementen die complexe scripts ondersteunen. Standaardbesturingselementen voor Windows-formulieren die in beheerde code worden gemaakt, ondersteunen complexe scripts.
Japanse sorteringen toegevoegd in SQL Server 2017
Vanaf SQL Server 2017 (14.x) worden nieuwe Japanse sorteringsfamilies ondersteund, met de permutaties van verschillende opties (_CS, _AS, _KS, _WSen _VSS), evenals _BIN en _BIN2.
Als u deze sorteringen wilt weergeven, kunt u een query uitvoeren op de SQL Server Database Engine:
SELECT name,
description
FROM sys.fn_helpcollations()
WHERE COLLATIONPROPERTY(name, 'Version') = 3;
Alle nieuwe sorteringen hebben ingebouwde ondersteuning voor aanvullende tekens, zodat geen van de nieuwe 140 sorteringen de SC-vlag heeft (of nodig).
Deze sorteringen worden ondersteund in Database Engine-indexen, tabellen die zijn geoptimaliseerd voor geheugen, columnstore-indexen en systeemeigen gecompileerde modules.
UTF-8-ondersteuning
SQL Server 2019 (15.x) introduceert volledige ondersteuning voor de veelgebruikte UTF-8-tekencodering als import- of exportcodering en als sortering op database- of kolomniveau voor tekenreeksgegevens. UTF-8 is toegestaan in de char en varchar datatypes, en het wordt ingeschakeld wanneer u een sortering van een object maakt of wijzigt naar een sortering met een UTF8-achtervoegsel. Een voorbeeld is het wijzigen van Latin1_General_100_CI_AS_SC in Latin1_General_100_CI_AS_SC_UTF8.
UTF-8 is alleen beschikbaar voor Windows-sorteringen die aanvullende tekens ondersteunen, zoals geïntroduceerd in SQL Server 2012 (11.x). De nchar en nvarchar gegevenstypen staan UCS-2- of UTF-16-codering alleen toe en ze blijven ongewijzigd.
Azure SQL Database en Azure SQL Managed Instance ondersteunen ook UTF-8 op database- en kolomniveau, terwijl SQL Managed Instance dit ook op serverniveau ondersteunt.
Opslagverschillen tussen UTF-8 en UTF-16
Het Unicode-consortium wijst aan elk teken een uniek codepunt toe. Dit is een waarde in het bereik 000000 - 10FFFFFF. Met SQL Server 2019 (15.x) zijn zowel UTF-8- als UTF-16-coderingen beschikbaar om het volledige bereik weer te geven:
- Met UTF-8-codering, tekens in het ASCII-bereik (000000 - 00007F) vereisen 1 byte, codepunten 000080 - 0007FF vereisen 2 bytes, codepunten 000800 - 00FFFF vereisen 3 bytes en codepunten 0010000 - 0010FFFFFF vereisen 4 bytes.
- Met UTF-16-codering vereisen codepunten 000000 - 00FFFF 2 bytes en codepunten 0010000 - 0010FFFFFF 4 bytes.
De volgende tabel bevat de coderingsopslagbytes voor elk tekenbereik en coderingstype:
| Codebereik (hexadecimaal) | Codebereik (decimaal) | Opslagbytes 1 met UTF-8 | Opslagbytes 1 met 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 |
1Opslagbytes verwijzen naar de gecodeerde bytelengte, niet naar de opslaggrootte van het gegevenstype op schijf. Zie nchar en nvarchar en char en varcharvoor meer informatie over opslaggrootten op schijf.
2 Het codepuntbereik voor aanvullende tekens.
Tip
Het is een algemene perceptie, in char en varchar of in nchar en nvarchar, dat n het aantal tekens definieert. Dit komt doordat in het voorbeeld van een teken(10) kolom 10 ASCII-tekens in het bereik 0 - 127 kunnen worden opgeslagen met behulp van een sortering zoals Latin1_General_100_CI_AI, omdat elk teken in dit bereik slechts 1 byte gebruikt. In teken- en varchar-definieert n echter de tekenreeksgrootte in bytes (0 - 8.000) en in nchar- en nvarchar-definieert n de tekenreeksgrootte in byteparen (0 - 4.000).
n definieert nooit getallen van tekens die kunnen worden opgeslagen.
Als u de juiste Unicode-codering en het juiste gegevenstype kiest, bespaart u mogelijk aanzienlijke opslagruimte of verhoogt u de huidige opslagvoetafdruk, afhankelijk van de tekenset die in gebruik is. Als u bijvoorbeeld een Latijnse sortering gebruikt waarvoor UTF-8 is ingeschakeld, zoals Latin1_General_100_CI_AI_SC_UTF8, worden in een teken(10) kolom 10 bytes opgeslagen en kunnen 10 ASCII-tekens in het bereik 0 - 127 worden opgeslagen. Maar het mag slechts vijf tekens bevatten in het bereik 128 - 2047 en slechts drie tekens in het bereik 2048 - 65535. Ter vergelijking, omdat een nchar(10) kolom 10 byteparen (20 bytes) opslaat, kan deze 10 tekens bevatten in het bereik 0 - 65535.
Voordat u besluit of u UTF-8 of UTF-16-codering wilt gebruiken voor een database of kolom, moet u rekening houden met de distributie van tekenreeksgegevens die worden opgeslagen:
- Als het meestal in het ASCII-bereik 0 - 127 (zoals Engels) staat, vereist elk teken 1 byte met UTF-8 en 2 bytes met UTF-16. Het gebruik van UTF-8 biedt opslagvoordelen. Als u een bestaand kolomgegevenstype wijzigt met ASCII-tekens in het bereik 0 - 127 van nchar(10) naar char(10)en een UTF-8-enabled sortering gebruikt, resulteert dit in een reductie van 50 procent in opslagvereisten. Deze vermindering komt doordat nchar(10) 20 bytes nodig heeft voor opslag, vergeleken met char(10), waarvoor 10 bytes nodig zijn voor dezelfde Unicode-tekenreeksweergave.
- Boven het ASCII-bereik, bijna alle Latijnse schriften en Grieks, Cyrillisch, Koptisch, Armeens, Hebreeuws, Arabisch, Syriër, Tāna en N'Ko, zijn 2 bytes per teken vereist in zowel UTF-8 als UTF-16. In deze gevallen zijn er geen aanzienlijke opslagverschillen voor vergelijkbare gegevenstypen (bijvoorbeeld tussen het gebruik van teken of nchar).
- Als het voornamelijk Oost-Aziatische script (zoals Koreaans, Chinees en Japans) is, vereist elk teken 3 bytes met UTF-8 en 2 bytes met UTF-16. Het gebruik van UTF-16 biedt opslagvoordelen.
- Tekens in het bereik 010000 - 10FFFF vereisen 4 bytes in zowel UTF-8 als UTF-16. In deze gevallen zijn er geen opslagverschillen voor vergelijkbare gegevenstypen (bijvoorbeeld tussen het gebruik van teken of nchar).
Zie Write International Transact-SQL Statementsvoor andere overwegingen.
Converteren naar UTF-8
Omdat in char en varchar of in nchar en nvarcharde n de byteopslaggrootte bepaalt en niet het aantal tekens dat kan worden opgeslagen, is het belangrijk om de grootte van het gegevenstype te bepalen waarnaar u moet converteren. De tekens die groter zijn dan de grootte, moeten worden afgekapt.
Denk bijvoorbeeld aan een kolom die is gedefinieerd als nvarchar(100) waarin 180 bytes aan Japanse tekens worden opgeslagen. In dit voorbeeld worden de kolomgegevens momenteel gecodeerd met UCS-2 of UTF-16, waarbij 2 bytes per teken worden gebruikt. Het kolomtype converteren naar varchar(200) is niet voldoende om afkapping van gegevens te voorkomen, omdat het nieuwe gegevenstype slechts 200 bytes kan opslaan, maar Japanse tekens vereisen 3 bytes wanneer ze zijn gecodeerd in UTF-8. De kolom moet worden gedefinieerd als varchar(270) om gegevensverlies door afkapping van gegevens te voorkomen.
Daarom moet u vooraf weten wat de verwachte bytegrootte voor de kolomdefinitie is, voordat u bestaande gegevens converteert naar UTF-8 en de grootte van het nieuwe gegevenstype dienovereenkomstig aanpassen. Raadpleeg het Transact-SQL-script of het SQL Notebook in de Gegevensvoorbeelden GitHub-, die de DATALENGTH functie en de COLLATE instructie gebruiken om de juiste gegevenslengtevereisten voor UTF-8-conversiebewerkingen in een bestaande database te bepalen.
Als u de kolomsortering en het gegevenstype in een bestaande tabel wilt wijzigen, gebruikt u een van de methoden die worden beschreven in Dekolomsortering instellen of wijzigen.
Als u de databasesortering wilt wijzigen, zodat nieuwe objecten de databasesortering standaard overnemen of de serversortering wilt wijzigen, zodat nieuwe databases de systeemsortering standaard kunnen overnemen, raadpleegt u de sectie Gerelateerde taken sectie van dit artikel.
Gerelateerde taken
| Taak | Artikel |
|---|---|
| In dit document wordt beschreven hoe u de sortering van de instantie van SQL Server instelt of wijzigt. Als u de serversortering wijzigt, wordt de sortering van bestaande databases niet gewijzigd. | de serversorteervolgorde instellen of wijzigen |
| Hierin wordt beschreven hoe u de sortering van een gebruikersdatabase instelt of wijzigt. Als u een databasesortering wijzigt, wordt de sortering van bestaande tabelkolommen niet gewijzigd. | De collatie van de database instellen of wijzigen |
| Beschrijft hoe u de sortering van een kolom in de database instelt of wijzigt. | de kolomsorteervolgorde instellen of wijzigen |
| Beschrijft hoe u sorteringsgegevens op server-, database- of kolomniveau kunt retourneren. | Collatie-informatie weergeven |
| Beschrijft hoe u Transact-SQL instructies schrijft die meer draagbaar zijn van de ene taal naar de andere, of om meerdere talen gemakkelijker te ondersteunen. | Internationale Transact-SQL-verklaringen schrijven |
| Hierin wordt beschreven hoe u de taal van foutberichten en voorkeuren wijzigt voor hoe datum-, tijd- en valutagegevens worden gebruikt en weergegeven. | een sessietaal instellen |
Verwante inhoud
- aanbevolen procedures voor sql Server-sorteringswijziging
- Unicode-tekenindeling gebruiken om gegevens (SQL Server) te importeren of te exporteren
- Internationale Transact-SQL-verklaringen schrijven
- migratie van best practices voor SQL Server naar Unicode-
- Unicode Consortium
- Unicode Standard
- UTF-8-ondersteuning in OLE DB-stuurprogramma voor SQL Server-
- SQL Server-sorteringsnaam (Transact-SQL)
- Windows-sorteringsnaam (Transact-SQL)
- Introductie van UTF-8-ondersteuning voor SQL Server-
- COLLATE (Transact-SQL)
- Collatievolgorde
- Bevat database-sorteringen
- Een taal kiezen bij het maken van een Full-Text Index
- sys.fn_helpcollations (Transact-SQL)
- Single-Byte en multibyte-tekensets