Przechowywanie danych wielojęzycznych

Przechowywanie danych wielojęzycznych wymaga typów Unicode i przemyślanego doboru kolacji bazy.

Przechowywanie danych wielojęzycznych – czym jest i dlaczego ma znaczenie

Przechowywanie danych wielojęzycznych oznacza takie projektowanie systemu, aby teksty zapisane w różnych alfabetach, językach i wariantach regionalnych zachowywały poprawne znaki, kolejność, znaczenie oraz możliwość późniejszego wyszukiwania. Dotyczy to nie tylko polskich liter, lecz także alfabetu greckiego, cyrylicy, znaków arabskich, hebrajskich, chińskich, japońskich, koreańskich i wielu innych zestawów znaków. W praktyce problem pojawia się wszędzie tam, gdzie w jednym systemie przechowywane są dane użytkowników, nazwy produktów, adresy, opisy, wiadomości, dokumenty lub wyniki wyszukiwania pochodzące z różnych krajów.

Najważniejszym założeniem jest używanie kodowania Unicode. Unicode przypisuje znakom unikalne punkty kodowe, dzięki czemu informacja o tekście nie zależy wyłącznie od języka, programu ani lokalnych ustawień komputera. Samo zastosowanie Unicode nie rozwiązuje jednak każdego problemu. Znaczenie mają również sposób zapisu w bazie danych, kodowanie połączenia z aplikacją, format pliku, reguły porównywania tekstu, sposób sortowania oraz poprawne wyświetlanie znaków przez system operacyjny i przeglądarkę.

Warto odróżnić warstwę znaków od warstwy wyglądu. Ten sam tekst może zostać pokazany inną czcionką, w innym kroju lub z odmiennym układem. Jeżeli jednak dane zostały błędnie zdekodowane przed zapisaniem, późniejsze ustawienie właściwej czcionki nie przywróci pierwotnej treści. Z tego powodu kwestie wielojęzyczności powinny być uwzględniane już przy wyborze technologii, a nie dopiero podczas naprawiania uszkodzonych rekordów.

Wielojęzyczne dane a kodowanie, kolacje i porównywanie tekstu

W systemach bazodanowych często używa się pojęć takich jak kodowanie znaków oraz kolacja. Kodowanie określa, w jaki sposób znaki są reprezentowane w pamięci lub pliku. Kolacja opisuje reguły porównywania i sortowania tekstu. Te dwie kwestie są powiązane, lecz nie są tym samym. Można przechowywać tekst w Unicode, a jednocześnie zastosować reguły sortowania niedopasowane do języka, przez co kolejność wyników będzie niezgodna z oczekiwaniami.

Przykładowo, wyszukiwanie bez uwzględnienia wielkości liter może być pożądane w katalogu produktów, lecz niekoniecznie w polu przechowującym identyfikator techniczny. W jednym miejscu znaki diakrytyczne mogą być traktowane jako równoważne, a w innym powinny odróżniać dwa różne wpisy. Podobnie mogą zachowywać się znaki złożone z kilku elementów Unicode. Wizualnie identyczny znak może być zapisany jako pojedynczy znak lub jako znak podstawowy połączony ze znakiem modyfikującym.

Przy projektowaniu tabel należy ustalić, czy wszystkie pola tekstowe mają używać jednego standardu, czy też wybrane pola wymagają odmiennych reguł. Najczęściej korzystne jest przyjęcie spójnej polityki dla całej aplikacji, a wyjątki wprowadzanie tylko wtedy, gdy wynikają z rzeczywistego wymagania biznesowego. Należy sprawdzić również typ długości pola. Liczba znaków nie zawsze odpowiada liczbie bajtów, dlatego limit ustalony wyłącznie na podstawie pamięci może prowadzić do obcinania tekstu.

Ważne jest też rozróżnienie lokalizacji od języka. Język określa między innymi słownictwo i reguły zapisu, natomiast lokalizacja może wpływać na format daty, liczb, waluty oraz kolejność sortowania. Dane tekstowe, liczby i daty powinny być przechowywane w sposób neutralny, a ich prezentacja dopasowywana dopiero na etapie interfejsu. Zmniejsza to ryzyko, że informacja zapisana dla jednego kraju stanie się nieczytelna po zmianie ustawień regionalnych.

Problemy z przechowywaniem danych wielojęzycznych

Jednym z typowych objawów błędnego kodowania są przypadkowe ciągi znaków zamiast liter z akcentami. Czasem w miejscu prawidłowego tekstu pojawiają się znaki zapytania, puste kwadraty albo symbole niepasujące do treści. Taki efekt może powstać podczas importu pliku, migracji bazy, kopiowania danych pomiędzy programami lub przesyłania formularza przez połączenie skonfigurowane w innym standardzie.

Inny problem polega na tym, że część danych działa poprawnie, a część nie. Dzieje się tak, gdy nowe rekordy trafiają do systemu w Unicode, lecz starsze zostały zapisane w lokalnym kodowaniu. Niespójność może długo pozostać niezauważona, szczególnie jeśli testy obejmują wyłącznie język używany przez zespół tworzący aplikację. W środowisku wielojęzycznym powinno się sprawdzać nie tylko typowe polskie znaki, ale także teksty z różnych alfabetów, znaki łączone, symbole walutowe oraz dłuższe nazwy.

