Typy danych a kodowanie języka — tylko typy z przedrostkiem N przechowują pełen zakres znaków Unicode.
Jak SQL Server przechowuje znaki w typach danych
W SQL Server wybór typu znakowego wpływa na zakres znaków, sposób kodowania wartości oraz ilość miejsca zajmowanego przez dane. Typy char, varchar i text są historycznie związane ze stroną kodową określoną przez sortowanie, czyli collation. W takim przypadku pojedynczy znak jest reprezentowany zgodnie z kodowaniem przypisanym do danej strony kodowej. Jeżeli strona kodowa nie zawiera konkretnego znaku, zapis może zakończyć się jego utratą, zastąpieniem innym symbolem albo błędną konwersją.
Typy z przedrostkiem n — nchar, nvarchar i ntext — służą w SQL Server do przechowywania danych Unicode. Wartości te są przechowywane w kodowaniu UTF-16. Dzięki temu mogą obejmować znaki używane między innymi w językach polskim, greckim, cyrylicy, arabskim, chińskim czy japońskim, a także symbole spoza podstawowej płaszczyzny Unicode za pomocą par zastępczych. Litera N przed stałym tekstem, na przykład N'Łódź', informuje SQL Server, że literał ma być traktowany jako Unicode.
Stwierdzenie, że tylko typy z przedrostkiem n przechowują pełen zakres Unicode, opisuje podstawową i przez wiele lat standardową zasadę SQL Server, ale wymaga doprecyzowania dla nowszych wersji. Od SQL Server 2019 dostępne są sortowania z sufiksem _UTF8, które pozwalają typom char i varchar przechowywać dane Unicode w kodowaniu UTF-8. W praktyce trzeba więc sprawdzić wersję silnika, definicję sortowania i typ kolumny. Bez sortowania UTF-8 bezpiecznym wyborem dla pełnego zakresu Unicode pozostaje typ n.
Różnice między nchar, nvarchar oraz dawnymi typami tekstowymi
nchar jest typem o stałej długości. Jeżeli kolumna ma definicję nchar(20), SQL Server rezerwuje miejsce dla 20 jednostek kodowania UTF-16, a krótszą wartość dopełnia spacjami. Typ ten pasuje do danych rzeczywiście mających stałą długość, na przykład kodów o ustalonym formacie. Nie jest dobrym wyborem dla opisów, nazw ulic czy komunikatów o zmiennej długości, ponieważ może powodować niepotrzebne zużycie miejsca.
nvarchar przechowuje tekst Unicode o zmiennej długości. Definicja nvarchar(100) określa maksymalną liczbę jednostek kodowania, a nie zawsze liczbę widocznych znaków. Zwykłe znaki zajmują zazwyczaj jedną jednostkę UTF-16, natomiast część znaków, w tym wiele emoji i symboli z dodatkowych płaszczyzn Unicode, wymaga dwóch jednostek. nvarchar(max) służy do większych treści, ale nie powinien być używany automatycznie dla każdej krótkiej wartości, ponieważ utrudnia kontrolę rozmiaru danych i może wpływać na sposób wykonywania zapytań.
ntext jest starszym typem przeznaczonym do dużych danych tekstowych i został oznaczony przez Microsoft jako przestarzały. W nowych tabelach należy stosować nvarchar(max). Analogicznie, dla starszych typów text i image istnieją współczesne odpowiedniki oparte na typach varchar(max) oraz varbinary(max). Zmiana typu nie jest wyłącznie zmianą nazwy: może wymagać sprawdzenia indeksów, procedur, funkcji, sterowników i kodu aplikacji, który przekazuje parametry jako Unicode albo jako tekst zależny od strony kodowej.
Literały, parametry i konwersje bez utraty polskich znaków
W zapytaniu SQL Server literał tekstowy zapisany bez prefiksu N jest początkowo interpretowany jako tekst niebędący Unicode. Dlatego przy kolumnie nvarchar poprawna forma to na przykład WHERE Nazwa = N'Żółć'. Pominięcie prefiksu może spowodować utratę znaków już podczas interpretacji literału, zanim wartość zostanie porównana z kolumną Unicode. Samo rzutowanie później na nvarchar nie zawsze odtworzy znak, który został wcześniej zastąpiony.
Podobna zasada dotyczy parametrów przekazywanych z aplikacji. Parametr przeznaczony dla kolumny nvarchar powinien być deklarowany i wysyłany jako Unicode. W przeciwnym razie sterownik lub warstwa dostępu do danych może wykonać konwersję przez lokalną stronę kodową. Objawem bywają znaki zapytania zamiast liter, nieprawidłowe sortowanie albo wyszukiwanie, które działa dla części danych, lecz nie znajduje wartości zawierających diakrytykę.
Do kontroli typu i wyniku konwersji można użyć jawnych wyrażeń, takich jak CAST i CONVERT, ale sama konwersja nie rozwiązuje problemu niezgodnego kodowania źródłowego. Trzeba także rozróżnić przechowywanie znaków od porównywania i sortowania. Collation określa między innymi reguły porządku alfabetycznego, czułość na wielkość liter oraz traktowanie akcentów. Dwie kolumny przechowujące ten sam znak Unicode mogą dawać różne wyniki porównań, jeśli używają innych sortowań. Przy diagnozie należy zatem sprawdzić definicję kolumny, sortowanie bazy i kolumny, typ parametrów oraz kodowanie po stronie aplikacji.
Kontrola kodowania podczas pracy laptopa i komputera
Błędy związane z typami znakowymi często ujawniają się jako problem aplikacji, choć ich przyczyną jest niespójność kilku warstw: formularza, sterownika, zapytania, schematu bazy i eksportu danych. Warto wykonać test z tekstem zawierającym polskie litery, na przykład „Zażółć gęślą jaźń”, a następnie sprawdzić wartość bezpośrednio w bazie i w interfejsie programu. Jeżeli tekst jest poprawny w tabeli, lecz błędny na ekranie, problem znajduje się poza samym typem kolumny. Jeżeli jest błędny już po zapisie, należy przeanalizować parametr, literał lub konwersję.
Przy diagnozowaniu komputera można również sprawdzić ustawienia regionalne systemu, kodowanie plików importowanych i eksportowanych oraz wersję sterownika używanego przez aplikację. Plik zapisany w UTF-8, UTF-16 i w lokalnej stronie kodowej nie jest równoważny tylko dlatego, że zawiera ten sam widoczny tekst. Szczególnej uwagi wymagają stare programy korzystające z typów varchar oraz nowe aplikacje, które zakładają Unicode. Zmiana kolumny na nvarchar bez sprawdzenia całego przepływu może usunąć jeden błąd, ale pozostawić niepoprawny import lub uszkodzone dane w kopiach roboczych.
Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, a w ramach diagnostyki oprogramowania można ustalić, czy nieprawidłowe polskie znaki wynikają z ustawień systemu, aplikacji, sterownika bazy danych czy samej definicji danych. W praktyce prawidłowa diagnoza wymaga zachowania oryginalnych plików i kopii danych oraz testowania zapisu na kopii roboczej, aby nie nadpisać wartości, których nie da się później odtworzyć.
