Udostępnij za pośrednictwem

Obsługa sortowania i unicode

  • Artykuł

Dotyczy:programu SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)punkt końcowy analizy SQL w usłudze Microsoft FabricMagazyn w usłudze Microsoft Fabric

Sortowania w programie SQL Server definiują reguły sortowania oraz czułość na wielkość liter i akcenty dla danych. Sortowania używane z typami danych znakowych, takimi jak char i varchar, określają stronę kodową oraz znaki, które dany typ danych może reprezentować.

Niezależnie od tego, czy instalujesz nowe wystąpienie programu SQL Server, przywracasz kopię zapasową bazy danych, czy łączysz serwer z bazami danych klienckimi, ważne jest, aby zrozumieć wymagania dotyczące ustawień regionalnych, kolejność sortowania oraz wrażliwość na wielkość liter i akcenty danych, z którymi pracujesz. Aby wyświetlić listę sortowania dostępnych na instancji programu SQL Server, zobacz sys.fn_helpcollations.

Po wybraniu sortowania dla serwera, bazy danych, kolumny lub wyrażenia przypisujesz pewne cechy do danych. Te cechy wpływają na wyniki wielu operacji w bazie danych. Na przykład podczas konstruowania zapytania przy użyciu ORDER BYkolejność sortowania zestawu wyników może zależeć od sortowania zastosowanego do bazy danych lub określonego w klauzuli COLLATE na poziomie wyrażenia zapytania.

Aby najlepiej używać obsługi sortowania w programie SQL Server, należy zrozumieć terminy zdefiniowane w tym artykule i sposób ich powiązania z cechami danych.

Terminy sortowania

Sortowanie

Sortowanie określa wzorce bitów reprezentujące każdy znak w zestawie danych. Sortowania określają również zasady porządkowania i porównywania danych. Program SQL Server obsługuje przechowywanie obiektów, które mają różne sortowania w pojedynczej bazie danych. W przypadku kolumn innych niż Unicode ustawienie sortowania określa stronę kodową danych i znaki, które mogą być reprezentowane. Dane przenoszone między kolumnami innych niż Unicode muszą zostać przekonwertowane ze strony kodu źródłowego na docelową stronę kodową.

Transact-SQL wyniki instrukcji mogą się różnić, gdy instrukcja jest uruchamiana w kontekście różnych baz danych, które mają różne ustawienia sortowania. Jeśli to możliwe, użyj ustandaryzowanego sortowania dla Twojej organizacji. W ten sposób nie trzeba określać sortowania w każdym znaku lub wyrażeniu Unicode. Jeśli musisz pracować z obiektami, które mają różne ustawienia sortowania i strony kodowej, należy kodować zapytania, aby wziąć pod uwagę reguły pierwszeństwa sortowania. Aby uzyskać więcej informacji, zobacz priorytet sortowania.

Opcje skojarzone z sortowaniem to czułość wielkości liter, czułość akcentu, czułość kana, czułość szerokości i czułość selektora odmiany. Program SQL Server 2019 (15.x) wprowadza dodatkową opcję kodowania UTF-8.

Te opcje można określić, dołączając je do nazwy sortowania. Na przykład porządkowanie Japanese_Bushu_Kakusu_100_CS_AS_KS_WS_SC_UTF8 rozróżnia wielkość liter, uwzględnia akcenty, rozróżnia znaki kana, rozróżnia szerokość i jest kodowane w UTF-8. Przykładowo, sortowanie Japanese_Bushu_Kakusu_140_CI_AI_KS_WS_VSS ignoruje wielkość liter, ignoruje akcenty, rozróżnia kana, uwzględnia szerokość, czułość na selektor odmiany i używa starszej strony kodowej dla varchar.

Zachowanie skojarzone z tymi różnymi opcjami opisano w poniższej tabeli:

Opcja Opis
Uwzględnianie wielkości liter (_CS) Rozróżnia wielkie i małe litery. Jeśli ta opcja jest zaznaczona, małe litery są sortowane przed ich wielkimi wersjami. Jeśli ta opcja nie jest zaznaczona, sortowanie jest bez uwzględniania wielkości liter. Oznacza to, że program SQL Server uważa, że wielkie i małe wersje liter są identyczne do celów sortowania. Można jawnie wybrać opcję ignorowania wielkości liter, określając _CI.
Wrażliwe na akcent (_AS) Rozróżnia znaki z akcentem i bez akcentu. Na przykład a nie jest równa ấ. Jeśli ta opcja nie jest zaznaczona, sortowanie jest niewrażliwe na akcent. Oznacza to, że SQL Server uważa akcentowane i nieakcentowane wersje liter za identyczne do celów sortowania. Możesz jawnie wybrać niewrażliwość na akcent, określając _AI.
Wrażliwe na kanę (_KS) Rozróżnia dwa typy japońskich znaków kana: Hiragana i Katakana. Jeśli ta opcja nie jest zaznaczona, sortowanie ignoruje znaki kana. Oznacza to, że program SQL Server uważa znaki Hiragana i Katakana za równe dla celów sortowania. Pominięcie tej opcji jest jedyną metodą określania niewrażliwości kana.
Wrażliwy na szerokość (_WS) Rozróżnia znaki o pełnej szerokości i pół szerokości. Jeśli ta opcja nie jest zaznaczona, SQL Server uważa reprezentację w pełnej i połowicznej szerokości tego samego znaku za identyczną do celów sortowania. Pominięcie tej opcji jest jedyną metodą określania niewrażliwości na szerokość.
Rozróżniana przez selektor odmiany (_VSS) Rozróżnia różne selektory odmian ideograficznych w japońskich kolacjach Japanese_Bushu_Kakusu_140 i Japanese_XJIS_140, które zostały wprowadzone w programie SQL Server 2017 (14.x). Sekwencja odmian składa się z znaku podstawowego oraz selektora odmiany. Jeśli ta opcja _VSS nie jest zaznaczona, sortowanie jest niewrażliwe na selektor odmiany, a selektor odmiany nie jest brany pod uwagę w porównaniu. Oznacza to, że program SQL Server uwzględnia znaki utworzone na podstawie tego samego znaku podstawowego z różnymi selektorami odmian, które mają być identyczne do celów sortowania. Aby uzyskać więcej informacji, zobacz Baza danych ideograficznych wariantów Unicode.

Sortowania z uwzględnieniem selektora odmian (_VSS) nie są obsługiwane w indeksach wyszukiwania pełnotekstowego. Indeksy wyszukiwania pełnotekstowego obsługują tylko opcje Accent-Sensitive (_AS), kana-sensitive (_KS) i Width-sensitive (_WS). Silniki integracyjne SQL Server XML i środowiska uruchomieniowego języka wspólnego (CLR) nie obsługują selektorów odmian (_VSS).
Plik binarny (_BIN) 1 Sortuje i porównuje dane w tabelach programu SQL Server na podstawie wzorców bitów zdefiniowanych dla każdego znaku. Kolejność sortowania binarnego jest wrażliwa na wielkość liter i akcenty. Kolejność binarna jest również najszybszą metodą sortowania. Aby uzyskać więcej informacji, zobacz sekcję sortowania binarnego w tym artykule.
Punkt kodu binarnego (_BIN2) 1 Sortuje i porównuje dane w tabelach programu SQL Server na podstawie punktów kodu Unicode dla danych Unicode. W przypadku danych innych niż Unicode punkt kodu binarnego używa porównań, które są identyczne z tymi dla sortowania binarnego.

Zaletą używania kolejności sortowania według kodu binarnego jest to, że w aplikacjach, które porównują posortowane dane w programie SQL Server, nie jest wymagane ponowne sortowanie danych. W rezultacie kolejność sortowania punktów kodu binarnego zapewnia prostszy rozwój aplikacji i możliwe zwiększenie wydajności. Aby uzyskać więcej informacji, zobacz sekcję sortowania binarnego w tym artykule.
UTF-8 (_UTF8) Umożliwia przechowywanie danych zakodowanych w formacie UTF-8 w programie SQL Server. Jeśli ta opcja nie jest zaznaczona, program SQL Server używa domyślnego formatu kodowania innego niż Unicode dla odpowiednich typów danych. Aby uzyskać więcej informacji, zobacz sekcję wsparcia dla UTF-8 w tym artykule.

1 Jeśli wybrano kod binarny lub binarny, opcje Uwzględnianie wielkości liter (_CS), Uwzględnianie akcentu (_AS), Kana (_KS) i Uwzględnianie szerokości (_WS) nie są dostępne.

Przykłady opcji sortowania

Każde sortowanie jest łączone jako seria sufiksów definiujących wielkość liter, akcent, szerokość lub czułość kana. W poniższych przykładach opisano zachowanie kolejności sortowania dla różnych kombinacji sufiksów.

