Kodowanie znaków – czym jest ASCII, UTF-8 i ISO-8859-2?

Kodowanie znaków to zbiór sztywnych reguł przypisujących konkretnym literom i symbolom unikalne wartości liczbowe, żeby komputery mogły je poprawnie zapisywać i wyświetlać na ekranie. Z historycznego punktu widzenia ASCII to najstarszy amerykański standard obejmujący tylko 128 podstawowych znaków, ISO-8859-2 to jego rozszerzenie stworzone specjalnie dla języków Europy Środkowej w tym polskiego, a UTF-8 to współczesny, uniwersalny format z rodziny Unicode, który obsługuje niemal wszystkie alfabety świata.

Prawda jest zresztą absolutnie taka, że przeciętny użytkownik internetu ignoruje ten mechanizm do momentu, w którym na monitorze wyskakują mu niezrozumiałe krzaczki. System binarny rozumie wyłącznie zera i jedynki. Maszyna nie ma pojęcia, jak wygląda litera „A” ani tym bardziej polskie „ą”. Musi dostać konkretną liczbę. Ktoś musiał te liczby ustalić.

Dlaczego systemy informatyczne w ogóle potrzebują kodowania znaków?

Komputery przetwarzają dane w oparciu o bity i bajty. Kiedy wciskasz klawisz na klawiaturze, wysyłasz impuls elektryczny. Ten impuls trafia do procesora jako ciąg zer i jedynek. Żeby edytor tekstu wiedział, że wpisałeś literę, musi zajrzeć do specjalnej tabeli. Tablica znaków to po prostu słownik tłumaczący kod maszynowy na glify zrozumiałe dla ludzkiego oka.

A problemy zaczynają się wtedy, gdy dwa różne systemy używają dwóch różnych słowników. Wyślesz komuś plik tekstowy. Ty zapisałeś go według jednej reguły, a odbiorca otwiera go według innej. Efekt to totalny chaos wizualny na ekranie. Zresztą sam się nad tym borykałem we wtorek rano, kiedy stary serwer pocztowy u klienta zrzucił logi z błędami. Wszystko przez brak spójności w interpretacji danych. To błąd.

Jak działa amerykański standard ASCII i dlaczego przestał nam wystarczać?

ASCII powstało w latach 60. Twórcy tego systemu w USA mieli prosty cel. Chcieli ustandaryzować komunikację dalekopisową. Użyli do tego 7 bitów. Daje to dokładnie 128 możliwych kombinacji liczbowych. Od 0 do 127.

W tej skromnej puli upchnęli alfabet angielski, cyfry arabskie, znaki interpunkcyjne i kilka ukrytych komend sterujących masynami. Na tamte czasy to w zupełności wystarczało. Pamięć dyskowa była potwornie droga. Każdy zaoszczędzony bit miał wagę złota. Amerykańscy inżynierowie nie myśleli o reszcie świata. Nie obchodziło ich, że Francuzi mają akcenty, a Polacy ogonki. Zbudowali zamknięty system pod własne potrzeby.

I to działało świetnie przez dwie dekady. Ale kiedy komputery osobiste zaczęły trafiać do Europy, Azji i na Bliski Wschód, ograniczenie do 128 znaków stało się barierą nie do przejścia. Brakowało miejsca na inne alfabety. Próbowano to omijać na różne, często partyzanckie sposoby. Zaczęto używać ósmego bita, który wcześniej był ignorowany lub służył do sprawdzania parzystości. Ten dodatkowy bit podwoił pulę. Zrobiło się 256 miejsc. Tylko że każdy kraj zaczął tworzyć własne, niekompatybilne ze sobą tabele dla tej drugiej połowy znaków.

Z jakiego powodu polskie litery psuły się w starych systemach?

Kiedy polscy informatycy w latach 80. i 90. próbowali pisać w ojczystym języku na zagranicznym sprzęcie, musieli modyfikować sprzętowe generatory znaków. Wgrywano polskie ogonki w miejsce rzadziej używanych symboli graficznych. Powstawały lokalne standardy takie jak Mazovia, Latin-2 czy standard używany w komputerach Amiga.

