nieprawidłowe kodowanie znaków

Nieprawidłowe kodowanie znaków objawia się „krzaczkami” w miejscu polskich liter.

Skąd biorą się krzaczki zamiast ogonków

Bajty nie niosą informacji o tym, jak je odczytać. Jeśli tekst zapisano w UTF-8, gdzie każda polska litera zajmuje dwa bajty, a odczytano według strony kodowej Windows-1250, gdzie zajmuje jeden — pojawiają się pary znaków w rodzaju Ä… czy ż. W drugą stronę, przy odczycie jednobajtowego zapisu jako UTF-8, powstają znaki zapytania albo romb z pytajnikiem, bo sekwencja jest formalnie nieprawidłowa. Trzeci wariant to podmiana strony kodowej na pokrewną: ISO-8859-2 i Windows-1250 zawierają te same polskie litery, ale pod różnymi numerami, więc część tekstu wygląda dobrze, a część nie.

Gdzie ustawia się kodowanie w praktyce

W plikach CSV otwieranych przez arkusz kalkulacyjny decyduje kreator importu i wybór strony 65001 dla UTF-8; podwójne kliknięcie w plik pomija ten krok i używa domyślnej strony systemu. Znacznik BOM na początku pliku pomaga arkuszom rozpoznać UTF-8, ale psuje pliki wsadowe i skrypty czytane przez narzędzia uniksowe. W konsoli Windows stronę zmienia polecenie chcp — 852 dla starego DOS-owego zestawu, 1250 dla środkowoeuropejskiej strony Windows, 65001 dla UTF-8. W bazach SQL Server znaczenie ma typ kolumny: VARCHAR zależy od sortowania bazy, NVARCHAR trzyma Unicode, ale literał trzeba poprzedzić literą N, inaczej tekst jest konwertowany przed zapisem. W MySQL prawdziwy Unicode daje dopiero zestaw utf8mb4, a stary utf8 obcina znaki czterobajtowe.

Objawy, które zwykle mylą trop

Wydruk z programu handlowego bez ogonków, choć na ekranie wszystko jest poprawne, wskazuje na sterownik drukarki lub czcionkę, nie na bazę. Nazwy plików z krzaczkami po rozpakowaniu archiwum ZIP wynikają z braku znacznika kodowania w starym formacie i różnicy między systemem pakującym a rozpakowującym. Wiadomość e-mail z zepsutymi literami ma zwykle nagłówek Content-Type deklarujący inny zestaw, niż faktycznie użyto. Osobna pułapka to systemowa opcja obsługi Unicode w ustawieniach regionalnych, opisana jako funkcja w wersji testowej — po jej włączeniu nowe programy działają lepiej, ale starsze aplikacje handlowe i sterowniki drukarek fiskalnych zaczynają pokazywać uszkodzone napisy.

Naprawa danych, nie tylko wyświetlania

Rozróżniamy dwa przypadki: tekst tylko źle wyświetlany, gdzie wystarczy zmiana ustawień, oraz tekst już zapisany w bazie z uszkodzonymi bajtami, gdzie potrzebna jest konwersja z rozpoznaniem pierwotnego kodowania i kontrolą wyników. Robimy to przy migracjach baz Subiekta, WAPRO i Comarcha między serwerami o różnym sortowaniu, przy imporcie cenników od dostawców i przy przenoszeniu poczty między programami. Nad danymi pracujemy na kopii, więc oryginał zostaje nietknięty do czasu akceptacji efektu.