Obsługa języków narodowych

Obsługa języków narodowych w bazie zależy od typu kolumny i kolacji — pełną swobodę daje Unicode.

Obsługa języków narodowych w bazie danych

Obsługa języków narodowych oznacza zdolność systemu informatycznego do przechowywania, porównywania, sortowania i wyświetlania tekstu zapisanego w różnych alfabetach oraz zgodnie z odmiennymi zasadami językowymi. Dotyczy to nie tylko polskich znaków, takich jak ą, ć, ę, ł, ń, ó, ś, ź i ż, lecz także znaków cyrylicy, alfabetu greckiego, liter z umlautami, znaków azjatyckich, symboli walut i innych elementów stosowanych w międzynarodowej wymianie danych. W praktyce znaczenie ma cały łańcuch przetwarzania: klawiatura, system operacyjny, aplikacja, sterownik, typ kolumny, kodowanie połączenia, kolacja oraz sposób prezentacji danych na ekranie.

Najważniejszym pojęciem pozostaje Unicode. Jest to rodzina standardów pozwalająca przypisywać znakom jednoznaczne wartości niezależnie od języka i platformy. W relacyjnych bazach danych obsługa Unicode może być realizowana przez odpowiedni typ danych, na przykład wariant przeznaczony do tekstu wielobajtowego, albo przez ustawienie kodowania na poziomie całej bazy. Sama możliwość zapisania pojedynczego znaku nie oznacza jeszcze pełnej obsługi języka. Konieczne jest również prawidłowe wyszukiwanie, sortowanie, indeksowanie i przesyłanie treści.

Języki narodowe a kodowanie, kolacja i typ kolumny

Typ kolumny określa, jakie znaki mogą zostać zapisane oraz jak duża będzie przestrzeń przeznaczona na tekst. W starszych konfiguracjach spotyka się kodowania ograniczone do niewielkiego zestawu znaków. Mogą one wystarczyć dla podstawowego alfabetu łacińskiego, lecz powodować utratę danych przy próbie zapisu liter używanych w języku polskim, czeskim, rumuńskim, greckim lub rosyjskim. Objawem bywa pojawienie się znaków zapytania, pustych pól, przypadkowych symboli albo błędu podczas zapisu.

Unicode działa szerzej, ale również wymaga poprawnego wdrożenia. Trzeba sprawdzić kodowanie tabel, kolumn, połączenia aplikacji z bazą oraz plików importowanych i eksportowanych. Jeżeli tylko jeden element wykorzystuje starszy standard, tekst może zostać uszkodzony jeszcze przed zapisaniem w tabeli. Szczególną uwagę należy zwrócić na migracje. Zmiana typu kolumny po wcześniejszej utracie znaków nie odtworzy automatycznie oryginalnej treści, dlatego przed modyfikacją wykonuje się kopię zapasową i test na wydzielonym środowisku.

Kolacja opisuje reguły porównywania i sortowania napisów. W zależności od ustawień może decydować o tym, czy wielkość liter ma znaczenie, czy znaki diakrytyczne są rozróżniane oraz w jakiej kolejności pojawiają się słowa. Dwa napisy mogą być uznane za równoważne przy wyszukiwaniu, mimo że różnią się akcentem, albo mogą zostać potraktowane jako odmienne. W przypadku danych osobowych, nazw miejscowości, katalogów produktów i dokumentów językowych wybór kolacji powinien wynikać z rzeczywistych wymagań, a nie wyłącznie z ustawień domyślnych.

Warto rozdzielić kodowanie znaków od reguł językowych. Kodowanie odpowiada za reprezentację znaku, natomiast kolacja wpływa na porównywanie, sortowanie i działanie indeksów. Prawidłowy zapis słowa nie gwarantuje więc poprawnej kolejności alfabetycznej. Różnice mogą dotyczyć także ligatur, znaków złożonych z kilku punktów kodowych oraz form zapisanych od prawej do lewej.

Typowe problemy z obsługą języków narodowych

Jednym z częstych problemów jest niespójność między bazą a aplikacją. W bazie zapisano tekst w Unicode, lecz formularz wysyła dane w innym kodowaniu. W innym przypadku aplikacja wyświetla treść poprawnie, ale eksport do pliku CSV pomija właściwe kodowanie i po otwarciu w arkuszu kalkulacyjnym pojawiają się nieczytelne znaki. Podobne trudności występują przy integracji z zewnętrznym systemem, gdy każda strona połączenia zakłada inne zasady interpretacji bajtów.

Problematyczne bywają również importy danych z plików tekstowych. Należy ustalić, czy plik wykorzystuje UTF-8, UTF-16, Windows-1250, ISO-8859-2 czy inny standard. Samo rozszerzenie pliku nie daje pewności. Dodatkowo trzeba zweryfikować separator, sposób zapisu cudzysłowów, znaki końca wiersza oraz ewentualny nagłówek. Przy imporcie danych wielojęzycznych test powinien obejmować słowa z polskimi znakami, tekst cyrylicą, znaki spoza alfabetu łacińskiego oraz symbole specjalne.

Inny rodzaj błędów dotyczy długości tekstu. W niektórych systemach limit jest liczony w bajtach, a nie w liczbie widocznych znaków. Tekst zawierający znaki wielobajtowe może zatem zajmować więcej miejsca niż napis o tej samej długości zapisany wyłącznie przy użyciu prostego alfabetu łacińskiego. Należy uwzględnić to przy projektowaniu pól, walidacji formularzy, tworzeniu indeksów i przekazywaniu danych między aplikacjami.