Wyobraźcie sobie sytuację w małej firmie księgowej na warszawskiej Pradze Północ w 1996 roku. Robiliśmy tam wdrożenie prostej bazy danych dla pacjentów przychodni. Programista zapisał nazwisko „Zaręba” w standardzie Mazovia. Lekarz otworzył ten sam plik na komputerze z wczesnym Windowsem. Zamiast polskiego „ę” zobaczył dziwny symbol matematyczny. Baza przestała wyszukiwać pacjentów. Znowu wywaliło bazę przez BŁĘDNE KODOWANIE w rejestrach pacjentów. Spędziliśmy całą noc na ręcznym podmienianiu znaków w plikach tekstowych. Brak jednolitego standardu paraliżował wymianę informacji.

Czym jest ISO-8859-2 i jak ratował polski internet w latach 90?

Międzynarodowa Organizacja Normalizacyjna postanowiła zrobić z tym porządek. Stworzono rodzinę standardów ISO-8859. Każdy z nich wykorzystywał 8 bitów (jeden bajt) na znak, dając dostęp do 256 pozycji. Pierwsze 128 miejsc zawsze było identyczne z ASCII. To gwarantowało wsteczną kompatybilność. Druga połowa tabeli była inna dla różnych regionów świata.

Dla Europy Środkowej i Wschodniej przygotowano wariant ISO-8859-2. Znany potocznie jako Latin-2. Obejmował on języki takie jak polski, czeski, węgierski, rumuński czy słowacki. Wreszcie mieliśmy oficjalny, zatwierdzony przez komitety standaryzacyjne sposób na zapisywanie naszych liter. Litera „ą” dostała kod B1 w systemie szesnastkowym. Litera „ś” dostała kod B6.

• Wprowadzenie ISO-8859-2 uporządkowało komunikację w rodzącym się polskim internecie. Twórcy stron WWW dodawali specjalny znacznik w nagłówku HTML, żeby przeglądarka wiedziała, jak renderować tekst.
• Systemy uniksowe i wczesne dystrybucje Linuksa przyjęły ten standard jako domyślny dla polskich użytkowników, co ustabilizowało pracę na serwerach.
• Dzięki zachowaniu pierwszej połowy tabeli z ASCII, angielskie komendy programistyczne i skrypty działały bez żadnych modyfikacji.
• Wymiana e-maili między polskimi uczelniami przestała przypominać zgadywankę i deszyfrowanie uszkodzonych wiadomości.

Dlaczego Windows i Linux używały innych tablic kodowych?

Microsoft postanowił pójść własną drogą. Zamiast wdrożyć międzynarodowy standard ISO-8859-2 w systemach Windows, stworzyli własną tablicę o nazwie Windows-1250. Różnice między nimi były subtelne, ale katastrofalne w skutkach. Kilka polskich liter, w tym „ś”, „ź” i „ą”, miało przypisane inne wartości liczbowe.

Wojna formatów trwała latami. Użytkownik Linuksa wysyłał plik tekstowy do użytkownika Windowsa. Odbiorca otwierał go w Notatniku i widział sieczkę. Programiści musieli pisać specjalne skrypty konwertujące w locie teksty między ISO-8859-2 a Windows-1250. Prowadziło to do absurdalnych sytuacji. Strony internetowe często miały na dole małe linki z napisem „Wersja ISO” oraz „Wersja WIN”. Czytelnik sam musiał kliknąć odpowiedni odnośnik, żeby przeczytać artykuł. To był technologiczny absurd.

W jaki sposób UTF-8 zdominował globalny rynek i wyparł stare standardy?

Rozwiązaniem tych wszystkich problemów okazał się standard Unicode. Jego celem było przypisanie unikalnego numeru każdemu znakowi z każdego języka na świecie. Niezależnie od platformy, programu czy języka. Unicode to gigantyczny katalog dziesiątek tysięcy symboli.

Ale sam katalog to za mało. Trzeba było ustalić, jak te liczby zapisywać w pamięci komputera. Tak powstało kodowanie UTF-8. Skrót pochodzi od 8-bit Unicode Transformation Format. Jego genialność polega na zmiennej długości zapisu.

