Na czym polega kodowanie znaków? Wyjaśnienie UTF-8, ASCII i Unicode

Kodowanie znaków to proces przypisywania konkretnym literom, cyfrom i symbolom unikalnych wartości liczbowych, żeby komputer mógł je zapisać i przetworzyć w postaci binarnej, czyli zer i jedynek. Standardy takie jak ASCII, Unicode oraz UTF-8 to po prostu zestawy reguł określające to przyporządkowanie, co pozwala na poprawny odczyt tekstu na zupełnie różnych urządzeniach i systemach operacyjnych na całym świecie.

Kiedy piszesz maila, edytujesz kod strony internetowej albo wysyłasz wiadomość w komunikatorze, nie zastanawiasz się nad tym, co dzieje się pod spodem. Ty widzisz polskie „ż” lub emoji uśmiechniętej twarzy. Twój procesor widzi ciąg bitów. Bez ustalonego systemu kodowania znaków, ten sam ciąg bitów na jednym komputerze byłby literą, a na innym kompletnie nieczytelnym zlepkiem krzaczków. To jest absolutna podstawa działania tekstów w informatyce. Brak zrozumienia tej mechaniki mści się bardzo szybko. Wiem coś o tym.

Pamiętam doskonale, jak w 2008 roku migrowaliśmy gigantyczną bazę danych sklepu internetowego na nowy serwer. Zignorowaliśmy kwestię domyślnego kodowania tabel w MySQL. Rano okazało się, że wszystkie nazwy produktów, opisy i dane klientów zamieniły się w ciąg znaków zapytania i dziwnych rombów. Musieliśmy przywracać backup z nocy. Od tamtej pory sprawdzam tablice znaków obsesyjnie.

Czym dokładnie jest kodowanie znaków w informatyce?

Zasada jest prosta. Komputery są z natury bardzo głupimi maszynami. Nie rozumieją koncepcji alfabetu. Operują wyłącznie na stanach napięcia elektrycznego, które my dla wygody zapisujemy jako zera i jedynki. Żeby sprzęt mógł zapisać jakikolwiek tekst, musimy mieć słownik tłumaczący ludzkie litery na język maszynowy. Kodowanie znaków pełni funkcję takiego właśnie słownika.

Tworzymy tabelę. W tej tabeli mówimy: liczba 65 to duże „A”. Liczba 66 to duże „B”. I tak dalej. Kiedy wciskasz klawisz na klawiaturze, system operacyjny odbiera sygnał, sprawdza aktywną tablicę znaków i zapisuje odpowiednią wartość liczbową w pamięci RAM, a potem na dysku twardym. Podczas otwierania pliku, edytor tekstu robi dokładnie to samo, tylko w odwrotną stronę. Odczytuje liczby i rysuje na ekranie przypisane do nich kształty liter z wybranej czcionki.

Jak komputer rozumie litery, skoro przetwarza tylko zera i jedynki?

Wszystko sprowadza się do systemu binarnego. Załóżmy, że mamy wspomnianą literę „A”. W standardowych, zachodnich systemach przypisano jej wartość dziesiętną 65. Ale procesor nie widzi liczby 65. Zapisuje ją jako bajt informacji.

Bajt składa się z ośmiu bitów. Każdy bit to jedno zero lub jedna jedynka. Liczba 65 w systemie binarnym wygląda tak: 01000001. Kiedy program do odczytu tekstu widzi ten konkretny układ ośmiu bitów, a ma ustawione kodowanie zgodne ze standardem zachodnim, wie, że ma wyświetlić „A”.

Problemy zaczynają się wtedy, gdy różne systemy używają różnych słowników. Przez dekady firmy informatyczne tworzyły własne, niekompatybilne ze sobą tablice. Apple miało swoje kodowanie (MacRoman). IBM miał swoje w systemie DOS. Microsoft wymyślił własne dla wczesnego Windowsa. Wyobraź sobie, że piszesz tekst w jednym słowniku, a ktoś próbuje go przeczytać, używając zupełnie innego. To po prostu nie mogło działać na dłuższą metę.

• Twój edytor zapisuje znak używając wartości 185. W starym polskim kodowaniu Mazovia oznaczało to literę „ą”.
• Wysyłasz plik koledze z nowszym systemem.
• Jego komputer czyta wartość 185, ale według jego słownika (np. Latin-1) jest to symbol potęgi pierwszej (¹). Zamiast „Zarząd” widzi „Zarz¹d”.
• Dokładnie z tego powodu starsze systemy informatyczne miały gigantyczne problemy z wymianą danych międzynarodowych.