Sufiks sortowania systemu Windows Opis kolejności sortowania
_BIN 1 Sortowanie binarne
_BIN2 1, 2 Kolejność sortowania punktów kodu binarnego
_CI_AI 2 Bez uwzględniania wielkości liter, bez uwzględniania akcentu, bez uwzględniania kana, bez uwzględniania szerokości
_CI_AI_KS 2 Bez uwzględniania wielkości liter, bez uwzględniania akcentu, z uwzględnieniem kany, bez uwzględniania szerokości
_CI_AI_KS_WS 2 Bez uwzględniania wielkości liter, bez uwzględniania akcentu, rozróżniająca się pod względem kana, rozróżniająca się pod względem szerokości
_CI_AI_WS 2 Niewrażliwe na wielkość liter, niewrażliwe na akcent, niewrażliwe na kana, wrażliwe na szerokość
_CI_AS 2 Bez uwzględniania wielkości liter, z uwzględnieniem akcentu, bez uwzględniania kana, niewrażliwego na szerokość
_CI_AS_KS 2 Niewrażliwa na wielkość liter, uwzględnianie akcentów, rozróżniana kana, niewrażliwa na różnice szerokości
_CI_AS_KS_WS 2 Bez uwzględnienia wielkości liter, wrażliwość na akcent, wrażliwość na kana, wrażliwość na szerokość
_CI_AS_WS 2 Niewrażliwe na wielkość liter, wrażliwe na akcent, niewrażliwe na kanę, wrażliwe na szerokość
_CS_AI 2 Uwzględniana wielkość liter, bez uwzględniania akcentów, niewrażliwa na kana, bez uwzględniania szerokości
_CS_AI_KS 2 Wrażliwa na wielkość liter, niewrażliwa na akcent, wrażliwa na kana, niewrażliwa na szerokość
_CS_AI_KS_WS 2 Uwzględniana wielkość liter, bez uwzględniania akcentu, wrażliwa na kana, rozróżniana szerokość
_CS_AI_WS 2 Wrażliwa na wielkość liter, niewrażliwa na akcenty, niewrażliwa na kana, wrażliwa na szerokość
_CS_AS 2 Wrażliwa na wielkość liter, wrażliwa na akcenty, niewrażliwa na znaki kana, niewrażliwa na szerokość
_CS_AS_KS 2 Wrażliwy na wielkość liter, wrażliwy na akcenty, wrażliwy na kana, niewrażliwy na szerokość
_CS_AS_KS_WS 2 Wrażliwa na wielkość liter, wrażliwa na akcent, wrażliwa na kana, wrażliwa na szerokość
_CS_AS_WS 2 Wrażliwa na wielkość liter, wrażliwa na akcenty, niewrażliwa na kana, wrażliwa na szerokość

1 Jeśli wybrano kod binarny lub binarny, opcje Uwzględnianie wielkości liter (_CS), Uwzględnianie akcentu (_AS), Kana (_KS) i Uwzględnianie szerokości (_WS) nie są dostępne.

2 Dodawanie opcji UTF-8 (_UTF8) umożliwia kodowanie danych Unicode przy użyciu protokołu UTF-8. Aby uzyskać więcej informacji, zobacz sekcję wsparcia dla UTF-8 w tym artykule.

Zestawy sortowania

Program SQL Server obsługuje następujące zestawy sortowania:

Sortowania systemu Windows

Sortowania systemu Windows określają zasady dotyczące przechowywania danych znakowych, które są oparte na powiązanym lokalizatorze systemowym Windows. W przypadku sortowania systemu Windows można zaimplementować porównanie danych innych niż Unicode przy użyciu tego samego algorytmu co w przypadku danych Unicode. Podstawowe reguły sortowania systemu Windows określają, który alfabet lub język jest używany podczas sortowania słownika. Reguły określają również stronę kodową używaną do przechowywania danych znaków innych niż Unicode. Sortowanie Unicode i nie-Unicode są zgodne w porównaniach ciągów w określonej wersji Systemu Windows. Zapewnia to spójność między typami danych w programie SQL Server i umożliwia deweloperom sortowanie ciągów w aplikacjach przy użyciu tych samych reguł, które są używane przez program SQL Server. Aby uzyskać więcej informacji, zobacz nazwę sortowania systemu Windows.

Sortowania binarne

Sortowania binarne sortują dane na podstawie sekwencji zakodowanych wartości zdefiniowanych przez ustawienia regionalne i typ danych. Uwzględniana jest wielkość liter. Sortowanie binarne w programie SQL Server definiuje ustawienia regionalne i stronę kodową ANSI, która jest używana. Wymusza to binarną kolejność sortowania. Ponieważ są one stosunkowo proste, sortowania binarne pomagają zwiększyć wydajność aplikacji. W przypadku typów danych innych niż Unicode porównania danych są oparte na punktach kodu zdefiniowanych na stronie kodowej ANSI. W przypadku typów danych Unicode porównania danych są oparte na punktach kodu Unicode. W przypadku sortowania binarnego w typach danych Unicode ustawienia regionalne nie są uwzględniane w sortowaniu danych. Na przykład Latin1_General_BIN i Japanese_BIN dają identyczne wyniki sortowania, gdy są używane na danych Unicode. Aby uzyskać więcej informacji, zobacz nazwę sortowania systemu Windows.

Istnieją dwa typy sortowania binarnego w programie SQL Server:

  • Starsze sortowania BIN, które wykonały niekompletne porównanie punkt-punkt-kod dla danych Unicode. Starsze sortowania binarne porównywały pierwszy znak jako WCHAR, a następnie bajt po bajcie. W sortowaniu BIN tylko pierwszy znak jest sortowany zgodnie z punktem kodu, a pozostałe znaki są sortowane zgodnie z ich wartościami bajtów.

  • Nowsze sortowania BIN2, które implementują czyste porównanie punktów kodu. W sortowaniu BIN2 wszystkie znaki są sortowane zgodnie z ich punktami kodu. Ponieważ platforma Intel jest architekturą little endian, znaki kodu Unicode są zawsze przechowywane jako przestawione bajty.

Sortowania programu SQL Server

Sortowania w programie SQL Server (SQL_*) zapewniają zgodność kolejności sortowania z wcześniejszymi wersjami SQL Server. Reguły sortowania słowników dla danych innych niż Unicode są niezgodne z dowolną procedurą sortowania dostarczaną przez systemy operacyjne Windows. Jednak sortowanie danych Unicode jest zgodne z określoną wersją reguł sortowania systemu Windows. Ponieważ sortowania programu SQL Server używają różnych reguł porównania dla danych innych niż Unicode i Unicode, są widoczne różne wyniki dla porównań tych samych danych, w zależności od bazowego typu danych.

Jeśli na przykład używasz sortowania SQL SQL_Latin1_General_CP1_CI_AS, ciąg nie-Unicode 'a-c' jest mniejszy niż ciąg 'ab', ponieważ łącznik (-) jest sortowany jako osobny znak, który występuje przed b. Jeśli jednak przekonwertujesz te ciągi na Unicode i wykonasz to samo porównanie, ciąg Unicode N'a-c' jest uważany za większy niż N'ab', ponieważ reguły sortowania Unicode używają sortowania wyrazów, które ignorują łącznik.

Aby uzyskać więcej informacji, zapoznaj się z nazwą sortowania SQL Server .

Podczas instalacji programu SQL Server domyślne ustawienie sortowania instalacji jest określane przez ustawienia regionalne systemu operacyjnego. Sortowanie na poziomie serwera można zmienić podczas instalacji lub zmieniając ustawienia regionalne systemu operacyjnego przed instalacją. Ze względów kompatybilności wstecznej sortowanie domyślne jest ustawione na najstarszą dostępną wersję skojarzoną z poszczególnymi ustawieniami lokalnymi. W związku z tym nie zawsze jest to zalecane sortowanie. Aby w pełni korzystać z funkcji programu SQL Server, zmień domyślne ustawienia instalacji, aby używać sortowania systemu Windows. Na przykład dla ustawień regionalnych systemu operacyjnego "Angielski (Stany Zjednoczone)" (strona kodowa 1252), domyślne sortowanie podczas instalacji jest SQL_Latin1_General_CP1_CI_AS, i można go zmienić na jego najbliższy odpowiednik sortowania systemu Windows, Latin1_General_100_CI_AS_SC.

Podczas uaktualniania wystąpienia programu SQL Server w języku angielskim można określić sortowania programu SQL Server (SQL_*) pod kątem zgodności z istniejącymi wystąpieniami programu SQL Server. Ponieważ podczas instalacji zdefiniowano domyślne sortowanie dla wystąpienia programu SQL Server, upewnij się, że ustawienia sortowania zostały dokładnie określone, gdy spełnione są następujące warunki:

  • Kod aplikacji zależy od zachowania poprzednich sortowania programu SQL Server.
  • Musisz przechowywać dane znaków odzwierciedlające wiele języków.