W starszych systemach, jak azjatyckie tablice, każdy znak zajmował na sztywno dwa bajty. W UTF-8 podstawowe znaki z amerykańskiego ASCII zajmują tylko jeden bajt. Jeśli piszesz czysty angielski tekst, plik UTF-8 ma dokładnie taki sam rozmiar jak plik ASCII. Zero strat. Pełna kompatybilność. Gdy system napotyka znak spoza podstawowej puli, na przykład polskie „ż” albo chiński piktogram, płynnie zwiększa rozmiar zapisu do dwóch, trzech lub nawet czterech bajtów.

Obecnie bez mała dziewięćdziesiąt procent wszystkich stron internetowych na świecie używa UTF-8. To po prostu działa. Koniec z wybieraniem tablic kodowych. Koniec z krzaczkami w e-mailach. Wszystkie współczesne przeglądarki, bazy danych i języki programowania traktują UTF-8 jako absolutny, domyślny fundament.

Jakie są realne różnice w zużyciu pamięci między ASCII a UTF-8?

Inżynierowie często spierają się o wydajność pamięciową. Zestawmy twarde dane. W ASCII każde słowo „test” zajmuje 4 bajty. W UTF-8 to samo słowo zajmuje 4 bajty. Różnica pojawia się przy polskich znakach.

Widać wyraźnie, że teksty nasycone polskimi znakami diakrytycznymi puchną na dysku w formacie UTF-8. Polskie litery wymagają dwóch bajtów zamiast jednego. Jednak przy dzisiejszych pojemnościach dysków twardych i prędkościach łączy internetowych, ten narzut pamięciowy jest kompletnie pomijalny. Stabilność i uniwersalność wygrały z agresywnym oszczędzaniem bitów.

Jak poprawnie ustawić kodowanie znaków na stronie internetowej i w bazie danych?

Żeby uniknąć problemów na własnej stronie, musisz wymusić UTF-8 na każdym etapie przetwarzania danych. Zmiana tych zasad na robocie to podstawa. Jeśli pominiesz jeden element w łańcuchu, tekst się rozsypie.

Krok pierwszy to dokument HTML. W sekcji head musisz umieścić odpowiedni znacznik meta. Wygląda to tak: <meta charset="utf-8">. To daje jasny sygnał przeglądarce klienta, jak ma interpretować plik, który właśnie pobrała z serwera.

Drugi etap to pliki źródłowe. Sam edytor kodu (np. VS Code czy Notepad++) musi zapisywać plik PHP lub HTML na dysku z użyciem UTF-8 bez sygnatury BOM (Byte Order Mark). BOM to niewidzialny znacznik na początku pliku, który w środowisku webowym potrafi rozwalić nagłówki HTTP i wyrzucić błąd pustej strony.

Ostatni fragment układanki to baza danych. W MySQL nie wystarczy ustawić domyślnego kodowania na utf8. Stara implementacja UTF-8 w MySQL była wybrakowana i obsługiwała maksymalnie 3 bajty na znak. To powodowało błędy przy zapisywaniu emoji, które wymagają 4 bajtów. Zawsze wybieraj zestaw znaków utf8mb4 oraz metodę porównywania napisów (collation) na utf8mb4_unicode_ci lub nowszą. Dopiero wtedy masz pewność, że system przyjmie i odda dokładnie ten sam tekst.

Co zrobić gdy na ekranie zamiast tekstu pojawiają się krzaczki?

Zjawisko wyświetlania błędnych znaków ma swoją fachową nazwę. To mojibake. Z japońskiego „zniekształcone znaki”. Zazwyczaj wygląda to jak ciąg dziwnych symboli, kwadratów, znaków zapytania w rombach albo liter z zachodnioeuropejskimi akcentami tam, gdzie powinny być polskie litery.

Gdy widzisz na stronie czarne romby ze znakami zapytania (), oznacza to, że przeglądarka oczekuje formatu UTF-8, ale serwer wysłał jej tekst w starym jednobajtowym kodowaniu (np. ISO-8859-2). Mechanizm renderowania poddaje się i wstawia znak zastępczy. Dane zostały bezpowrotnie utracone w procesie wyświetlania.

