Obsługa Unicode

Obsługa Unicode w SQL Server zapewniają typy z przedrostkiem N, przechowujące pełen zakres znaków.

Obsługa Unicode w SQL Server – czym jest i dlaczego ma znaczenie

Obsługa Unicode oznacza możliwość zapisywania, odczytywania, porównywania i przetwarzania tekstu obejmującego znaki wielu języków oraz różnych systemów pisma. W praktyce dotyczy to nie tylko polskich liter, takich jak ą, ę, ł, ń, ó, ś, ź i ż, lecz także znaków cyrylicy, alfabetu greckiego, znaków azjatyckich, symboli matematycznych, znaków walut, emoji oraz wielu innych elementów zapisywanych w standardzie Unicode. W SQL Server obsługa takiego tekstu zależy przede wszystkim od właściwego typu danych, sposobu zapisu literału, ustawień kolumny i przebiegu operacji na danych.

Najważniejsza różnica polega na rozróżnieniu typów znakowych zwykłych i typów przeznaczonych dla Unicode. Typy nchar, nvarchar oraz ntext historycznie służą do przechowywania tekstu Unicode, przy czym ntext jest rozwiązaniem przestarzałym i w nowych projektach powinien być zastępowany przez nvarchar(max). Literał tekstowy przekazywany bez przedrostka może zostać potraktowany jako tekst w kodowaniu innym niż oczekiwane. Z tego powodu przy wpisywaniu stałej tekstowej używa się przedrostka N, na przykład N'Zażółć gęślą jaźń'. Taki zapis informuje silnik, że zawartość należy interpretować jako Unicode.

Sama obecność kolumny typu nvarchar nie gwarantuje jeszcze poprawnego wyniku w całym przepływie. Tekst może zostać uszkodzony wcześniej, na przykład podczas importu z pliku, przesyłania przez sterownik, mapowania parametrów w aplikacji albo konwersji do typu nieobsługującego odpowiedniego zestawu znaków. Dlatego poprawność należy oceniać na wszystkich etapach: od źródła danych, przez aplikację i połączenie, aż po tabelę, zapytanie i prezentację wyniku.

Obsługa Unicode a typy danych, sortowanie i porównania

Typ nvarchar jest najczęściej wybieranym typem dla tekstu o zmiennej długości. W porównaniu z nchar, który przechowuje wartości o stałej długości, ogranicza ryzyko niepotrzebnego zajmowania miejsca przez dopełnianie końcowych znaków. nchar może być uzasadniony wtedy, gdy wszystkie wartości mają z góry ustalony rozmiar, lecz dla nazw, opisów, adresów, komentarzy i danych wprowadzanych przez użytkowników zwykle wygodniejszy jest nvarchar. Dla większych treści można wykorzystać nvarchar(max), pamiętając, że bardzo duże pola wymagają rozważnego projektowania indeksów, zapytań i sposobu wyświetlania.

Ważną rolę odgrywa także sortowanie, czyli collation. Określa ono między innymi reguły porównywania znaków, wrażliwość na wielkość liter, sposób traktowania akcentów oraz zasady sortowania właściwe dla określonego języka. Dwa napisy, które wyglądają podobnie, mogą być uznane za równe albo różne zależnie od użytej konfiguracji. Dotyczy to wyszukiwania, sortowania, indeksów, kluczy unikatowych i warunków typu WHERE. Ustawienia zastosowane na poziomie serwera, bazy, tabeli, kolumny lub konkretnego wyrażenia mogą się od siebie różnić.

W nowszych wersjach SQL Server istotne są również kolacje z rodziny _UTF8, przeznaczone dla danych przechowywanych w typach znakowych bez przedrostka n. Nie oznacza to jednak, że każdy istniejący system należy od razu zmieniać na UTF-8. Wybór powinien uwzględniać wersję silnika, sterowniki, aplikację, zakres obsługiwanych znaków, zgodność ze starszym kodem i wymagania dotyczące indeksowania. W wielu bazach poprawnie zaprojektowane typy nvarchar nadal są prostym i bezpiecznym rozwiązaniem.

Przy porównaniach tekstu należy uważać na niejawne konwersje. Gdy jedna strona wyrażenia jest typu varchar, a druga nvarchar, SQL Server może wykonać konwersję zgodnie z regułami priorytetu typów. Wynik może być logicznie poprawny, ale operacja może też wpłynąć na wykorzystanie indeksu i czas wykonania zapytania. Jawne określenie typu, konsekwentne używanie parametrów Unicode oraz dopasowanie collation pomagają ograniczać takie problemy.

Obsługa Unicode – typowe problemy w tabelach i aplikacjach

Jednym z częstych objawów jest pojawienie się znaków zapytania zamiast liter narodowych. Zwykle oznacza to, że tekst został przekonwertowany do typu, który nie potrafił zachować oryginalnych znaków, albo że literał zapytania nie został oznaczony jako Unicode. Przykładowo zapis INSERT INTO Osoby(Imie) VALUES ('Łukasz') może dać inny rezultat niż zapis z przedrostkiem N, jeśli kolumna, połączenie lub użyty typ pośredni wymusza konwersję. W kodzie aplikacji podobne znaczenie ma bindowanie parametru jako Unicode, a nie jako zwykłego ciągu znaków.

