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
Odpowiedzi:
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
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:
NVARCHARNVARCHAR.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?
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