Co to jest ASCII i dlaczego przestało nam wystarczać?

ASCII (American Standard Code for Information Interchange) to ojciec wszystkich współczesnych kodowań. Powstał w latach 60. w Stanach Zjednoczonych. Amerykanie potrzebowali jednolitego standardu dla dalekopisów i pierwszych komputerów. Stworzyli więc tablicę, która była genialna w swojej prostocie.

Oparli ją na architekturze 7-bitowej. To ważne. Użyli tylko 7 bitów z dostępnego bajtu, co dało im dokładnie 128 możliwych kombinacji do wykorzystania. Dlaczego tylko 7? Bo ósmy bit zostawili sobie jako tak zwany bit parzystości do sprawdzania błędów w transmisji danych na słabych liniach telefonicznych. To był standard. Kropka.

Z ilu znaków składa się oryginalna tabela ASCII?

Oryginalna tablica ma dokładnie 128 pozycji (od 0 do 127). Zmieścili w niej wszystko, co było potrzebne przeciętnemu amerykańskiemu inżynierowi. Mamy tam wielkie i małe litery alfabetu angielskiego, cyfry od 0 do 9, podstawowe znaki interpunkcyjne oraz trochę znaków sterujących. Te ostatnie są fascynujące, bo przypominają nam, jak stare jest to rozwiązanie.

Znaki od 0 do 31 to polecenia dla sprzętu fizycznego, a nie litery do czytania. Na przykład znak o numerze 7 (BEL) wyzwalał fizyczny dzwonek w dalekopisie, żeby obudzić operatora. Znak 10 (LF) nakazywał maszynie przewinąć papier o jedną linijkę w dół. Znak 13 (CR) kazał wózkowi drukującemu wrócić na początek linii. Dzisiaj używamy znaków 10 i 13 po prostu jako „Entera” w plikach tekstowych.

ASCII miało jedną gigantyczną wadę. Kompletnie ignorowało istnienie innych języków niż angielski. Nie było tam miejsca na polskie „ł”, niemieckie „ä”, francuskie „ç”, a o rosyjskiej cyrylicy czy znakach chińskich można było w ogóle zapomnieć. 128 miejsc to drastycznie za mało na potrzeby całego świata.

Producenci sprzętu zaczęli więc „hakować” ten system. Zaczęli używać tego wolnego, ósmego bitu. Dzięki temu pojemność tabeli wzrosła do 256 znaków. Pierwsze 128 pozycji zostawiono bez zmian, żeby utrzymać kompatybilność z amerykańskim sprzętem. Z kolei pozycje od 128 do 255 każda firma i każdy kraj zapełniał po swojemu swoimi lokalnymi literami. Tak powstały tak zwane strony kodowe (Code Pages).

W Polsce mieliśmy z tym potworny bałagan. Używaliśmy standardu ISO 8859-2 (zwanego Latin-2) w internecie i na systemach Unix. Microsoft z kolei wymusił w Windowsie swoją własną stronę kodową Windows-1250. Dodatkowo stary DOS używał kodowania CP852. Ten sam polski tekst zapisany na trzech różnych systemach wyglądał inaczej. Programiści musieli pisać specjalne skrypty konwertujące w locie, żeby to wszystko miało ręce i nogi (często i tak kończyło się to katastrofą).

Na czym polega standard Unicode i po co go stworzono?

Sytuacja w latach 90. była już nie do zniesienia. Globalizacja, rozwój internetu i wymiana maili między kontynentami wymusiły radykalną zmianę podejścia. Wtedy do gry weszło konsorcjum Unicode. Zamiast tworzyć setki małych, lokalnych tabliczek, postanowili stworzyć jeden, gigantyczny, uniwersalny katalog wszystkich znaków pisarskich używanych przez ludzkość.

Unicode nie jest bezpośrednio kodowaniem znaków w sensie informatycznym. To raczej abstrakcyjny inwentarz. Gigantyczna biblioteka. W tej bibliotece każdy znak, niezależnie czy to polskie „ź”, japoński znak Kanji, historyczny hieroglif czy emoji z kawałkiem pizzy, dostaje swój unikalny numer identyfikacyjny. Ten numer nazywamy Code Point (punkt kodowy).

Czym różni się Unicode od konkretnego kodowania znaków?