Jeśli natomiast widzisz dziwne zbitki liter, na przykład „Ăł” zamiast „ó” albo „Ĺ›” zamiast „ś”, sytuacja jest odwrotna. Tekst został zapisany w bazie jako UTF-8, ale strona internetowa ma zadeklarowane kodowanie ISO-8859-2 lub Windows-1250. Przeglądarka bierze dwubajtowy znak UTF-8 i brutalnie tnie go na dwa osobne, jednobajtowe znaki.

Naprawa tego bałaganu wymaga analizy nagłówków serwera. Czasami wina leży po stronie pliku .htaccess w Apache, który na sztywno forsuje złą deklarację w nagłówku Content-Type. Wtedy nawet poprawny znacznik meta w HTML zostanie zignorowany przez przeglądarkę, bo nagłówek HTTP ma wyższy priorytet. Zresztą zastanawiacie się pewnie, dlaczego to na produkcji tak wyje na testach po drodze? Sam to naprawiałem wczoraj u siebie na serwerze testowym. Trzeba po prostu wejść w konfigurację Apache i wymusić AddDefaultCharset UTF-8. To ucina problem u źródła.

Pamiętajcie, epoka żonglowania tablicami znaków bezpowrotnie minęła. Zostawcie zabytkowe systemy w spokoju, wyrzućcie Windows-1250 do kosza i przestańcie trzymać dane na przestarzałych regułach. Przekodujcie swoje bazy na UTF-8 i przestańcie tracić czas na debugowanie rozsypanych ogonków.

Najczęściej zadawane pytania (FAQ)

• Czym różni się ASCII od UTF-8?
  ASCII to stary 7-bitowy standard obsługujący tylko 128 znaków podstawowych bez polskich liter. UTF-8 to nowoczesny system o zmiennej długości od 1 do 4 bajtów, który potrafi zapisać każdy znak z dowolnego alfabetu na świecie, będąc jednocześnie w pełni kompatybilnym wstecz z ASCII.
• Dlaczego polskie znaki nie działają na stronie?
  Dzieje się tak z powodu konfliktu kodowań. Zazwyczaj plik tekstowy na serwerze zapisano w innym formacie (np. Windows-1250), a przeglądarka próbuje go odczytać jako UTF-8, co skutkuje błędnym renderowaniem glifów.
• Co to jest ISO-8859-2?
  To 8-bitowy standard kodowania stworzony dla języków Europy Środkowej potocznie nazywany Latin-2. Był masowo używany w polskim internecie w latach 90. zanim wyparł go uniwersalny UTF-8.
• Czy UTF-8 zajmuje więcej miejsca na dysku?
  W przypadku czystego tekstu angielskiego zajmuje dokładnie tyle samo co ASCII. Polskie znaki diakrytyczne zajmują w nim po 2 bajty, przez co pliki w języku polskim są nieznacznie większe niż w starym systemie jednobajtowym.
• Jakie kodowanie ustawić w bazie MySQL?
  Zawsze należy wybierać zestaw utf8mb4. Stare ustawienie utf8 w MySQL jest wadliwe i nie obsługuje pełnej przestrzeni 4-bajtowej, co powoduje błędy przy próbie zapisu chociażby ikon emoji.
• Jak sprawdzić kodowanie pliku tekstowego?
  Dobrym pomysłem jest użycie zaawansowanego edytora kodu, takiego jak Notepad++ lub VS Code. W pasku stanu na dole ekranu program wyświetli aktualne kodowanie pliku i pozwoli na jego bezpieczną konwersję do UTF-8.

Bibliografia

1. Państwowy Instytut Badawczy NASK – https://www.nask.pl
2. Konsorcjum Unicode – https://home.unicode.org
3. W3C Polska – https://www.w3.org
4. Ministerstwo Cyfryzacji – https://www.gov.pl/web/cyfryzacja
5. Wydawnictwo Naukowe PWN – https://pwn.pl