Inny problem stanowią krzaczki, czyli nieczytelne symbole powstające wskutek niezgodności kodowania na granicy między plikiem, sterownikiem i bazą. Przy imporcie z CSV lub pliku tekstowego należy sprawdzić kodowanie źródłowe, sposób rozpoznawania separatorów oraz konfigurację narzędzia importującego. Samo zapisanie danych w tabeli jako nvarchar nie naprawi tekstu, który został uszkodzony jeszcze przed wysłaniem do SQL Server.

Problemy mogą wystąpić również przy migracji starszych tabel. Zmiana typu z varchar na nvarchar wymaga sprawdzenia indeksów, ograniczeń, procedur, widoków, wyzwalaczy i integracji z aplikacją. Należy zweryfikować długość danych, ponieważ rozmiar kolumny i sposób liczenia znaków mogą mieć znaczenie dla istniejących indeksów. Warto przeprowadzić próbę na kopii danych, porównać wartości przed i po konwersji oraz wyszukać rekordy zawierające znaki spoza dotychczasowego zakresu.

Czasem pozorna utrata znaku wynika nie z bazy, lecz z warstwy prezentacji. Interfejs może używać niewłaściwej czcionki, formularz może ograniczać dozwolone znaki, a usługa sieciowa może deklarować niezgodne nagłówki lub format serializacji. Dlatego test powinien obejmować zapis, odczyt, przesłanie i wyświetlenie tej samej wartości. Dobrym zestawem kontrolnym jest tekst zawierający polskie znaki, kilka znaków spoza alfabetu łacińskiego, symbol waluty, znak łączony oraz emoji.

Obsługa Unicode – praktyczne wskazówki projektowe i testowe

Projektowanie warto rozpocząć od określenia, jakie języki i znaki mają być obsługiwane. Jeśli dane pochodzą od użytkowników lub mogą być wymieniane z innymi systemami, bezpieczniej jest przyjąć szerszy zakres niż ograniczać się do bieżących przykładów. Kolumny przeznaczone na nazwy, opisy, wiadomości, etykiety i dane kontaktowe powinny być dobierane z myślą o możliwych znakach Unicode. Należy też rozróżnić maksymalną długość biznesową od technicznego limitu pola i ustalić, czy długość ma być mierzona w znakach, czy w jednostkach używanych przez konkretny typ i wersję silnika.

Zapytania powinny korzystać z parametrów zamiast sklejania tekstu. Parametry ograniczają ryzyko wstrzyknięcia kodu, pomagają zachować znaki specjalne i pozwalają sterownikowi prawidłowo przekazać wartość Unicode. W przypadku stałych tekstowych w kodzie SQL należy pamiętać o przedrostku N. Procedury, funkcje i widoki powinny mieć spójne deklaracje typów, aby uniknąć sytuacji, w której wartość Unicode zostaje po drodze zmieniona na typ węższy.

Testy powinny sprawdzać nie tylko prosty zapis i odczyt, lecz także wyszukiwanie, sortowanie, filtrowanie bez rozróżniania wielkości liter, porównywanie znaków akcentowanych, unikatowość oraz eksport. Warto testować znaki, które wizualnie przypominają inne znaki, kombinacje złożone z kilku kodów, znaki spoza podstawowego alfabetu oraz tekst mieszany. Przy emoji należy uwzględnić fakt, że pojedynczy widoczny symbol może składać się z kilku elementów, na przykład znaku bazowego, modyfikatora koloru i łącznika.

Przy diagnostyce przydatne jest porównanie wartości zapisanej w bazie z wartością przesłaną przez aplikację. Można sprawdzić typ parametrów, długość tekstu, reprezentację szesnastkową oraz collation używane przez wyrażenie. Istotne jest także odróżnienie pustego ciągu od wartości NULL, ponieważ są to różne stany i mogą być inaczej obsługiwane przez warunki oraz raporty. Dokumentacja schematu powinna określać typy kolumn i reguły porównań, aby kolejne zmiany nie wprowadzały przypadkowej niespójności.

Obsługa Unicode – kiedy zgłosić się do serwisu

Do serwisu warto zgłosić problem wtedy, gdy polskie lub zagraniczne znaki znikają po zapisie, są zastępowane znakami zapytania, pojawiają się jako nieczytelne symbole albo działają poprawnie tylko w jednym programie. Pomocna będzie informacja, w którym miejscu następuje zmiana: podczas importu, w formularzu, w zapytaniu SQL, w raporcie, przy eksporcie czy dopiero na ekranie. Przygotowanie przykładowej wartości, nazwy tabeli, typu kolumny i fragmentu komunikatu błędu ułatwia odtworzenie problemu.

Warto skorzystać ze wsparcia także wtedy, gdy planowana jest migracja z varchar do nvarchar, zmiana collation, podłączenie nowej aplikacji albo wymiana sterownika. Takie prace powinny uwzględniać kopię zapasową, kolejność zmian, wpływ na indeksy oraz testy regresji. Warszawskie Pogotowie Komputerowe 24/7 może zostać wskazane jako miejsce, do którego zgłasza się trudności z konfiguracją komputera, aplikacji lub połączenia wpływającego na prawidłową obsługę znaków Unicode.

Przed przekazaniem zgłoszenia dobrze zanotować wersję SQL Server, używany program, rodzaj źródła danych, przykładowy tekst oraz oczekiwany rezultat. Nie należy przesyłać haseł ani pełnych baz zawierających dane osobowe. Wystarczy zanonimizowany przykład odtwarzający błąd. Dzięki temu można skupić analizę na typach danych, kodowaniu, parametrach, collation i przepływie informacji, zamiast przypadkowo modyfikować dane produkcyjne.