To absolutnie najważniejsze rozróżnienie w tej branży. Unicode tylko nadaje numery. Zapisujemy je zazwyczaj w formacie szesnastkowym, poprzedzonym literami „U+”. Na przykład duże „A” to U+0041. Polska litera „ę” to U+0119. Obecnie baza Unicode zawiera grubo ponad 140 tysięcy przypisanych znaków i ciągle rośnie.

Samo przypisanie numeru to jednak za mało. Procesor nadal musi wiedzieć, w jaki sposób zapisać tę gigantyczną liczbę (często przekraczającą wartość 255) w bajtach na dysku twardym. I tu wchodzą do gry fizyczne metody kodowania, takie jak UTF-8, UTF-16 czy UTF-32. One biorą numer przypisany przez Unicode i tłumaczą go na konkretny ciąg zer i jedynek.

Gdybyśmy po prostu zapisywali każdy znak z Unicode jako stałą liczbę 32-bitową (czyli 4 bajty na każdą, nawet najzwyklejszą literę), pliki tekstowe stałyby się potwornie ciężkie. Rozmiar zwykłego artykułu po angielsku wzrósłby czterokrotnie bez żadnego sensownego powodu. Potrzebowaliśmy sprytniejszego algorytmu kompresji i zapisu. Potrzebowaliśmy standardu, który zrewolucjonizuje sieć.

Co to jest UTF-8 i jak zdominowało cały internet?

UTF-8 (8-bit Unicode Transformation Format) to mistrzostwo świata w dziedzinie inżynierii oprogramowania. Zaprojektowali go w 1992 roku Ken Thompson i Rob Pike na systemie Plan 9. Zrobili to dosłownie w kilka dni na serwetkach, a stworzyli format, który dzisiaj obsługuje ponad 98% wszystkich stron internetowych na świecie.

Geniusz UTF-8 polega na tym, że jest to kodowanie o zmiennej długości. Nie marnuje miejsca na dysku. Zwykłe litery z alfabetu angielskiego zajmują tylko 1 bajt, dokładnie tyle samo co w starym ASCII. Ale jeśli chcesz zapisać polskie znaki, system dynamicznie rozszerza zapis do 2 bajtów. Trudniejsze znaki azjatyckie zajmują 3 bajty, a emoji lub bardzo rzadkie symbole historyczne pochłaniają 4 bajty.

Ile bajtów zajmuje jeden znak w systemie UTF-8?

Mechanika tego procesu opiera się na sprytnych maskach bitowych. Kiedy program czyta plik zaszyfrowany w UTF-8, patrzy na pierwsze bity każdego bajtu. To one mówią mu, ile kolejnych bajtów musi przeczytać, żeby złożyć w całość jeden znak.

• Jeśli bajt zaczyna się od zera (0xxxxxxx), program wie, że to zwykły znak jednobajtowy. Czyste ASCII. Zgodność wsteczna jest tu absolutnie perfekcyjna.
• Jeśli bajt zaczyna się od sekwencji 110 (110xxxxx), system wie, że znak składa się z 2 bajtów. (Tak zapisujemy nasze polskie ogonki).
• Początek 1110 (1110xxxx) to sygnał, że znak zajmuje 3 bajty.
• Początek 11110 (11110xxx) nakazuje odczyt 4 bajtów.

Dzięki temu angielski tekst zajmuje skrajnie mało miejsca, a my wciąż mamy możliwość użycia dowolnego ze 140 tysięcy znaków z biblioteki Unicode w dowolnym momencie. Nie musimy przełączać żadnych stron kodowych. Możemy w jednym zdaniu napisać po polsku, wtrącić japońskie słowo, dodać rosyjską cyrylicę i zakończyć roześmianą buźką. Wszystko w jednym pliku. UTF-8 rozwiązało problemy z kompatybilnością raz na zawsze.

Prawda jest zresztą absolutnie taka, że jeśli dzisiaj tworzysz jakąkolwiek nową aplikację, stronę www, czy bazę danych i wybierasz inne kodowanie niż UTF-8, popełniasz błąd w sztuce. Ignorowanie tego standardu to proszenie się o kłopoty przy pierwszej próbie eksportu lub importu jakichkolwiek danych od zewnętrznego dostawcy.

Dlaczego na stronach internetowych zamiast polskich liter wyświetlają się dziwne znaczki?

Ten irytujący efekt, kiedy zamiast pięknego tekstu widzisz „krzaczki” (na przykład „Mikoaj” zamiast „Mikołaj”), ma nawet swoją oficjalną japońską nazwę: Mojibake. Dochodzi do niego z jednego, bardzo konkretnego powodu. Przeglądarka internetowa lub program tekstowy próbuje zinterpretować ciąg bajtów używając niewłaściwego klucza.

