Obsługa znaków narodowych

Obsługa znaków narodowych wymaga zgodnej kolacji przy typach nie-Unicode albo użycia NVARCHAR.

Obsługa znaków narodowych w bazach danych i aplikacjach

Obsługa znaków narodowych obejmuje prawidłowe przechowywanie, przesyłanie, wyświetlanie i wyszukiwanie liter występujących w różnych językach. Dotyczy to między innymi polskich znaków: ą, ć, ę, ł, ń, ó, ś, ź i ż, a także znaków używanych w języku czeskim, niemieckim, francuskim, greckim, ukraińskim, chińskim czy arabskim. Problem nie ogranicza się do wyglądu tekstu na ekranie. Nieprawidłowe ustawienia mogą powodować zmianę znaków na pytajniki, kwadraty albo przypadkowe symbole, błędne sortowanie nazw oraz niepoprawne działanie wyszukiwarki.

W praktyce poprawna obsługa znaków narodowych wymaga zgodności całego łańcucha przetwarzania danych. Znaczenie ma sposób zapisania tekstu w pliku, kodowanie połączenia z bazą danych, typ kolumny, ustawienia serwera, konfiguracja programu oraz czcionka używana w interfejsie. Jeżeli choć jeden z tych elementów nie obsługuje danego zestawu znaków, dane mogą zostać uszkodzone jeszcze przed ich wyświetleniem. Późniejsze przełączenie kodowania nie zawsze przywraca pierwotną treść, ponieważ błędnie zapisane znaki mogły zostać bezpowrotnie zastąpione innymi wartościami.

Znaki narodowe są częścią zwykłych danych użytkowych. Pojawiają się w imionach i nazwiskach, adresach, nazwach miejscowości, opisach produktów, tytułach dokumentów, komentarzach, wiadomościach oraz nazwach plików. Z tego powodu problem może ujawnić się zarówno w niewielkim programie biurowym, jak i w rozbudowanym systemie obsługującym wiele źródeł danych. Sama obecność polskich liter w jednym formularzu nie oznacza jeszcze, że cała aplikacja jest przygotowana do ich bezpiecznego przetwarzania.

Obsługa znaków narodowych a kodowanie tekstu i typ danych

Najczęściej spotykane trudności wynikają z pomieszania dwóch zagadnień: kodowania znaków oraz sposobu porównywania tekstu. Kodowanie określa, jak znaki są reprezentowane w pamięci lub w pliku. Z kolei reguły porównywania, często określane jako sortowanie językowe, wpływają na kolejność wyników, rozpoznawanie wielkości liter i działanie wyszukiwania. Dwa systemy mogą przechowywać ten sam tekst bez jego uszkodzenia, lecz zwracać inne wyniki sortowania albo inaczej traktować litery o podobnym zapisie.

W starszych rozwiązaniach wykorzystywano lokalne, ograniczone zestawy znaków. Mogły one wystarczać dla jednego języka, lecz nie obejmowały wszystkich alfabetów i symboli używanych obecnie. Przy takim podejściu polska litera może być interpretowana inaczej na różnych komputerach, szczególnie gdy plik został utworzony w jednym środowisku, a otwarty w innym. Trudność zwiększa się podczas importowania danych z arkusza, pliku tekstowego, formularza internetowego lub urządzenia pracującego z odmienną konfiguracją regionalną.

Współczesnym rozwiązaniem jest Unicode, czyli wspólny standard przypisujący znakom jednoznaczne wartości. W bazach danych tekst wielojęzyczny powinien być zapisywany w typach przeznaczonych do danych Unicode, takich jak NVARCHAR w środowiskach, które stosują rozróżnienie między zwykłym tekstem a tekstem Unicode. Sam wybór typu nie wystarcza, jeśli połączenie z bazą, sterownik lub zapytanie przekazuje dane w innym formacie. Należy więc sprawdzić zgodność na każdym etapie, od pola formularza po zapis w tabeli i późniejszy odczyt.

Różnice można zauważyć także podczas porównywania wartości. W zależności od ustawień tekst „Zielinski” i „Zieliński” może być uznany za identyczny, podobny albo zupełnie różny. To samo dotyczy wielkich i małych liter oraz znaków diakrytycznych. W jednych zastosowaniach pożądane jest wyszukiwanie tolerujące brak akcentu, a w innych wymagana jest ścisła zgodność zapisu. Reguły powinny zostać dobrane do przeznaczenia danych, ponieważ przypadkowa zmiana ustawień może wpłynąć na logowanie, raporty, sortowanie klientów i działanie filtrów.

Typowe problemy z obsługą znaków narodowych

Jednym z typowych objawów jest wyświetlanie pytajników zamiast liter. Zwykle oznacza to, że tekst został zapisany w formacie, który nie potrafił przedstawić danego znaku, albo że został przekazany przez niezgodne połączenie. Innym objawem są tak zwane krzaczki, czyli ciągi pozornie przypadkowych znaków powstające przy otwarciu pliku w niewłaściwym kodowaniu. Jeżeli taki plik zostanie następnie zapisany bez sprawdzenia treści, błędny zapis może utrwalić się w kopii roboczej lub bazie danych.

Często występuje również nieprawidłowe sortowanie. Nazwiska zawierające ą, ć, ł lub ż mogą pojawiać się w nieoczekiwanych miejscach, ponieważ zastosowane reguły porównywania nie odpowiadają językowi danych. Wyszukiwanie może nie zwracać istniejących rekordów, mimo że wpisany tekst wygląda podobnie. Problem może dotyczyć także unikatowości wartości. Dwa wpisy różniące się tylko znakiem diakrytycznym mogą zostać potraktowane jako duplikaty albo jako dwa odrębne rekordy, zależnie od konfiguracji.