Nieprawidłowa kolacja może powodować pozornie sprzeczne wyniki wyszukiwania. Rekord może istnieć w bazie, ale nie zostać znaleziony przy porównaniu binarnym, przy nieoczekiwanej wrażliwości na wielkość liter albo przy odmiennym traktowaniu znaków diakrytycznych. Kłopotliwe są także różnice między środowiskiem testowym a produkcyjnym. Nawet identyczna aplikacja może działać inaczej, jeśli bazy korzystają z różnych wersji silnika lub odmiennych ustawień regionalnych.

• Nieczytelne symbole po imporcie zwykle wskazują na niezgodność kodowania.
• Brak wyników dla poprawnie wpisanej nazwy może wynikać z kolacji albo normalizacji tekstu.
• Obcięcie końcówki długiego napisu może oznaczać ograniczenie długości liczone w bajtach.
• Różna kolejność tych samych rekordów w dwóch aplikacjach często wynika z innych reguł sortowania.

Praktyczne wskazówki dla języków narodowych

Projektowanie obsługi języków narodowych powinno rozpocząć się od ustalenia, jakie języki i rodzaje tekstu będą rzeczywiście wykorzystywane. Jeżeli dane mogą pochodzić z wielu krajów, najbezpieczniejsze jest przyjęcie Unicode od początku projektu. Późniejsza zmiana kodowania w działającym systemie może wymagać przebudowy tabel, indeksów, procedur, raportów oraz integracji. W dokumentacji warto zapisać typy kolumn, kolacje, kodowanie połączeń i reguły eksportu, aby ustawienia nie zależały od wiedzy jednej osoby.

Testy powinny obejmować pełny przepływ danych, a nie tylko ręczne wpisanie tekstu do pojedynczego pola. Należy sprawdzić zapis w formularzu, odczyt z bazy, wyszukiwanie częściowe, sortowanie, filtrowanie, raportowanie, eksport, import i wyświetlanie na różnych urządzeniach. Przydatny jest zestaw kontrolny zawierający słowa z polskimi znakami, nazwy zapisane cyrylicą, tekst z akcentami, znaki łączone, emoji, apostrofy, łączniki oraz spacje nierozdzielające. Pozwala to wykryć problemy, które nie występują przy prostych danych testowych.

Ważna jest także normalizacja. Ten sam znak może być zapisany jako pojedynczy punkt kodowy albo jako litera połączona ze znakiem diakrytycznym. Dla użytkownika oba warianty wyglądają tak samo, lecz porównanie techniczne może uznać je za różne. Aplikacja powinna konsekwentnie stosować przyjętą formę, zwłaszcza w polach wykorzystywanych do identyfikacji, wyszukiwania i deduplikacji.

Przy tworzeniu kopii zapasowych trzeba upewnić się, że proces zachowuje oryginalne kodowanie. Kopia, która formalnie zakończyła się poprawnie, może być niepełna z punktu widzenia użytkownika, jeśli podczas odtwarzania znaki zostaną zmienione. Weryfikacja powinna obejmować próbne odtworzenie oraz porównanie wybranych rekordów przed i po operacji. Warto również monitorować logi aplikacji i bazy, ponieważ ostrzeżenia o konwersji znaków często pojawiają się wcześniej niż skargi użytkowników.

Kiedy sprawdzić obsługę języków narodowych w serwisie

Do konsultacji technicznej warto zgłosić się wtedy, gdy po aktualizacji systemu znikają polskie znaki, importowane dane wyświetlają się jako przypadkowe symbole, wyszukiwanie nie znajduje istniejących rekordów albo sortowanie nie odpowiada przyjętej kolejności alfabetu. Weryfikacji wymaga również sytuacja, w której jedna aplikacja pokazuje treść poprawnie, a inna prezentuje ją błędnie. Takie objawy mogą wskazywać na problem z bazą danych, konfiguracją programu, sterownikiem, systemem plików, pamięcią masową albo sposobem wykonywania kopii.

Przed przekazaniem urządzenia do analizy warto przygotować opis objawu, przykładowy tekst powodujący błąd, informację o programie oraz moment, od którego problem występuje. Nie należy wielokrotnie konwertować plików ani zapisywać ich w przypadkowych programach, ponieważ każda kolejna konwersja może utrwalać utratę znaków. W pierwszej kolejności zaleca się zabezpieczenie oryginalnych danych i wykonanie kopii roboczej.

W przypadku problemów sprzętowych lub systemowych związanych z zapisem i odczytem danych pomoc może zostać zorganizowana przez Warszawskie Pogotowie Komputerowe 24/7. Przed rozpoczęciem prac analizuje się objawy, sposób występowania błędu oraz możliwość bezpiecznego zachowania danych. Szczególnego znaczenia nabiera ostrożność przy nośnikach, na których znajdują się jedyne kopie dokumentów wielojęzycznych, ponieważ uszkodzenie pliku może dotyczyć nie tylko wyglądu znaków, lecz także ich rzeczywistej reprezentacji.

Obsługa języków narodowych jest więc zagadnieniem obejmującym więcej niż wybór jednego ustawienia w bazie. Poprawny rezultat zależy od zgodności kodowania, typu kolumny, kolacji, aplikacji, połączenia, importu i eksportu. Spójne zasady przyjęte na etapie projektowania oraz regularne testy pozwalają uniknąć utraty znaków, niejednoznacznych wyszukiwań i błędnych raportów.