Załóżmy, że zapisałeś plik na starym systemie Windows z użyciem kodowania Windows-1250. W tym systemie polska litera „ś” ma wartość dziesiętną 156. Wrzucasz ten plik na serwer. Użytkownik wchodzi na stronę, ale przeglądarka zakłada domyślnie, że wszystko w dzisiejszym internecie to UTF-8. Próbuje odczytać wartość 156 według reguł UTF-8. W UTF-8 ten znak nie ma sensu jako pojedynczy bajt, bo bajty powyżej 127 służą jako części składowe większych znaków wielobajtowych. Przeglądarka głupieje i wstawia czarny romb ze znakiem zapytania (tzw. Replacement Character U+FFFD).

Zjawisko to występuje masowo przy starych bazach danych, źle skonfigurowanych serwerach pocztowych albo przy pobieraniu wyciągów CSV z systemów bankowych, które zatrzymały się mentalnie w 1999 roku.

Jak naprawić błędy kodowania w HTML i bazach danych?

Naprawa krzaków na stronie wymaga działania na kilku frontach jednocześnie. Nie wystarczy zmienić jednej opcji. Musisz zsynchronizować całą ścieżkę, przez którą przechodzi tekst od bazy danych aż po ekran użytkownika.

• Na poziomie samego pliku HTML musisz wyraźnie poinformować przeglądarkę, czego ma się spodziewać. Wstawiasz w sekcji nagłówkowej tag: <meta charset="UTF-8">. To podstawa.
• Twój edytor kodu (np. VS Code, Notepad++) musi fizycznie zapisywać pliki z tym kodowaniem.
• Twój serwer bazy danych (np. MySQL lub PostgreSQL) musi mieć ustawione właściwe kodowanie tabel i połączenia. W MySQL powinieneś używać wariantu utf8mb4. Stare, domyślne utf8 w MySQL było upośledzone i obsługiwało maksymalnie 3 bajty, przez co wywalało błędy przy próbie zapisu emoji. Dopiero utf8mb4 daje pełne wsparcie dla 4 bajtów.
• Nagłówki serwera HTTP (Apache/Nginx) muszą wysyłać odpowiedni Content-Type w odpowiedzi do przeglądarki.

Zrobiliśmy u siebie w firmie kiedyś ten błąd. Frontend był w UTF-8, pliki były w UTF-8, ale skrypt PHP łączył się z bazą danych używając domyślnego połączenia w standardzie latin1. Dane wchodziły do bazy poprawnie zaszyfrowane w UTF-8, ale baza traktowała je jako latin1, podwójnie je kodując przy wyciąganiu. Wyplątanie danych z tego podwójnego węzła wymagało pisania autorskich skryptów konwertujących na żywym organizmie. Trzy dni wyjęte z życiorysu.

Jakie są różnice między UTF-8, UTF-16 a UTF-32?

Mamy Unicode jako bibliotekę znaków, ale sposobów zapisywania tych znaków jest kilka. UTF-8 omówiłem szczegółowo, bo wygrał wojnę o internet. Ale w systemach operacyjnych i językach programowania mocno trzymają się inne warianty. Różnica polega głównie na tym, ile pamięci zużywają domyślnie na jeden znak i jak bardzo są elastyczne.

UTF-32 jest najprostszy matematycznie. Każdy pojedynczy znak zajmuje zawsze równe 32 bity (4 bajty). Nieważne, czy to litera „A”, czy chiński ideogram. System nie musi niczego przeliczać, nie ma maskowania bitów. Bezpośrednio mapuje numer Unicode na pamięć. Brzmi super, ale marnuje kolosalne ilości przestrzeni dyskowej w przypadku języków opartych na alfabecie łacińskim. Używa się go rzadko, głównie w wewnętrznej pamięci niektórych procesorów podczas przetwarzania skomplikowanych operacji na tekstach, gdzie stała szerokość znaku ułatwia obliczenia.

UTF-16 to kompromis. Został zaimplementowany przez Microsoft w wewnętrznej architekturze systemów Windows NT, oraz przez języki takie jak Java i C#. W UTF-16 podstawowe znaki zajmują 2 bajty (16 bitów). Obejmuje to większość używanych na świecie alfabetów, w tym azjatyckie. Dopiero bardzo rzadkie znaki historyczne lub emoji wymagają użycia tzw. par surogatów (surrogate pairs), rozszerzając znak do 4 bajtów.