Poziomy sortowania

Sortowania ustawień są obsługiwane na następujących poziomach wystąpienia programu SQL Server:

Sortowania na poziomie serwera

Sortowanie serwera domyślnego jest określane podczas instalacji programu SQL Server i staje się domyślnym sortowaniem systemowych baz danych i wszystkich baz danych użytkowników.

W poniższej tabeli przedstawiono domyślne oznaczenia sortowania określone przez ustawienia regionalne systemu operacyjnego, w tym identyfikatory kodu języka (LCID) dla Windows i SQL.

Ustawienia regionalne systemu Windows Windows LCID SQL LCID Sortowanie domyślne
Afrikaans (Republika Południowej Afryki) 0x0436 0x0409 Latin1_General_CI_AS
Albański (Albania) 0x041c 0x041c Albanian_CI_AS
Alsatian (Francja) 0x0484 0x0409 Latin1_General_CI_AS
Amharic (Etiopia) 0x045e 0x0409 Latin1_General_CI_AS
Arabski (Algieria) 0x1401 0x0401 Arabic_CI_AS
Arabski (Bahrajn) 0x3c01 0x0401 Arabic_CI_AS
Arabski (Egipt) 0x0c01 0x0401 Arabic_CI_AS
Arabski (Irak) 0x0801 0x0401 Arabic_CI_AS
Arabski (Jordania) 0x2c01 0x0401 Arabic_CI_AS
Arabski (Kuwejt) 0x3401 0x0401 Arabic_CI_AS
Arabski (Liban) 0x3001 0x0401 Arabic_CI_AS
Arabski (Libia) 0x1001 0x0401 Arabic_CI_AS
Arabski (Maroko) 0x1801 0x0401 Arabic_CI_AS
Arabski (Oman) 0x2001 0x0401 Arabic_CI_AS
Arabski (Katar) 0x4001 0x0401 Arabic_CI_AS
Arabski (Arabia Saudyjska) 0x0401 0x0401 Arabic_CI_AS
Arabski (Syria) 0x2801 0x0401 Arabic_CI_AS
Arabski (Tunezja) 0x1c01 0x0401 Arabic_CI_AS
Arabski (U.A.E.) 0x3801 0x0401 Arabic_CI_AS
Arabski (Jemen) 0x2401 0x0401 Arabic_CI_AS
Ormiański (Armenia) 0x042b 0x0419 Latin1_General_CI_AS
Assamese (Indie) 0x044d 0x044d Niedostępne na poziomie serwera
Azerbejdżański (Azerbejdżan, Cyrylica) 0x082c 0x082c Przestarzałe, niedostępne na poziomie serwera
Azerbejdżański (Azerbejdżan, Łaciński) 0x042c 0x042c Przestarzałe, niedostępne na poziomie serwera
Bashkir (Rosja) 0x046d 0x046d Latin1_General_CI_AI
Baskijski (baskijski) 0x042d 0x0409 Latin1_General_CI_AS
Białorusin (Białoruś) 0x0423 0x0419 Cyrillic_General_CI_AS
Bangla (Bangladesz) 0x0845 0x0445 Niedostępne na poziomie serwera
Bengalski (Indie) 0x0445 0x0439 Niedostępne na poziomie serwera
Bośniacki (Bośnia i Hercegowina, cyrylica) 0x201a 0x201a Latin1_General_CI_AI
Bośniacki (Bośnia i Hercegowina, Łaciński) 0x141a 0x141a Latin1_General_CI_AI
Breton (Francja) 0x047e 0x047e Latin1_General_CI_AI
Bułgarski (Bułgaria) 0x0402 0x0419 Cyrillic_General_CI_AS
Kataloński (kataloński) 0x0403 0x0409 Latin1_General_CI_AS
Chiński (Hongkong, Specjalny Region Administracyjny, ChRL) 0x0c04 0x0404 Chinese_Taiwan_Stroke_CI_AS
Chiński (Makao SAR) 0x1404 0x1404 Latin1_General_CI_AI
Chiński (Makao SAR) 0x21404 0x21404 Latin1_General_CI_AI
Chiński (ChRL) 0x0804 0x0804 Chinese_PRC_CI_AS
Chiński (ChRL) 0x20804 0x20804 Chinese_PRC_Stroke_CI_AS
Chiński (Singapur) 0x1004 0x0804 Chinese_PRC_CI_AS
Chiński (Singapur) 0x21004 0x20804 Chinese_PRC_Stroke_CI_AS
Chiński (Tajwan) 0x30404 0x30404 Chinese_Tajwan_Bopomofo_CI_AS
Chiński (Tajwan) 0x0404 0x0404 Chinese_Taiwan_Stroke_CI_AS
Korsykan (Francja) 0x0483 0x0483 Latin1_General_CI_AI
Chorwacki (Bośnia i Hercegowina, Łaciński) 0x101a 0x041a Croatian_CI_AS
Chorwacki (Chorwacja) 0x041a 0x041a Croatian_CI_AS
Czeski (Czechy) 0x0405 0x0405 Czech_CI_AS
Duński (Dania) 0x0406 0x0406 Danish_Norwegian_CI_AS
Dari (Afganistan) 0x048c 0x048c Latin1_General_CI_AI
Divehi (Malediwy) 0x0465 0x0465 Niedostępne na poziomie serwera
Holenderski (Belgia) 0x0813 0x0409 Latin1_General_CI_AS
Niderlandzki (Holandia) 0x0413 0x0409 Latin1_General_CI_AS
Angielski (Australia) 0x0c09 0x0409 Latin1_General_CI_AS
Angielski (Belize) 0x2809 0x0409 Latin1_General_CI_AS
Angielski (Kanada) 0x1009 0x0409 Latin1_General_CI_AS
Angielski (Karaiby) 0x2409 0x0409 Latin1_General_CI_AS
Angielski (Indie) 0x4009 0x0409 Latin1_General_CI_AS
Angielski (Irlandia) 0x1809 0x0409 Latin1_General_CI_AS
Angielski (Jamajka) 0x2009 0x0409 Latin1_General_CI_AS
Angielski (Malezja) 0x4409 0x0409 Latin1_General_CI_AS
Angielski (Nowa Zelandia) 0x1409 0x0409 Latin1_General_CI_AS
Angielski (Filipiny) 0x3409 0x0409 Latin1_General_CI_AS
Angielski (Singapur) 0x4809 0x0409 Latin1_General_CI_AS
Angielski (Republika Południowej Afryki) 0x1c09 0x0409 Latin1_General_CI_AS
Angielski (Trynidad i Tobago) 0x2c09 0x0409 Latin1_General_CI_AS
Angielski (Wielka Brytania) 0x0809 0x0409 Latin1_General_CI_AS
Angielski (Stany Zjednoczone) 0x0409 0x0409 SQL_Latin1_General_CP1_CI_AS
Angielski (Zimbabwe) 0x3009 0x0409 Latin1_General_CI_AS
Język estoński (Estonia) 0x0425 0x0425 Estonian_CI_AS
Język farerski (Wyspy Owcze) 0x0438 0x0409 Latin1_General_CI_AS
Język filipiński (Filipiny) 0x0464 0x0409 Latin1_General_CI_AS
Fiński (Finlandia) 0x040b 0x040b Finnish_Swedish_CI_AS
Francuski (Belgia) 0x080c 0x040c French_CI_AS
Francuski (Kanada) 0x0c0c 0x040c French_CI_AS
Francuski (Francja) 0x040c 0x040c French_CI_AS
Francuski (Luksemburg) 0x140c 0x040c French_CI_AS
Francuski (Monako) 0x180c 0x040c French_CI_AS
Francuski (Szwajcaria) 0x100c 0x040c French_CI_AS
Frisian (Holandia) 0x0462 0x0462 Latin1_General_CI_AI
Galicyjski 0x0456 0x0409 Latin1_General_CI_AS
Gruziński (Georgia) 0x10437 0x10437 Georgian_Modern_Sort_CI_AS
Gruziński (Georgia) 0x0437 0x0419 Latin1_General_CI_AS
Niemiecki — Sortowanie książek telefonicznych (DIN) 0x10407 0x10407 German_PhoneBook_CI_AS
Niemiecki (Austria) 0x0c07 0x0409 Latin1_General_CI_AS
Niemiecki (Niemcy) 0x0407 0x0409 Latin1_General_CI_AS
Niemiecki (Liechtenstein) 0x1407 0x0409 Latin1_General_CI_AS
Niemiecki (Luksemburg) 0x1007 0x0409 Latin1_General_CI_AS
Niemiecki (Szwajcaria) 0x0807 0x0409 Latin1_General_CI_AS
Grecki (Grecja) 0x0408 0x0408 Greek_CI_AS
Grenlandzki (Grenlandia) 0x046f 0x0406 Danish_Norwegian_CI_AS
Gujarati (Indie) 0x0447 0x0439 Niedostępne na poziomie serwera
Hausa (Nigeria, Łacińska) 0x0468 0x0409 Latin1_General_CI_AS
Hebrajski (Izrael) 0x040d 0x040d Hebrew_CI_AS
Hindi (Indie) 0x0439 0x0439 Niedostępne na poziomie serwera
Węgierski (Węgry) 0x040e 0x040e Hungarian_CI_AS
Węgierskie sortowanie techniczne 0x1040e 0x1040e Hungarian_Technical_CI_AS
Islandzki (Islandia) 0x040f 0x040f Icelandic_CI_AS
Igbo (Nigeria) 0x0470 0x0409 Latin1_General_CI_AS
Indonezyjski (Indonezja) 0x0421 0x0409 Latin1_General_CI_AS
Inuktitut (Kanada, alfabet łaciński) 0x085d 0x0409 Latin1_General_CI_AS
Inuktitut (Syllabics) Kanada 0x045d 0x045d Latin1_General_CI_AI
Irlandzki (Irlandia) 0x083c 0x0409 Latin1_General_CI_AS
Włoski (Włochy) 0x0410 0x0409 Latin1_General_CI_AS
Włoski (Szwajcaria) 0x0810 0x0409 Latin1_General_CI_AS
Japoński (Japonia XJIS) 0x0411 0x0411 Japanese_CI_AS
Japoński (Japonia) 0x040411 0x40411 Latin1_General_CI_AI
Kannada (Indie) 0x044b 0x0439 Niedostępne na poziomie serwera
kazachski (Kazachstan) 0x043f 0x043f Kazakh_90_CI_AS
Khmer (Kambodża) 0x0453 0x0453 Niedostępne na poziomie serwera
K'iche (Gwatemala) 0x0486 0x0c0a Modern_Spanish_CI_AS
Kinyarwanda (Rwanda) 0x0487 0x0409 Latin1_General_CI_AS
Konkani (Indie) 0x0457 0x0439 Niedostępne na poziomie serwera
Koreański (Sortowanie w słowniku koreańskim) 0x0412 0x0412 Korean_Wansung_CI_AS
Kirgizja (Kirgistan) 0x0440 0x0419 Cyrillic_General_CI_AS
Lao (Lao PDR) 0x0454 0x0454 Niedostępne na poziomie serwera
Łotewski (Łotwa) 0x0426 0x0426 Latvian_CI_AS
Litewski (Litwa) 0x0427 0x0427 Lithuanian_CI_AS
Dolna Łużysta (Niemcy) 0x082e 0x0409 Latin1_General_CI_AS
Luksemburski (Luksemburg) 0x046e 0x0409 Latin1_General_CI_AS
Macedoński (Macedonia Północna) 0x042f 0x042f Macedonian_FYROM_90_CI_AS
Malaj (Brunei Darussalam) 0x083e 0x0409 Latin1_General_CI_AS
Malajski (Malezja) 0x043e 0x0409 Latin1_General_CI_AS
Malajalam (Indie) 0x044c 0x0439 Niedostępne na poziomie serwera
Maltański (Malta) 0x043a 0x043a Latin1_General_CI_AI
Maori (Nowa Zelandia) 0x0481 0x0481 Latin1_General_CI_AI
Mapudungun (Chile) 0x047a 0x047a Latin1_General_CI_AI
Marathi (Indie) 0x044e 0x0439 Niedostępne na poziomie serwera
Mohawk (Kanada) 0x047c 0x047c Latin1_General_CI_AI
mongolski (Mongolia) 0x0450 0x0419 Cyrillic_General_CI_AS
Mongolski (ChRL) 0x0850 0x0419 Cyrillic_General_CI_AS
Nepalski (Nepal) 0x0461 0x0461 Niedostępne na poziomie serwera
Norweski (Bokmål, Norwegia) 0x0414 0x0414 Latin1_General_CI_AI
Norweski (Nynorsk, Norwegia) 0x0814 0x0414 Latin1_General_CI_AI
Occitan (Francja) 0x0482 0x040c French_CI_AS
Odia (Indie) 0x0448 0x0439 Niedostępne na poziomie serwera
Pashto (Afganistan) 0x0463 0x0463 Niedostępne na poziomie serwera
Perski (Iran) 0x0429 0x0429 Latin1_General_CI_AI
Język polski (Polska) 0x0415 0x0415 Polish_CI_AS
Portugalski (Brazylia) 0x0416 0x0409 Latin1_General_CI_AS
Portugalski (Portugalia) 0x0816 0x0409 Latin1_General_CI_AS
Pendżabi (Indie) 0x0446 0x0439 Niedostępne na poziomie serwera
Quechua (Boliwia) 0x046b 0x0409 Latin1_General_CI_AS
Quechua (Ekwador) 0x086b 0x0409 Latin1_General_CI_AS
Quechua (Peru) 0x0c6b 0x0409 Latin1_General_CI_AS
Rumuński (Rumunia) 0x0418 0x0418 Romanian_CI_AS
Romansh (Szwajcaria) 0x0417 0x0417 Latin1_General_CI_AI
Rosyjski (Rosja) 0x0419 0x0419 Cyrillic_General_CI_AS
Sahka (Rosja) 0x0485 0x0485 Latin1_General_CI_AI
Sami (Inari, Finlandia) 0x243b 0x083b Latin1_General_CI_AI
Sami (Lule, Norwegia) 0x103b 0x043b Latin1_General_CI_AI
Sami (Lule, Szwecja) 0x143b 0x083b Latin1_General_CI_AI
Sami (Północna, Finlandia) 0x0c3b 0x083b Latin1_General_CI_AI
Sami (Północna, Norwegia) 0x043b 0x043b Latin1_General_CI_AI
Sami (Północna, Szwecja) 0x083b 0x083b Latin1_General_CI_AI
Sami (Skolt, Finlandia) 0x203b 0x083b Latin1_General_CI_AI
Sami (Południowy, Norwegia) 0x183b 0x043b Latin1_General_CI_AI
Saamowie (południowa Szwecja) 0x1c3b 0x083b Latin1_General_CI_AI
Sanskrit (Indie) 0x044f 0x0439 Niedostępne na poziomie serwera
Serbski (Bośnia i Hercegowina, cyrylica) 0x1c1a 0x0c1a Latin1_General_CI_AI
Serbski (Bośnia i Hercegowina, Łaciński) 0x181a 0x081a Latin1_General_CI_AI
język serbski (Serbia, cyrylica) 0x0c1a 0x0c1a Latin1_General_CI_AI
Serbski (Serbia, Łaciński) 0x081a 0x081a Latin1_General_CI_AI
Sesotho sa Leboa/Northern Sotho (Republika Południowej Afryki) 0x046c 0x0409 Latin1_General_CI_AS
Setswana/Tswana (Republika Południowej Afryki) 0x0432 0x0409 Latin1_General_CI_AS
Sinhala (Sri Lanka) 0x045b 0x0439 Niedostępne na poziomie serwera
Słowacki (Słowacja) 0x041b 0x041b Slovak_CI_AS
słoweński (Słowenia) 0x0424 0x0424 Slovenian_CI_AS
Hiszpański (Argentyna) 0x2c0a 0x0c0a Modern_Spanish_CI_AS
Hiszpański (Boliwia) 0x400a 0x0c0a Modern_Spanish_CI_AS
Hiszpański (Chile) 0x340a 0x0c0a Modern_Spanish_CI_AS
Hiszpański (Kolumbia) 0x240a 0x0c0a Modern_Spanish_CI_AS
Hiszpański (Kostaryka) 0x140a 0x0c0a Modern_Spanish_CI_AS
Hiszpański (Dominikana) 0x1c0a 0x0c0a Modern_Spanish_CI_AS
Hiszpański (Ekwador) 0x300a 0x0c0a Modern_Spanish_CI_AS
Hiszpański (Salwador) 0x440a 0x0c0a Modern_Spanish_CI_AS
Hiszpański (Gwatemala) 0x100a 0x0c0a Modern_Spanish_CI_AS
Hiszpański (Honduras) 0x480a 0x0c0a Modern_Spanish_CI_AS
Hiszpański (Meksyk) 0x080a 0x0c0a Modern_Spanish_CI_AS
Hiszpański (Nikaragua) 0x4c0a 0x0c0a Modern_Spanish_CI_AS
Hiszpański (Panama) 0x180a 0x0c0a Modern_Spanish_CI_AS
Hiszpański (Paragwaj) 0x3c0a 0x0c0a Modern_Spanish_CI_AS
Hiszpański (Peru) 0x280a 0x0c0a Modern_Spanish_CI_AS
Hiszpański (Portoryko) 0x500a 0x0c0a Modern_Spanish_CI_AS
Hiszpański (Hiszpania) 0x0c0a 0x0c0a Modern_Spanish_CI_AS
Hiszpański (Hiszpania, Tradycyjne sortowanie) 0x040a 0x040a Traditional_Spanish_CI_AS
Hiszpański (Stany Zjednoczone) 0x540a 0x0409 Latin1_General_CI_AS
Hiszpański (Urugwaj) 0x380a 0x0c0a Modern_Spanish_CI_AS
Hiszpański (Wenezuela) 0x200a 0x0c0a Modern_Spanish_CI_AS
Suahili (Kenia) 0x0441 0x0409 Latin1_General_CI_AS
Szwedzki (Finlandia) 0x081d 0x040b Finnish_Swedish_CI_AS
Szwedzki (Szwecja) 0x041d 0x040b Finnish_Swedish_CI_AS
Syryjski (Syria) 0x045a 0x045a Niedostępne na poziomie serwera
Tadżycki (Tadżykistan) 0x0428 0x0419 Cyrillic_General_CI_AS
Tamazight (Algieria, Łacińska) 0x085f 0x085f Latin1_General_CI_AI
Tamil (Indie) 0x0449 0x0439 Niedostępne na poziomie serwera
Tatar (Rosja) 0x0444 0x0444 Cyrillic_General_CI_AS
Telugu (Indie) 0x044a 0x0439 Niedostępne na poziomie serwera
Tajski (Tajlandia) 0x041e 0x041e Thai_CI_AS
Tybetańczyk (CHRL) 0x0451 0x0451 Niedostępne na poziomie serwera
Turecki (Turcja) 0x041f 0x041f Turkish_CI_AS
Turkmen (Turkmenistan) 0x0442 0x0442 Latin1_General_CI_AI
Ujgur (CHRL) 0x0480 0x0480 Latin1_General_CI_AI
Ukraiński (Ukraina) 0x0422 0x0422 Ukrainian_CI_AS
Górnołużycki (Niemcy) 0x042e 0x042e Latin1_General_CI_AI
Urdu (Pakistan) 0x0420 0x0420 Latin1_General_CI_AI
Uzbek (Uzbekistan, Cyrylica) 0x0843 0x0419 Cyrillic_General_CI_AS
Uzbek (Uzbekistan, alfabet łaciński) 0x0443 0x0443 Uzbek_Latin_90_CI_AS
Wietnamski (Wietnam) 0x042a 0x042a Vietnamese_CI_AS
Walijski (Wielka Brytania) 0x0452 0x0452 Latin1_General_CI_AI
Wolof (Senegal) 0x0488 0x040c French_CI_AS
Xhosa/isiXhosa (Republika Południowej Afryki) 0x0434 0x0409 Latin1_General_CI_AS
Yi (ChRL) 0x0478 0x0409 Latin1_General_CI_AS
Yoruba (Nigeria) 0x046a 0x0409 Latin1_General_CI_AS
Zulu/isiZulu (Republika Południowej Afryki) 0x0435 0x0409 Latin1_General_CI_AS

