Unicode vs non-Unicode

Typy Unicode zajmują dwa bajty na znak i obsługują pełen zakres alfabetów; typy non-Unicode są węższe, ale mniej pojemne.

Unicode i non-Unicode — różnica w sposobie zapisu tekstu

Unicode to rodzina standardów opisujących sposób reprezentowania znaków używanych w różnych systemach pisma. Obejmuje między innymi litery alfabetu łacińskiego, cyrylicę, alfabet grecki, znaki azjatyckie, symbole matematyczne oraz emoji. Każdy znak Unicode ma przypisany punkt kodowy, czyli liczbę jednoznacznie identyfikującą dany znak. Standard Unicode nie jest jednak pojedynczym formatem pliku ani jednym sposobem zajmowania pamięci. Punkty kodowe mogą być zapisywane przy użyciu różnych kodowań, między innymi UTF-8, UTF-16 i UTF-32.

Określenie non-Unicode odnosi się zwykle do starszych stron kodowych, które zawierają ograniczony zestaw znaków. Przykładami są Windows-1250, używany historycznie dla języków Europy Środkowej, ISO-8859-2 oraz ASCII. W takich kodowaniach jeden bajt może oznaczać konkretny znak, ale znaczenie wartości zależy od wybranej strony kodowej. Bajt odpowiadający określonej literze w jednym kodowaniu może oznaczać inny znak w innym. Z tego powodu tekst zapisany jako non-Unicode może zostać wyświetlony nieprawidłowo po otwarciu w programie używającym odmiennej strony kodowej.

Dlaczego zapis „dwa bajty na znak” jest uproszczeniem

W praktyce często spotyka się stwierdzenie, że typ Unicode zajmuje dwa bajty na znak, a typ non-Unicode jeden bajt. Jest to skrót myślowy, który może prowadzić do błędnych wniosków. UTF-16 używa jednostek kodowych o rozmiarze dwóch bajtów, lecz znaki znajdujące się poza podstawową płaszczyzną Unicode mogą wymagać dwóch takich jednostek, czyli łącznie czterech bajtów. Dotyczy to między innymi części emoji oraz niektórych rzadziej używanych znaków. Z kolei UTF-8 koduje znaki przy użyciu od jednego do czterech bajtów.

UTF-8 zapisuje znaki ASCII, czyli między innymi podstawowe litery alfabetu łacińskiego, cyfry i część znaków interpunkcyjnych, w jednym bajcie. Polskie znaki, takie jak ą, ć, ę, ł, ń, ó, ś, ź i ż, zajmują w UTF-8 po dwa bajty. Znaki z innych zakresów mogą zajmować trzy albo cztery bajty. UTF-32 stosuje stałą długość czterech bajtów na punkt kodowy, dzięki czemu obliczanie pozycji znaku jest prostsze, ale zużywa więcej pamięci dla tekstów zawierających głównie podstawowe znaki łacińskie. Rozmiar danych zależy więc od konkretnego kodowania, zawartości tekstu i sposobu implementacji typu.

Wpływ kodowania na pliki, programy i bazy danych

Nieprawidłowy dobór kodowania może powodować tak zwaną mojibake, czyli pojawianie się przypadkowych znaków zamiast oryginalnego tekstu. Typowym objawem jest zastąpienie polskich liter ciągiem znaków o nieczytelnym znaczeniu, na przykład „Ä…” albo innymi symbolami wynikającymi z błędnej interpretacji bajtów. Problem może powstać podczas zapisu pliku tekstowego, importu danych, komunikacji między programami albo odczytu danych z nośnika. Sam tekst nie zawsze jest uszkodzony; czasami zmieniono jedynie sposób jego interpretacji.

W aplikacji ważne jest rozróżnienie między punktem kodowym, jednostką kodową i widocznym znakiem. Jeden znak użytkowy może składać się z kilku punktów kodowych, na przykład litera podstawowa oraz osobno zapisany znak diakrytyczny. Z tego powodu liczba znaków widocznych na ekranie nie musi odpowiadać liczbie bajtów ani liczbie jednostek kodowych. Operacje takie jak przycinanie tekstu, wyznaczanie długości, sortowanie i sprawdzanie limitu pola powinny uwzględniać używane kodowanie oraz zasady normalizacji Unicode. W przeciwnym razie można obciąć znak w nieprawidłowym miejscu albo błędnie uznać tekst za zbyt długi.

W systemach korzystających ze starszych stron kodowych problemem jest także ograniczony zakres znaków. Strona kodowa przeznaczona dla jednego regionu językowego może nie zawierać znaków potrzebnych w innym języku. Konwersja z Unicode do non-Unicode może wtedy prowadzić do zastąpienia znaku symbolem zastępczym, utraty informacji albo nieodwracalnego uproszczenia tekstu. Konwersja w przeciwnym kierunku również nie naprawi danych, które wcześniej zostały zapisane z użyciem niewłaściwego kodowania.

Rozpoznawanie problemów z Unicode podczas pracy komputera

Przy diagnozowaniu problemów z tekstem należy ustalić, gdzie następuje zmiana interpretacji danych. Warto sprawdzić kodowanie pliku, ustawienia programu, sposób otwierania dokumentu oraz format wymiany danych używany przez aplikacje. W plikach tekstowych pomocna może być obecność znacznika BOM, czyli kilku bajtów na początku pliku sygnalizujących określone kodowanie, choć jego brak nie oznacza automatycznie, że plik nie jest zapisany w Unicode. Istotne jest również sprawdzenie, czy program poprawnie rozpoznaje UTF-8, UTF-16 lub konkretną stronę kodową.

Jeżeli problem występuje tylko w jednym programie, przyczyną może być jego ustawienie regionalne, niezgodna czcionka albo błędna konwersja przy imporcie. Brak znaku w czcionce zwykle objawia się pustym prostokątem lub symbolem zastępczym, natomiast błędne kodowanie daje inne, lecz niepasujące znaki. Są to różne usterki i wymagają odmiennych działań. W przypadku laptopa lub komputera PC można sprawdzić ustawienia systemowe, aplikację odpowiedzialną za zapis danych oraz sposób przenoszenia pliku między urządzeniami.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC oraz ich podzespołów, a w ramach diagnostyki można ustalić, czy nieprawidłowe wyświetlanie tekstu wynika z ustawień systemu, programu, czcionki lub konwersji kodowania.