Z punktu widzenia webdevelopera, UTF-16 jest uciążliwe. Próba przesłania pliku HTML w formacie UTF-16 przez sieć często kończy się źle, bo wiele starszych routerów i parserów sieciowych spodziewa się w plikach tekstowych jednobajtowych znaków kontrolnych z ASCII. UTF-16 wstawia zera w połowie znaków łacińskich, co stare programy interpretują jako niespodziewany koniec łańcucha tekstowego (Null terminator w języku C). Dlatego w sieci rządzi UTF-8, a w trzewiach Windowsa UTF-16.

Co oznacza BOM (Byte Order Mark) w plikach tekstowych?

To jest temat, który przyprawia programistów o siwe włosy. BOM, czyli Znacznik Kolejności Bajtów, to specjalny, niewidzialny dla oka znak wstawiany na samym początku pliku tekstowego. Jego oficjalny numer w Unicode to U+FEFF. Został wymyślony głównie na potrzeby kodowań UTF-16 i UTF-32.

Dlaczego w ogóle powstał? Komputery mają różną architekturę procesorów. Niektóre czytają bajty od lewej do prawej (Big-Endian), inne od prawej do lewej (Little-Endian). Kiedy masz znak zapisany na 2 bajtach w UTF-16, system otwierający plik musi wiedzieć, w jakiej kolejności je odczytać. BOM wstawiony na początku pliku działa jak znak drogowy. Jeśli system odczyta go poprawnie jako U+FEFF, wie, że kolejność jest zgodna z jego architekturą. Jeśli odczyta go odwrotnie (U+FFFE), wie, że musi w locie zamieniać bajty miejscami dla całego pliku.

Kiedy należy zapisać plik jako UTF-8 bez BOM?

W przypadku UTF-8, BOM jest całkowicie pozbawiony logicznego sensu. UTF-8 traktuje tekst jako ciąg pojedynczych bajtów, więc problem kolejności ich odczytu (Endianness) po prostu tu nie istnieje. Mimo to, niektóre programy, z notatnikiem Windows na czele, uparcie doklejały przez lata trzy bajty (EF BB BF) na początku plików UTF-8, jako taką wizytówkę: „Hej, jestem plikiem UTF-8”.

BOM w plikach UTF-8 to zło. Psuje wszystko. Jeśli napiszesz skrypt w języku PHP i zapiszesz go z BOM, serwer odczyta te trzy niewidzialne bajty i natychmiast wyśle je do przeglądarki, zanim jeszcze przetworzy właściwy kod HTML. Zablokuje to możliwość wysłania jakichkolwiek nagłówków HTTP (słynny błąd „Headers already sent”). Na stronie mogą też pojawić się puste linie na samej górze ekranu. Zawsze ustawiaj w swoim edytorze kodu opcję zapisu jako „UTF-8 bez BOM”. Zawsze.

Zresztą zastanawiacie się pewnie, jak radzić sobie z takimi plikami, gdy dostaniecie je od klienta. Sam się nad tym borykałem dzisiaj u siebie we wtorek. Wystarczy otworzyć plik w dobrym edytorze (Notepad++ załatwia sprawę dwoma kliknięciami w menu „Format”), zmienić na „Koduj w UTF-8” i zapisać. Ucinamy problem u źródła.

Wdrożyliśmy te zasady na robocie w zeszłym miesiącu dla wszystkich dostawców zewnętrznych. Odrzucamy na wejściu każdy plik XML, który nie jest czystym UTF-8. Liczba zgłoszeń na helpdesk związana z „nieczytelnymi fakturami” spadła do zera w jeden dzień.

Nie pozwól, żeby maszyna decydowała za ciebie, jak renderuje tekst. Ty musisz wymusić konkretną tablicę, nadpisać nagłówki w bazie i ustawić meta tagi na froncie. Dopiero wtedy zyskujesz pełną kontrolę nad łańcuchem przesyłu. Sprawdź dokładnie swoje systemy. Zobacz, czy twoja baza nie trzyma przypadkiem danych w starym latin1 udając nowoczesność, i zrób porządek z kodowaniem znaków, zanim pierwsze emoji rozwali ci tabelę klientów.

Bibliografia

1. Konsorcjum Unicode – https://home.unicode.org
2. World Wide Web Consortium (W3C) – https://www.w3.org
3. Baza dokumentacji Mozilla Developer Network – https://developer.mozilla.org
4. Internet Engineering Task Force (IETF) – https://www.ietf.org
5. Wydawnictwo Naukowe PWN – https://pwn.pl