Po przypisaniu sortowania do serwera można go zmienić tylko przez wyeksportowanie wszystkich obiektów i danych bazy danych, ponowne skompilowanie master bazy danych i zaimportowanie wszystkich obiektów i danych bazy danych. Zamiast zmieniać domyślne sortowanie wystąpienia programu SQL Server, można określić żądane sortowanie podczas tworzenia nowej bazy danych lub kolumny bazy danych.

Aby sprawdzić ustawienia sortowania serwera dla instancji programu SQL Server, skorzystaj z funkcji SERVERPROPERTY:

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

Aby zapytać serwer o wszystkie dostępne sortowania, użyj następującej wbudowanej funkcji fn_helpcollations():

SELECT *
FROM sys.fn_helpcollations();

Sortowania w bazie danych Azure SQL

Nie można zmienić ani ustawić sortowania serwera logicznego w usłudze Azure SQL Database, ale można skonfigurować sortowania każdej bazy danych zarówno dla danych, jak i dla wykazu. Sortowanie wykazu określa sortowanie metadanych systemu, takich jak identyfikatory obiektów. Oba sortowania można określić niezależnie, gdy utworzyć bazę danych w witrynie Azure Portalw języku T-SQL za pomocą CREATE DATABASE, w programie PowerShell z new-AzSqlDatabase.

