Unicode i obsługa języków w SQL Server zapewniają typy z przedrostkiem N, przechowujące pełen zakres znaków.
Typy danych Unicode w SQL Server
W Microsoft SQL Server tekst przeznaczony do przechowywania znaków Unicode zapisuje się przede wszystkim w typach nchar i nvarchar. Litera „n” oznacza wariant Unicode. Typ nchar przechowuje wartości o stałej długości, natomiast nvarchar służy do wartości o długości zmiennej. W definicji kolumny można określić długość od 1 do 4000 jednostek dla nchar i nvarchar. Wariant nvarchar(max) pozwala przechowywać znacznie większe wartości tekstowe, do maksymalnego rozmiaru obsługiwanego przez SQL Server.
SQL Server przechowuje dane nchar, nvarchar i ntext w reprezentacji UTF-16. Dla znaków mieszczących się w podstawowej płaszczyźnie wielojęzycznej często wystarcza jedna 16-bitowa jednostka kodu, ale część znaków wymaga pary zastępczej, czyli dwóch jednostek UTF-16. Z tego powodu liczba jednostek przechowywanych w kolumnie nie zawsze jest równa liczbie widocznych znaków. Ma to znaczenie przy ustalaniu długości pól, stosowaniu funkcji tekstowych oraz sprawdzaniu, czy cały symbol, na przykład wybrane emoji, został zapisany poprawnie.
Litera N przy stałych tekstowych
Sam wybór kolumny typu Unicode nie wystarcza, jeżeli tekst jest zapisany bezpośrednio w zapytaniu. Literał Unicode w języku Transact-SQL powinien mieć przedrostek N, na przykład N'Łódź — العربية — 日本語'. Przedrostek informuje SQL Server, że stała tekstowa ma być interpretowana jako Unicode. Bez niego literał jest traktowany jako tekst nieunikodowy i może zostać przekonwertowany zgodnie z bieżącą stroną kodową, zanim trafi do kolumny nvarchar. W efekcie znak niedostępny w tej stronie kodowej może zostać zastąpiony znakiem zapytania albo utracić pierwotną wartość.
Przedrostek N należy stosować również w warunkach wyszukiwania, instrukcjach INSERT i UPDATE, wartościach domyślnych oraz parametrach budowanych w kodzie aplikacji, gdy tekst zawiera znaki spoza podstawowego zestawu ASCII. Przykładowe zapytanie INSERT INTO Osoby (Imie) VALUES (N'Żaneta') zachowuje polską literę „Ż”, o ile kolumna Imie ma odpowiedni typ i długość. Parametry zapytań są preferowanym sposobem przekazywania tekstu z aplikacji, ponieważ ograniczają niejawne konwersje i pozwalają sterownikowi przekazać wartość w typie zgodnym z jej przeznaczeniem.
Sortowanie, porównywanie i wybór długości
Typ Unicode określa sposób przechowywania tekstu, ale nie definiuje samodzielnie reguł sortowania ani porównywania. Za te operacje odpowiada kolacja, ustawiana między innymi dla serwera, bazy danych, kolumny lub konkretnego wyrażenia. Kolacja określa alfabet, kolejność sortowania oraz wrażliwość na wielkość liter, akcenty, kanał pisma czy szerokość znaków, zależnie od używanej odmiany. Dwie wartości zapisane w kolumnach nvarchar mogą więc być porównywane inaczej, jeżeli kolumny mają różne kolacje.
Przy projektowaniu tabeli trzeba dobrać długość do rzeczywistej zawartości, a nie tylko do liczby znaków widocznych na ekranie. Dla tekstu o zmiennej długości zwykle stosuje się nvarchar, ponieważ nie rezerwuje pełnego rozmiaru dla każdej wartości tak jak nchar. Zbyt krótka kolumna może powodować obcięcie danych lub błąd podczas zapisu, natomiast bezrefleksyjne używanie nvarchar(max) utrudnia kontrolę modelu danych i może wpływać na pracę indeksów. Kolumny ntext są starszym rozwiązaniem; dla nowych tabel należy wybierać nvarchar(max), ponieważ typy ntext, text i image są wycofywane z dalszego rozwoju SQL Server.
Testowanie znaków w aplikacji korzystającej z SQL Server
Problemy z językami narodowymi często powstają na granicy aplikacji i bazy, a nie w samym mechanizmie przechowywania. Podczas diagnostyki należy sprawdzić typ kolumny, jej długość, kolację oraz typ parametrów wysyłanych przez sterownik. Warto wykonać test zawierający znaki z kilku grup, na przykład polskie „ąęłńóśźż”, cyrylicę, alfabet grecki, znaki CJK i symbol spoza podstawowej płaszczyzny Unicode. Następnie trzeba odczytać wartość z SQL Server i porównać ją z tekstem wejściowym, zwracając uwagę na znaki zastąpione znakiem zapytania, nieprawidłową kolejność sortowania oraz różnice w wyszukiwaniu.
Przy analizie zapytań pomocne jest jawne rzutowanie do typu Unicode, na przykład CAST(@tekst AS nvarchar(4000)), oraz sprawdzenie długości za pomocą LEN i DATALENGTH. Funkcja LEN pomija końcowe spacje, a DATALENGTH zwraca liczbę bajtów przeznaczonych na zapis wartości, dlatego wyniki tych funkcji nie są równoważne. Trzeba także odróżnić problem kodowania od problemu czcionki: jeżeli SQL Server zwraca prawidłowe dane, lecz ekran pokazuje kwadraty lub puste symbole, przyczyną może być brak glifu w używanej czcionce albo błąd w warstwie interfejsu.
W środowiskach korzystających z nowszych wersji SQL Server można spotkać także kolacje UTF-8 dla typów char i varchar. Nie zmienia to jednak podstawowej zasady dla kolumn Unicode opartych na nchar i nvarchar: dane oraz literały muszą być przekazywane ze świadomie dobranym typem, a poprawność należy potwierdzić testem obejmującym wszystkie języki obsługiwane przez konkretną aplikację.
