SQL Server 2005/2008 UTF-8 Sortowanie / zestaw znaków

16

Nie mogę znaleźć opcji bezpośrednio ustawionych UTF-8ponownie Collations/Charsetsw SQL Server 2005/2008, tak jak to możliwe w innych silnikach SQL, ale w SQL Server 2005/2008 są tylko sortowania w języku łacińskim i SQL.

Czy istnieje opcja wymuszenia / zainstalowania tych zestawień / zestawów znaków w silniku SQL Server (dla obu wersji) 2005/2008 w systemie operacyjnym Win2008

mKorbel
źródło

Odpowiedzi:

13

Nie, nie ma. SQL Server nie obsługuje UTF-8.

Musisz zdefiniować kolumny jako nvarchar / nchar, jeśli chcesz danych Unicode. Uwaga: wewnętrznie SQL Server przechowuje to jako UCS-2.

Zauważ, że zwrócił się o to Ben z MS na Connect i jest starszy artykuł z bazy wiedzy . I trochę informacji na tym blogu

gbn
źródło
6
dodatkowo, jeśli zamierzasz dopasować tekst na nvarchar ze znakami obcymi, musisz dopasować ciąg sformatowany za pomocą N przed łańcuchem (np. N'οἰκονόμον).
swasheck,
Czy to zachowanie zmieniło się w jakiejkolwiek najnowszej wersji serwera SQL?
Seiyria
@Seiyria: nie, to samo zachowanie
gbn
Każdy, kto znajdzie drogę do tej odpowiedzi, przejdź do strony MS Connect i głosuj, że MS obsługuje UTF-8 na serwerze SQL. Dzięki: D
DarcyThomas
@DarcyThomas To staje się rzeczywistością w SQL Server 2019, choć nadal nie jest to coś, z czego należy korzystać, chyba że jest to wyraźnie potrzebne. Szczegóły znajdują się w mojej odpowiedzi .
Solomon Rutzky
2

Nie można zainstalować UTF-8 jako zestawu znaków, ponieważ nie jest to zestaw znaków, to kodowanie.

Jeśli chcesz przechowywać tekst Unicode, używasz nvarchartypu danych.

Jeśli chcesz przechowywać tekst zakodowany za pomocą UTF-8, zapisujesz go jako dane binarne ( varbinary).

Guffa
źródło
1

Począwszy od SQL Server 2019 (obecnie w wersji beta / „Community Tech Preview”), dostępna jest natywna obsługa UTF-8 za pośrednictwem nowej serii zestawień UTF-8. JEDNAK możliwość korzystania z UTF-8 nie oznacza, że ​​powinieneś. Istnieją wyraźne wady korzystania z UTF-8, takie jak:

  1. Tylko pierwsze 128 punktów kodowych ma 1 bajt (tj. Standardowy 7-bitowy zestaw ASCII)
  2. Następne prawie 2000 punktów kodowych to 2 bajty, stąd brak oszczędności miejsca w porównaniu do UTF-16 / NVARCHAR
  3. Pozostałe 63k punktów kodowych w BMP (tj. Zakres U + 0800 - U + FFFF) to wszystkie 3 bajty, stąd 1 bajt większy niż ten sam znak w UTF-16 / NVARCHAR.
  4. Wystarczy powiedzieć: znaki uzupełniające mają 4 bajty w obu kodowaniach, więc nie ma tutaj różnicy spacji
  5. Podczas gdy możesz zaoszczędzić miejsce za pomocą UTF-8, istnieje bardzo duża szansa, że ​​zrobisz to za sprawą wydajności.

Tak naprawdę sprowadza się to do tego: UTF-8 jest formatem pamięci masowej, który umożliwia systemom 8-bitowym (które zwykle zostały zaprojektowane w oparciu o ASCII i ASCII Extended - strony kodowe) korzystanie z Unicode bez zepsucia czegokolwiek i nie wymagając żadnej modyfikacji istniejącej pliki w celu utrzymania działania. UTF-8 jest wspaniały dla systemów plików i sieci, ale dane przechowywane w SQL Server nie są takie same. Fakt, że dane, które akurat znajdują się głównie (lub całkowicie) w standardowym zakresie ASCII, wymagają mniej miejsca niż te same dane, gdy są przechowywane jako UTF-16 /, NVARCHARjest efektem ubocznym. Jasne, to efekt uboczny, który może okazać się przydatny, ale decyzję tę musi podjąć ktoś, kto rozumie zarówno dane, jak i konsekwencje / wady tej decyzji. To jestnie jest to funkcja do użytku ogólnego.

Ponadto głównym przypadkiem użycia dla UTF-8 (w SQL Server) jest kod aplikacji już korzystający z UTF-8, być może już z innym RDBMS, który go obsługuje, i nie ma potrzeby ani możliwości aktualizacji kodu aplikacji / schematu DB używać NVARCHARtypów danych (dla tabel, zmiennych, parametrów itp.) lub poprzedzać literały ciągów wielkimi literami „N”. Cel jest taki sam, jak przyczyna istnienia UTF-8: włącz kod aplikacji do korzystania z Unicode bez zmiany ogólnej struktury lub renderowania istnienia niepoprawnych danych. Jeśli to opisuje twoją sytuację, użyj UTF-8, ale pamiętaj, że wciąż jest z nim kilka błędów / problemów.

Jeśli nie ma wyraźnej potrzeby, aby Unicode działał bez użycia NVARCHARliterałów łańcuchowych z literami „N” z prefiksem, wówczas jedynym innym scenariuszem, w którym UTF-8 jest zaletą, jest DUŻO w większości standardowych danych ASCII, które muszą uwzględniać Znaki Unicode, a ty używasz NVARCHAR(MAX)(co oznacza, że ​​kompresja danych nie będzie działać), a tabela jest często aktualizowana (więc Indeks klastrowanego magazynu kolumn prawdopodobnie nie pomoże).

Aby uzyskać szczegółowe informacje, zobacz mój post:

Natywne wsparcie UTF-8 w SQL Server 2019: Zbawiciel czy fałszywy prorok?

Solomon Rutzky
źródło
0

W moim przypadku musiałem wyświetlać znaki arabskie, a moja baza danych programowania była w 2014 roku, tutaj wszystko działało dobrze. Tutaj w zapytaniu mogłem zobaczyć znaki arabskie, a moje zestawienie to SQL_Latin1_General_CP1256_CI_AS

Ale moja produkcja była w SQL Server 2008 i ostatecznie nie obsługiwała zestawu znaków UTF-8. Tutaj mogłem zobaczyć wszystko ??????????? ponieważ UTF-8 nie jest obsługiwany w SQL 2008.

Wszystko, co zrobiłem, zmieniło wszystkie varchar na nvarchar i poprawnie widziałem arabski znak. Zmieniam także sortowanie bazy danych w 2008 r. Na SQL_Latin1_General_CP1256_CI_AS

Halim
źródło