Sortowania w Azure SQL Managed Instance

Sortowanie na poziomie serwera w usłudze Azure SQL Managed Instance można określić podczas tworzenia wystąpienia i nie da się go później zmienić.

Aby uzyskać więcej informacji, zobacz Ustaw lub Zmień Sortowanie Serwera.

Sortowania na poziomie bazy danych

Podczas tworzenia lub modyfikowania bazy danych można użyć klauzuli COLLATE instrukcji CREATE DATABASE lub ALTER DATABASE, aby określić domyślne sortowanie bazy danych. Jeśli sortowanie nie zostanie określone, baza danych zostanie przypisana do sortowania serwera.

Nie można zmienić sortowania systemowych baz danych, chyba że zmienisz sortowanie serwera.

  • W programie SQL Server i usłudze Azure SQL Managed Instance sortowanie bazy danych jest używane dla wszystkich metadanych w bazie danych, a sortowanie jest ustawieniem domyślnym dla wszystkich kolumn ciągów, obiektów tymczasowych, nazw zmiennych i innych ciągów używanych w bazie danych.
  • W usłudze Azure SQL Database nie ma sortowania serwera, dlatego każda baza danych ma sortowanie danych i sortowanie dla katalogu. CATALOG_COLLATION jest używany dla wszystkich metadanych w bazie danych, a sortowanie jest ustawieniem domyślnym dla wszystkich kolumn ciągów, obiektów tymczasowych, nazw zmiennych i innych ciągów używanych w bazie danych. CATALOG_COLLATION jest ustawiana podczas tworzenia i nie można jej zmienić.

Podczas zmiany sortowania bazy danych użytkownika mogą pojawić się konflikty sortowania, gdy zapytania w tej bazie danych uzyskują dostęp do tabel tymczasowych. Tabele tymczasowe są zawsze przechowywane w systemowej bazie danych tempdb, która używa sortowania dla wystąpienia. Zapytania porównujące dane znaków między bazą danych użytkownika i tempdb mogą zakończyć się niepowodzeniem, jeśli sortowania powodują konflikt podczas oceniania danych znaków. Ten problem można rozwiązać, określając klauzulę COLLATE w zapytaniu. Aby uzyskać więcej informacji, zobacz COLLATE.

Sortowanie bazy danych użytkownika można zmienić przy użyciu instrukcji ALTER DATABASE podobnej do następującego przykładu kodu:

ALTER DATABASE myDB COLLATE Greek_CS_AI;

Ważny

Zmiana sortowania na poziomie bazy danych nie ma wpływu na sortowanie na poziomie kolumny ani na poziomie wyrażenia. Nie ma to wpływu na dane w istniejących kolumnach.

Bieżące sortowanie bazy danych można pobrać przy użyciu instrukcji podobnej do następującego przykładu kodu:

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

Sortowania na poziomie kolumn

Podczas tworzenia lub zmieniania tabeli można określić sortowania dla każdej kolumny ciągu znaków przy użyciu klauzuli COLLATE. Jeśli nie określisz sortowania, kolumna zostanie przypisana do domyślnego sortowania bazy danych.

Sortowanie kolumny można zmienić przy użyciu instrukcji ALTER TABLE podobnej do poniższego przykładu kodu:

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

Sortowania na poziomie wyrażeń

Sortowania na poziomie wyrażeń są ustawiane po uruchomieniu instrukcji i wpływają na sposób zwracania zestawu wyników. Umożliwia to ORDER BY sortowanie wyników zgodnie z regionalnymi ustawieniami. Aby zaimplementować sortowania na poziomie wyrażeń, użyj klauzuli COLLATE, takiej jak następujący przykład kodu:

SELECT name
FROM customer
ORDER BY name COLLATE Latin1_General_CS_AI;

Lokalizacja

Lokalizacja to zbiór informacji powiązanych z miejscem lub kulturą. Informacje mogą zawierać nazwę i identyfikator języka mówionego, skrypt używany do pisania języka i konwencji kulturowych. Sortowania mogą być skojarzone z jedną lub więcej lokalizacjami. Aby uzyskać więcej informacji, zapoznaj się z dokumentem Identyfikatory ustawień regionalnych przypisanych przez Microsoft.

Strona kodowa