Do osobnej grupy należą błędy na granicy systemów. Formularz internetowy może poprawnie przyjmować polskie znaki, ale moduł zapisujący dane może używać innego kodowania. Program może prawidłowo czytać bazę, natomiast eksport do pliku CSV może tracić część znaków. Także wiadomość e-mail, dokument tekstowy, kopia zapasowa lub integracja z zewnętrzną usługą może wprowadzić zmianę. Diagnoza powinna zatem obejmować nie tylko ekran, na którym pojawia się błąd, lecz także źródło danych, sposób transportu oraz miejsce docelowego zapisu.

Problemy bywają mylone z awarią czcionki. Brak odpowiedniego kroju pisma może spowodować wyświetlenie pustego prostokąta, lecz nie musi oznaczać uszkodzenia danych. Jeżeli po skopiowaniu tekstu do innego programu znaki są prawidłowe, przyczyny należy szukać w interfejsie lub czcionce. Jeżeli natomiast tekst jest błędny już w pliku albo w bazie, sama zmiana wyglądu nie rozwiąże problemu.

Ryzyko rośnie podczas migracji danych. Przeniesienie tabel do nowszej wersji programu, zmiana systemu operacyjnego, import archiwum albo konwersja plików może ujawnić błędy, które wcześniej pozostawały niezauważone. Przed taką operacją zaleca się wykonanie kopii, ustalenie kodowania źródłowego i docelowego oraz porównanie próbek zawierających różne rodzaje znaków. Szczególnej uwagi wymagają polskie litery, znaki cyrylicy, symbole walut, cudzysłowy typograficzne i znaki spoza podstawowego alfabetu łacińskiego.

Praktyczne wskazówki dla obsługi znaków narodowych

• Przy tworzeniu nowej bazy lub aplikacji należy od początku przyjąć Unicode w warstwie danych, formularzy, plików i komunikacji między modułami.
• Przy imporcie pliku tekstowego należy ustalić jego rzeczywiste kodowanie, a nie wybierać ustawienia przypadkowo na podstawie samego rozszerzenia pliku.
• Warto przetestować zapis i odczyt pełnego zestawu znaków używanych przez odbiorców, zamiast ograniczać próbę do pojedynczej polskiej litery.
• Należy sprawdzić, czy sterownik oraz biblioteka używana przez aplikację przesyłają tekst jako Unicode i czy zapytania nie wymuszają starszego formatu.
• Reguły sortowania i porównywania powinny być opisane przed wdrożeniem, zwłaszcza gdy dane są filtrowane, deduplikowane lub wykorzystywane do logowania.
• Przy eksporcie do CSV, TXT lub innych plików należy przekazać odbiorcy informację o kodowaniu albo użyć formatu, który przechowuje tę informację w sposób jednoznaczny.
• Nie powinno się naprawiać uszkodzonych znaków przez ręczne podmienianie symboli w całej bazie bez wcześniejszego ustalenia, na którym etapie nastąpiła zmiana.
• Po zmianie konfiguracji należy sprawdzić nie tylko nowe wpisy, ale też stare rekordy, wyszukiwanie, sortowanie, raporty, wydruki i eksport danych.

Pomocne jest przygotowanie niewielkiego zestawu testowego. Powinny znaleźć się w nim imiona i nazwiska z polskimi znakami, nazwy miejscowości, tekst zawierający wielkie i małe litery, kilka języków oraz symbole specjalne. Taki zestaw pozwala porównać zachowanie poszczególnych etapów i szybciej wskazać miejsce, w którym dochodzi do błędu. W przypadku plików dobrze jest zachować kopię przed konwersją, aby można było wrócić do danych źródłowych.

Kiedy zgłosić obsługę znaków narodowych do serwisu

Zgłoszenie problemu do serwisu jest uzasadnione, gdy znaki narodowe znikają po aktualizacji programu, są błędnie wyświetlane w kilku aplikacjach, nie można ich poprawnie zapisać na dysku albo problem powtarza się przy drukowaniu i eksporcie. Wskazaniem jest także sytuacja, w której część dokumentów działa prawidłowo, a część pokazuje pytajniki lub nieczytelne symbole. Taki wzorzec może świadczyć o różnych ustawieniach plików, niespójnych profilach użytkownika albo błędach w konfiguracji połączenia z bazą.

Przed przekazaniem urządzenia lub danych dobrze jest zanotować, gdzie dokładnie pojawia się błąd, jakie znaki są zmieniane, czy dotyczy to nowych i starych plików oraz czy problem występuje na innym koncie użytkownika. Pomocne może być zachowanie przykładowego dokumentu i zrzutu ekranu, o ile nie zawierają poufnych informacji. Pozwala to odróżnić problem z kodowaniem od kłopotu z czcionką, ustawieniami regionalnymi, programem albo nośnikiem danych.

W Warszawie obsługę takich zgłoszeń może przeprowadzić Warszawskie Pogotowie Komputerowe 24/7, obejmując sprawdzenie konfiguracji systemu, aplikacji, plików i połączeń odpowiedzialnych za zapis tekstu. Zakres czynności dobiera się do objawów, ponieważ prawidłowa naprawa powinna chronić istniejące dane i nie ograniczać się do zmiany pojedynczego ustawienia. Po zakończeniu prac sprawdza się zapis, odczyt, wyszukiwanie oraz działanie przykładowych dokumentów z polskimi i innymi znakami narodowymi.