it-swarm.dev

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

Nie mogę znaleźć opcji bezpośrednio ustawionych UTF-8 rellated Collations/Charsets w SQL Server 2005/2008, tak jak można ustawić 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

16
mKorbel

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 poprosił o to Ben MS na Connect i istnieje starszy artykuł z KB . I trochę informacji także na tym blog

13
gbn

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żyj typu danych nvarchar.

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

2
Guffa

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 oznacza 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 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)) 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 umożliwiającym włączenie systemów 8-bitowych (które zwykle były zaprojektowane w oparciu o ASCII i ASCII Rozszerzone - strony kodowe) do korzystania z Unicode bez niszczenia czegokolwiek lub wymagania modyfikacji istniejących plików w celu utrzymania działania UTF-8 jest wspaniały dla systemów plików i sieci, ale dane są przechowywane wewnątrz SQL Server nie jest tym. Fakt, że dane, które akurat akurat przypadają, to głównie (lub całkowicie) w ramach standardowego ASCII zakres wymaga mniej miejsca niż te same dane, gdy przechowywane jako UTF-16/NVARCHAR to efekt uboczny. Jasne, to efekt uboczny, który może okazać się przydatny, ale decyzję tę musi podjąć ktoś, kto rozumie zarówno dane i konsekwencje/wady tej decyzji. To jest nie funkcja do ogólnego użytku.

Ponadto głównym przypadkiem użycia dla UTF-8 (w SQL Server) jest kod aplikacji, który już korzysta 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ć NVARCHAR typów danych (dla tabel, zmiennych, parametrów itp.) lub poprzedzać literały łańcuchowe 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, że ​​dane są nieprawidłowe. 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 NVARCHAR lub literałów ciągowych z wielkimi literami „N”, wówczas jedynym innym scenariuszem, w którym UTF-8 jest zaletą, jest DUŻO mostly standard ASCII dane, które muszą zezwalać na 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:

Natywna obsługa UTF-8 w SQL Server 2019: Zbawiciel czy fałszywy prorok?

1
Solomon Rutzky

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

0
Halim