Problemy mogą występować również podczas wyszukiwania. Użytkownik może wpisać słowo bez znaku diakrytycznego, podczas gdy w bazie znajduje się forma z takim znakiem. W innym systemie oba warianty powinny zostać uznane za ten sam wyraz, a jeszcze gdzie indziej powinny zwrócić różne wyniki. Nie należy przyjmować jednej reguły dla każdego pola bez wcześniejszego określenia celu wyszukiwania.

Warto zwrócić uwagę na eksporty do plików tekstowych i arkuszy. Plik może wyglądać poprawnie na jednym komputerze, lecz po otwarciu w innym programie utracić część znaków. Bezpieczny proces obejmuje jawne określenie kodowania pliku, sprawdzenie nagłówka lub deklaracji formatu oraz próbny import i eksport. Przy migracji powinno się wykonywać kopię danych, porównywać liczbę rekordów i kontrolować reprezentatywną próbkę tekstów z każdego obsługiwanego języka.

Praktyczne wskazówki dla wielojęzycznego zapisu danych

Na początku powinno się opisać, jakie języki, alfabety i znaki będą obsługiwane. Następnie należy ustalić jeden standard zapisu dla aplikacji, bazy, połączeń, plików konfiguracyjnych i interfejsu. W dokumentacji technicznej warto zapisać wymagania dotyczące kodowania, sortowania, wyszukiwania, długości pól oraz sposobu walidacji. Jasna reguła ogranicza ryzyko, że poszczególne moduły będą stosowały odmienne ustawienia.

Podczas testów należy używać danych zróżnicowanych pod względem alfabetu i budowy znaków. Dobrze sprawdzają się imiona, nazwiska, adresy, nazwy miejscowości, opisy zawierające znaki diakrytyczne oraz teksty zapisane od prawej do lewej. Trzeba zweryfikować zapis, odczyt, edycję, sortowanie, filtrowanie, wyszukiwanie, eksport, import i generowanie raportów. Test nie powinien kończyć się na sprawdzeniu, czy tekst jest widoczny. Należy potwierdzić, że po ponownym zapisaniu zachowuje tę samą treść.

W aplikacjach internetowych potrzebne jest sprawdzenie kilku punktów przepływu danych: formularza, żądania wysyłanego do serwera, warstwy programu obsługującej dane, połączenia z bazą oraz samej tabeli. Błąd na dowolnym etapie może zmienić tekst. Warto również kontrolować nagłówki odpowiedzi, deklaracje kodowania dokumentu oraz ustawienia biblioteki używanej do komunikacji z bazą.

Przy naprawianiu istniejących danych nie powinno się wykonywać masowej zamiany znaków bez rozpoznania źródła problemu. Najpierw należy ustalić, czy uszkodzenie dotyczy samego zapisu, czy tylko sposobu wyświetlania. Następnie można przygotować kopię, próbkę testową i odwracalną procedurę migracji. Po zmianie trzeba porównać rekordy przed i po operacji oraz sprawdzić znaki szczególnie narażone na błędną konwersję.

Dobrym rozwiązaniem jest także oddzielenie treści od tłumaczeń. Jeżeli jeden produkt lub komunikat występuje w kilku językach, można przechowywać wspólny identyfikator oraz osobne wersje językowe. Ułatwia to aktualizowanie tekstów, kontrolowanie brakujących tłumaczeń i dodawanie kolejnych języków bez przebudowy całej struktury. Trzeba przy tym pilnować, aby brak tłumaczenia nie powodował zastąpienia treści pustą wartością albo przypadkowym językiem domyślnym.

Kiedy zgłosić problem z przechowywaniem danych wielojęzycznych

Do serwisu warto zgłosić się wtedy, gdy znaki są poprawne w jednym programie, lecz uszkodzone w innym, gdy po migracji znikają litery diakrytyczne, gdy wyszukiwanie zwraca niepełne wyniki albo gdy pliki z tekstem otwierają się zależnie od używanego komputera. Pomoc może być potrzebna także po awarii dysku, reinstalacji systemu, zmianie aplikacji bazodanowej lub przeniesieniu danych na inne urządzenie. Istotne jest przekazanie przykładowych plików, informacji o momencie wystąpienia problemu i opisu tego, co działało wcześniej.

Przed przekazaniem sprzętu powinno się zabezpieczyć kopię najważniejszych danych, o ile urządzenie pozwala na bezpieczny dostęp. Nie należy wielokrotnie otwierać i zapisywać uszkodzonych plików ani uruchamiać przypadkowych programów naprawczych, ponieważ może to utrudnić późniejsze odzyskanie oryginalnej treści. W przypadku firmowych baz i dokumentów pomocne jest przygotowanie listy używanych programów, formatów plików oraz języków, które muszą zostać zachowane.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się zgłoszeniami dotyczącymi komputerów i laptopów, w których wielojęzyczne dane nie są prawidłowo zapisywane, odczytywane lub wyświetlane; naprawy z reguły są wykonywane do 3 dni roboczych. Przed rozpoczęciem prac można opisać objawy, wskazać moment pojawienia się błędu oraz zaznaczyć, czy problem dotyczy pojedynczego pliku, całej aplikacji, bazy danych czy konkretnego urządzenia. Takie informacje ułatwiają dobranie bezpiecznej metody diagnostyki i ograniczają ryzyko dalszej utraty treści.