Strona kodowa to uporządkowany zestaw znaków danego systemu pisma, w którym z każdym znakiem jest skojarzony indeks liczbowy lub wartość punktu kodowego. Strona kodowa systemu Windows jest zazwyczaj nazywana zestawem znaków lub zestawem znaków . Strony kodowe służą do zapewniania obsługi zestawów znaków i układów klawiatury, które są używane przez różne ustawienia regionalne systemu Windows.

Kolejność sortowania

Kolejność sortowania określa sposób sortowania wartości danych. Kolejność ma wpływ na wyniki porównania danych. Dane są sortowane przy użyciu sortowania i można je zoptymalizować przy użyciu indeksów.

Obsługa formatu Unicode

Unicode to standard mapowania punktów kodu na znaki. Ponieważ jest ona przeznaczona do obsługi wszystkich znaków we wszystkich językach świata, nie potrzebujesz różnych stron kodu do obsługi różnych zestawów znaków.

Podstawy Unicode

Przechowywanie danych w wielu językach w jednej bazie danych jest trudne do zarządzania, gdy używasz tylko danych znaków i stron kodu. Trudno jest również znaleźć jedną stronę kodową bazy danych, która może przechowywać wszystkie wymagane znaki specyficzne dla języka. Ponadto trudno jest zagwarantować poprawne tłumaczenie znaków specjalnych podczas ich odczytywania lub aktualizowania przez różnych klientów, którzy uruchamiają różne strony kodu. Bazy danych obsługujące klientów międzynarodowych powinny zawsze używać typów danych Unicode zamiast typów danych innych niż Unicode.

Rozważmy na przykład bazę danych klientów w Ameryce Północnej, która musi obsługiwać trzy główne języki:

  • Hiszpańskie nazwy i adresy meksyku
  • Francuskie nazwy i adresy dla Quebecu
  • Nazwy i adresy angielskie dla reszty Kanady i Stanów Zjednoczonych

W przypadku używania tylko kolumn znaków i stron kodu należy zadbać o to, aby baza danych została zainstalowana ze stroną kodową, która będzie obsługiwać znaki wszystkich trzech języków. Należy również zadbać o zagwarantowanie poprawnego tłumaczenia znaków z dowolnego z języków, gdy znaki są odczytywane przez klientów, którzy uruchamiają stronę kodową dla innego języka.

Notatka

Strony kodu używane przez klienta są określane przez ustawienia systemu operacyjnego. Aby ustawić strony kodu klienta w systemie operacyjnym Windows, użyj Ustawień Regionalnych w Panelu sterowania.

Trudno byłoby wybrać stronę kodową dla typów danych znaków, które będą obsługiwać wszystkie znaki wymagane przez odbiorców na całym świecie. Najprostszym sposobem zarządzania danymi znakowymi w międzynarodowych bazach danych jest zawsze użycie typu danych obsługującego kod Unicode.

Typy danych Unicode

Jeśli przechowujesz dane znaków odzwierciedlające wiele języków w programie SQL Server (SQL Server 2005 (9.x) i nowszych), użyj typów danych Unicode (nchar, nvarchari ntext) zamiast typów danych innych niż Unicode (znaków, varchari tekst).

Notatka

Dla typów danych Unicode, Silnik bazy danych może reprezentować do 65 536 znaków używając UCS-2 lub pełny zakres Unicode (1 114 112 znaków), jeśli używane są znaki dodatkowe. Aby uzyskać więcej informacji na temat włączania znaków dodatkowych, zobacz Znaki dodatkowe.

Alternatywnie, począwszy od programu SQL Server 2019 (15.x), jeśli jest używane sortowanie z włączoną funkcją UTF-8 (_UTF8), wcześniej typy danych innych niż Unicode ( znaków i varchar) stają się typami danych Unicode przy użyciu kodowania UTF-8. Program SQL Server 2019 (15.x) nie zmienia zachowania poprzednio istniejących typów danych Unicode (nchar, nvarchari ntext), które nadal używają kodowania UCS-2 lub UTF-16. Aby uzyskać więcej informacji, zobacz Różnice w przechowywaniu pomiędzy UTF-8 a UTF-16.

Zagadnienia dotyczące unicode

Istotne ograniczenia są skojarzone z typami danych innych niż Unicode. Dzieje się tak, ponieważ komputer inny niż Unicode jest ograniczony do korzystania z jednej strony kodowej. Możesz zauważyć poprawę wydajności dzięki użyciu Unicode, ponieważ wymaga on mniej konwersji stron kodowych. Sortowania Unicode muszą być wybierane indywidualnie na poziomie bazy danych, kolumny lub wyrażenia, ponieważ nie są obsługiwane na poziomie serwera.

Podczas przenoszenia danych z serwera do klienta sortowanie serwera może nie być rozpoznawane przez starsze sterowniki klienta. Taka sytuacja może wystąpić w przypadku przenoszenia danych z serwera Unicode do klienta innego niż Unicode. Najlepszą opcją może być uaktualnienie systemu operacyjnego klienta tak, aby podstawowe sortowania systemu były aktualizowane. Jeśli klient ma zainstalowane oprogramowanie klienckie bazy danych, możesz rozważyć zastosowanie aktualizacji usługi do oprogramowania klienckiego bazy danych.

Napiwek

Możesz również użyć innego sortowania danych na serwerze. Wybierz sortowanie, które odpowiada stronie kodowej na kliencie. Aby użyć kolacji UTF-16, które są dostępne w programie SQL Server (SQL Server 2012 (11.x) i późniejszych), aby ulepszyć wyszukiwanie i sortowanie niektórych znaków Unicode (tylko kolacje systemu Windows), można wybrać jedną z kolacji znaków uzupełniających (_SC) lub jedną z kolacji w wersji 140.

Aby użyć sortowania UTF-8, które są dostępne w programie SQL Server 2019 (15.x) i aby ulepszyć wyszukiwanie i sortowanie niektórych znaków Unicode (tylko sortowania systemu Windows), należy wybrać sortowania z obsługą kodowania UTF-8 (_UTF8).

  • Flagę UTF8 można zastosować do:

    • Sortowania językowe, które obsługują już znaki dodatkowe (_SC) lub rozpoznawanie selektora odmiany (_VSS)
    • Sortowanie binarne BIN2

  • Nie można zastosować flagi UTF8 do:

    • Sortowania językowe, które nie obsługują znaków dodatkowych (_SC) ani rozpoznawania selektorów odmian (_VSS)
    • Sortowania binarne typu "BIN"
    • Sortowania SQL_*

Aby ocenić problemy związane z używaniem typów danych Unicode lub innych niż Unicode, przetestuj swój scenariusz, aby zmierzyć różnice wydajności w środowisku. Dobrym rozwiązaniem jest standaryzacja sortowania używanego w systemach w organizacji oraz wdrażania serwerów i klientów Unicode wszędzie tam, gdzie to możliwe.

W wielu sytuacjach program SQL Server współdziała z innymi serwerami lub klientami, a Organizacja może używać wielu standardów dostępu do danych między aplikacjami i wystąpieniami serwera. Klienci programu SQL Server są jednym z dwóch głównych typów:

  • klientów Unicode korzystających z OLE DB i Open Database Connectivity (ODBC) w wersji 3.7 lub nowszej.
  • klientów nieobsługujących Unicode korzystających z DB-Library i ODBC w wersji 3.6 lub starszej.

Poniższa tabela zawiera informacje o korzystaniu z danych wielojęzycznych z różnymi kombinacjami serwerów Unicode i innych niż Unicode:

Serwer Klient Korzyści lub ograniczenia
Unicode Unicode Ponieważ dane Unicode są używane w całym systemie, ten scenariusz zapewnia najlepszą wydajność i ochronę przed uszkodzeniem pobranych danych. Jest to sytuacja w przypadku obiektów danych ActiveX (ADO), OLE DB i ODBC w wersji 3.7 lub nowszej.
Unicode Inne niż Unicode W tym scenariuszu, szczególnie w przypadku połączeń między serwerem z nowszym systemem operacyjnym i klientem z wcześniejszą wersją programu SQL Server lub starszym systemem operacyjnym mogą występować ograniczenia lub błędy podczas przenoszenia danych na komputer kliencki. Dane Unicode na serwerze dążą do dopasowania do odpowiedniej strony kodowej na kliencie nie obsługującym Unicode w celu konwersji danych.
Inne niż Unicode Unicode Nie jest to idealna konfiguracja do korzystania z danych wielojęzycznych. Nie można zapisać danych Unicode na serwerze innym niż Unicode. Problemy mogą wystąpić, gdy dane są wysyłane do serwerów spoza strony kodowej serwera.
Inne niż Unicode Inne niż Unicode Jest to bardzo ograniczający scenariusz dla danych wielojęzycznych. Można użyć tylko jednej strony kodu.

Znaki dodatkowe

Konsorcjum Unicode przydziela każdemu znakowi unikatowy punkt kodu, który jest wartością z zakresu 0000000–10FFFF. Najczęściej używane znaki mają wartości punktów kodu w zakresie 000000– 00FFFF (65 536 znaków), które mieszczą się w 8-bitowym lub 16-bitowym słowie w pamięci i na dysku. Ten zakres jest zwykle wyznaczony jako podstawowa płaszczyzna wielojęzyczna (BMP).

Jednak Konsorcjum Unicode ustanowiło 16 dodatkowych "płaszczyzn" znaków, każdy o takim samym rozmiarze jak BMP. Ta definicja umożliwia unicode możliwość reprezentowania 1114 112 znaków (czyli 216 * 17 znaków) w zakresie punktów kodu 000000– 10FFFF. Znaki z wartością punktu kodu większą niż 00FFFF wymagają od dwóch do czterech kolejnych 8-bitowych wyrazów (UTF-8) lub dwóch kolejnych 16-bitowych wyrazów (UTF-16). Te znaki znajdujące się poza BMP są nazywane dodatkowych znaków, a dodatkowe kolejne 8-bitowe lub 16-bitowe wyrazy są nazywane par zastępczych. Aby uzyskać więcej informacji na temat dodatkowych znaków, zastępców i par zastępczych, zobacz standardowego standardu Unicode.

Program SQL Server udostępnia typy danych, takie jak nchar i nvarchar do przechowywania danych Unicode w zakresie BMP (000000– 00FFFF), które aparat bazy danych koduje przy użyciu UCS-2.

SQL Server 2012 (11.x) wprowadził nową rodzinę sortowań znaków dodatkowych (_SC), które można stosować z typami danych nchar, nvarchari sql_variant, aby reprezentować pełny zakres znaków Unicode (000000 – 10FFFF). Na przykład: Latin1_General_100_CI_AS_SC lub, jeśli używasz sortowania japońskiego, Japanese_Bushu_Kakusu_100_CI_AS_SC.

Program SQL Server 2019 (15.x) rozszerza obsługę dodatkowych znaków na znaków i varchar typów danych z nowymi sortowaniami z włączonymi formatami UTF-8 (_UTF8). Te typy danych mogą również reprezentować pełny zakres znaków Unicode.

Notatka

Począwszy od programu SQL Server 2017 (14.x), wszystkie nowe sortowania automatycznie obsługują znaki dodatkowe.

Jeśli używasz dodatkowych znaków:

  • Znaki dodatkowe mogą być używane w operacjach porządkowania i porównywania w wersjach sortowania 90 lub nowszych.

  • Wszystkie sortowania w wersji 100 obsługują sortowanie językowe z dodatkowymi znakami.

  • Znaki dodatkowe nie są obsługiwane do użycia w metadanych, takich jak nazwy obiektów bazy danych.

  • Flagę SC można zastosować do:

    • Porównania wersji 90
    • Kolacje wersji 100

  • Nie można zastosować flagi SC do:

    • Sortowania systemu Windows w wersji 80 bez oznaczenia wersji
    • Sortowania binarne BIN lub BIN2
    • Kolejności SQL*
    • Sortowania w wersji 140 (nie potrzebują flagi SC, ponieważ już obsługują znaki uzupełniające)

W poniższej tabeli porównuje się zachowanie niektórych funkcji ciągów i operatorów ciągów podczas używania dodatkowych znaków z sortowaniem uwzględniającym znaki dodatkowe oraz bez niego (SCA).

Funkcja lub operator ciągu Porządkowanie według SCA Bez sortowania SCA
CHARINDEX

LEN
PATINDEX		 Para zastępcza UTF-16 jest liowana jako pojedynczy punkt kodu. Para zastępcza UTF-16 jest liczona jako dwa punkty kodowe.
LEWA

ZASTĄP
ODWROTNOŚĆ
RIGHT
podciąg
STUFF		 Te funkcje traktują każdą parę zastępczą jako pojedynczy punkt kodu i działają zgodnie z oczekiwaniami. Te funkcje mogą dzielić dowolne pary surogatowe i prowadzić do nieoczekiwanych wyników.
NCHAR Zwraca znak odpowiadający określonej wartości punktu kodu Unicode w zakresie 0 — 0x10FFFF. Jeśli określona wartość znajduje się w zakresie 0 — 0xFFFF, zwracany jest jeden znak. W przypadku wyższych wartości zwracany jest odpowiedni zamiennik. Wartość wyższa niż 0xFFFF zwraca NULL zamiast odpowiedniego surogatu.
UNICODE Zwraca punkt kodu UTF-16 w zakresie 0 — 0x10FFFF. Zwraca punkt kodu UCS-2 w zakresie 0 — 0xFFFF.
dopasuj jeden znak wieloznaczny

Symbol wieloznaczny - znak(i), które nie pasują do		 Dodatkowe znaki są obsługiwane dla wszystkich operacji z symbolami wieloznacznymi. Dodatkowe znaki nie są obsługiwane w przypadku tych operacji z symbolami wieloznacznymi. Obsługiwane są inne operatory wieloznaczne.

Obsługa GB18030

GB18030 jest oddzielnym standardem używanym w Chińskiej Republice Ludowej do kodowania chińskich znaków. W GB18030 znaki mogą mieć długość 1, 2 lub 4 bajty. Program SQL Server zapewnia obsługę znaków zakodowanych w GB18030, rozpoznając je, gdy są przesyłane z aplikacji po stronie klienta do serwera, a następnie konwertując i przechowując je natywnie jako znaki Unicode. Po ich zapisaniu na serwerze są traktowane jako znaki Unicode w kolejnych operacjach.

Możesz użyć dowolnej chińskiej kolejności, najlepiej wersji 100 najnowszej. Wszystkie sortowania w wersji 100 obsługują sortowanie językowe z znakami GB18030. Jeśli dane zawierają dodatkowe znaki (pary zastępcze), możesz użyć sortowania SC, które są dostępne w programie SQL Server, aby ulepszyć wyszukiwanie i sortowanie.

Notatka

Upewnij się, że narzędzia klienckie, takie jak SQL Server Management Studio, używają czcionki Dengxian do poprawnego wyświetlania ciągów zawierających znaki zakodowane GB18030.

Obsługa złożonych skryptów

Program SQL Server może obsługiwać wprowadzanie, przechowywanie, zmienianie i wyświetlanie złożonych skryptów. Złożone skrypty obejmują następujące typy:

  • Skrypty, które zawierają kombinację tekstu od prawej do lewej i od lewej do prawej, takich jak kombinacja tekstu arabskiego i angielskiego.
  • Skrypty, których znaki zmieniają kształt w zależności od ich położenia lub w połączeniu z innymi znakami, takimi jak arabski, indyjski i tajski.
  • Języki, takie jak Tajski, które wymagają wewnętrznych słowników rozpoznawania wyrazów, ponieważ nie ma żadnych przerw między nimi.

Aplikacje bazy danych, które współdziałają z programem SQL Server, muszą używać kontrolek obsługujących złożone skrypty. Standardowe kontrolki formularzy Windows utworzone w kodzie zarządzanym obsługują złożone skrypty.

Sortowania japońskie dodane w programie SQL Server 2017

Począwszy od programu SQL Server 2017 (14.x), obsługiwane są nowe japońskie rodziny sortowania z permutacjami różnych opcji (_CS, _AS, _KS, _WSi _VSS), a także _BIN i _BIN2.

Aby wyświetlić listę tych sortowań, możesz wykonać zapytanie dotyczące silnika bazy danych SQL Server.

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

Żadne z nowych ustawień sortowania 140 nie ma (nie wymaga) flagi SC, ponieważ wszystkie nowe ustawienia sortowania mają wbudowaną obsługę dodatkowych znaków.

Te sortowania są obsługiwane w indeksach aparatu bazy danych, tabelach zoptymalizowanych pod kątem pamięci, indeksach magazynu kolumn i natywnie skompilowanych modułach.

Obsługa protokołu UTF-8

Program SQL Server 2019 (15.x) wprowadza pełną obsługę powszechnie używanego kodowania znaków UTF-8 jako kodowania importu lub eksportu oraz sortowania na poziomie bazy danych lub na poziomie kolumny dla danych ciągów. Protokół UTF-8 jest dozwolony w char i varchar typów danych i jest włączony podczas tworzenia lub zmieniania sortowania obiektu na sortowanie, które ma sufiks UTF8. Jednym z przykładów jest zmiana Latin1_General_100_CI_AS_SC na Latin1_General_100_CI_AS_SC_UTF8.

UTF-8 jest dostępny tylko dla sortowań systemu Windows, które obsługują dodatkowe znaki, wprowadzonych w programie SQL Server 2012 (11.x). Typy danych nchar i nvarchar zezwalają tylko na kodowanie UCS-2 lub UTF-16 i pozostają niezmienione.

Usługi Azure SQL Database i Azure SQL Managed Instance obsługują również protokół UTF-8 na poziomie bazy danych i kolumn, natomiast usługa SQL Managed Instance obsługuje tę funkcję również na poziomie serwera.

Różnice w przechowywaniu danych między UTF-8 a UTF-16

Konsorcjum Unicode przydziela każdemu znakowi unikatowy punkt kodu, który jest wartością z zakresu 0000000–10FFFF. W programie SQL Server 2019 (15.x) dostępne są zarówno kodowania UTF-8, jak i UTF-16, aby reprezentować pełny zakres:

  • W przypadku kodowania UTF-8 znaki w zakresie ASCII (000000– 00007F) wymagają 1 bajtu, punkty kodu 0000080 – 0007FF wymagają 2 bajtów, punkty kodu 000800 – 00FFFF wymagają 3 bajtów, a punkty kodu 0010000 – 00100FFFF wymagają 4 bajtów.
  • W przypadku kodowania UTF-16 punkty kodu 000000–00FFFF wymagają 2 bajtów, a punkty kodu 0010000 – 0010FFFF wymagają 4 bajtów.

W poniższej tabeli wymieniono bajty przechowywania kodowania dla każdego przedziału znaków i typu kodowania.

Zakres kodu (szesnastkowy) Zakres kodu (dziesiętny) Bajty pamięci 1 z kodowaniem UTF-8 Bajty pamięci 1 z 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

1Bajty pamięci odnoszą się do długości zakodowanych bajtów, a nie rozmiaru pamięci na dysku. Aby uzyskać więcej informacji na temat rozmiarów przechowywania na dysku, zobacz nchar i nvarchar oraz char i varchar.

2 zakres punktów kodu dla znaków dodatkowych .

Napiwek

Powszechnie uważa się, że w char i varchar lub w nchar i nvarchar, wartość n określa liczbę znaków. Dzieje się tak, ponieważ w przykładzie kolumny char(10) 10 znaków ASCII w zakresie od 0 do 127 można przechowywać przy użyciu sortowania, takiego jak Latin1_General_100_CI_AI, ponieważ każdy znak w tym zakresie używa tylko 1 bajtów. Jednak w char i varcharn definiuje rozmiar ciągu w bajtach (0 – 8000) i w nchar i nvarchar, n definiuje rozmiar ciągu w parach bajtowych (0 – 4000). n nigdy nie definiuje liczby znaków, które mogą być przechowywane.

Wybranie odpowiedniego kodowania Unicode i typu danych może spowodować znaczne oszczędności magazynu lub zwiększyć bieżące zużycie miejsca do magazynowania, w zależności od używanego zestawu znaków. Na przykład w przypadku używania sortowania łacińskiego z włączonym formatem UTF-8, takiego jak Latin1_General_100_CI_AI_SC_UTF8, kolumna znak 10 przechowuje 10 bajtów i może pomieścić 10 znaków ASCII w zakresie od 0 do 127. Ale może zawierać tylko pięć znaków w zakresie 128 - 2047 i tylko trzy znaki w zakresie 2048 - 65535. Dla porównania, ponieważ kolumna nchar(10) przechowuje 10 par bajtów (20 bajtów), może przechowywać 10 znaków w zakresie od 0 do 65535.

Przed podjęciem decyzji, czy używać kodowania UTF-8 lub UTF-16 dla bazy danych lub kolumny, rozważ dystrybucję danych ciągów, które będą przechowywane:

  • Jeśli jest to głównie w zakresie ASCII 0 - 127 (na przykład angielski), każdy znak wymaga 1 bajtu w UTF-8 i 2 bajtów w UTF-16. Korzystanie z protokołu UTF-8 zapewnia korzyści z magazynowania. Zmiana istniejącego typu danych kolumny zawierającej znaki ASCII w zakresie od 0 do 127 z nchar(10) na char(10)oraz użycie sortowania z włączonym UTF-8 przekłada się na 50-procentową redukcję wymagań dotyczących miejsca na dysku. Jest to spowodowane tym, że nchar(10) wymaga 20 bajtów do przechowywania, w porównaniu z char(10), który wymaga 10 bajtów dla tej samej reprezentacji ciągu Unicode.
  • Powyżej zakresu ASCII, prawie wszystkie skrypty oparte na łacinie oraz grecki, cyrylica, koptyjski, ormiański, hebrajski, arabski, syryjski, Tana i N'Ko, wymagają 2 bajtów na każdy znak zarówno w UTF-8, jak i UTF-16. W takich przypadkach nie ma znaczących różnic w przechowywaniu (na przykład między użyciem char lub nchar) dla porównywalnych typów danych.
  • Jeśli jest to głównie pismo wschodnioazjatyckie (takie jak koreańskie, chińskie i japońskie), każdy znak wymaga 3 bajtów w UTF-8 i 2 bajtów w UTF-16. Korzystanie z protokołu UTF-16 zapewnia korzyści z magazynowania.
  • Znaki z zakresu 010000– 10FFFF wymagają 4 bajtów zarówno w formacie UTF-8, jak i UTF-16. W takich przypadkach nie ma różnic w przechowywaniu dla porównywalnych typów danych (na przykład między używaniem char lub nchar).

Aby zapoznać się z innymi zagadnieniami, zobacz Write International Transact-SQL Statements.

Konwertowanie na utF-8

Ponieważ w char i varchar lub w nchar i nvarchar, n definiuje rozmiar magazynu bajtów, a nie liczbę znaków, które można przechowywać, ważne jest określenie rozmiaru typu danych, na który należy przekonwertować. Znaki przekraczające rozmiar mają zostać obcięte.

Rozważmy na przykład kolumnę zdefiniowaną jako nvarchar(100), która przechowuje 180 bajtów znaków japońskich. W tym przykładzie dane kolumny są obecnie kodowane przy użyciu protokołu UCS-2 lub UTF-16, który używa 2 bajtów na znak. Konwertowanie typu kolumny na varchar(200) nie jest wystarczające, aby zapobiec obcinaniu danych, ponieważ nowy typ danych może przechowywać tylko 200 bajtów, ale znaki japońskie wymagają 3 bajtów podczas kodowania w formacie UTF-8. Kolumna musi być zdefiniowana jako varchar(270), aby uniknąć utraty danych przez obcinanie danych.

Dlatego przed przekonwertowaniem istniejących danych na wartość UTF-8 należy wcześniej wiedzieć, jaki jest przewidywany rozmiar bajtów dla definicji kolumny, i odpowiednio dostosować rozmiar nowego typu danych. Zapoznaj się ze skryptem Transact-SQL lub notesem SQL w Data Samples GitHub, który używa funkcji DATALENGTH oraz instrukcji COLLATE, aby określić odpowiednie wymagania dotyczące długości danych dla operacji konwersji UTF-8 w istniejącej bazie danych.

Aby zmienić sortowanie kolumn i typ danych w istniejącej tabeli, użyj jednej z metod opisanych w Ustaw lub Zmień sortowanie kolumn.

Aby zmienić sortowanie bazy danych, zezwalając nowym obiektom na dziedziczenie sortowania bazy danych domyślnie lub zmienić sortowanie serwera, dzięki czemu nowe bazy danych domyślnie dziedziczą sortowanie systemu, zobacz sekcję Powiązane zadania tego artykułu.

Zadanie Artykuł
Opisuje sposób ustawiania lub zmieniania sortowania wystąpienia programu SQL Server. Zmiana sortowania serwera nie zmienia sortowania istniejących baz danych. ustaw lub zmień sortowanie serwera
Opisuje sposób ustawiania lub zmieniania sortowania bazy danych użytkownika. Zmiana sortowania bazy danych nie zmienia sortowania istniejących kolumn tabeli. Ustaw lub zmień porządek sortowania bazy danych
Opisuje sposób ustawiania lub zmieniania sortowania kolumny w bazie danych. Ustawianie lub zmienianie porządku kolumn
Opisuje sposób zwracania informacji sortowania na poziomie serwera, bazy danych lub kolumny. Wyświetl informacje o sortowaniu
Opisuje, jak pisać instrukcje Transact-SQL, które są łatwiej przenośne między różnymi językami lub łatwiejsze w obsłudze wielu języków. Tworzenie międzynarodowych oświadczeń Transact-SQL
Opisuje sposób zmieniania języka komunikatów o błędach i preferencji dotyczących sposobu użycia i wyświetlania danych daty, godziny i waluty. Ustaw język sesji

Powiązana zawartość