UTF-16

UTF-16 to kodowanie Unicode wykorzystujące od dwóch do czterech bajtów na znak.

Jednostki kodowe, pary zastępcze i płaszczyzny Unicode

UTF-16 koduje znak za pomocą jednej lub dwóch szesnastobitowych jednostek. Znaki z podstawowej płaszczyzny wielojęzycznej, czyli o numerach do U plus FFFF, mieszczą się w jednej jednostce i zajmują dwa bajty. Znaki z płaszczyzn dodatkowych, między innymi emoji, znaki muzyczne i rzadkie ideogramy, wymagają pary zastępczej złożonej z dwóch jednostek, czyli czterech bajtów. Zakresy od D800 do DBFF oraz od DC00 do DFFF są zarezerwowane właśnie na połówki takiej pary i same w sobie nie oznaczają żadnego znaku. Stąd bierze się zjawisko dobrze znane programistom: łańcuch o długości dwa może reprezentować jeden widoczny symbol.

Kolejność bajtów i różnica wobec UTF-8

Ponieważ jednostka ma dwa bajty, znaczenie ma kolejność ich zapisu. Wariant z młodszym bajtem na początku jest domyślny w Windows, wariant odwrotny spotyka się w formatach sieciowych i na części platform uniksowych. Rozróżnia je znacznik kolejności bajtów umieszczany na początku pliku: FF FE albo FE FF. Windows używa UTF-16 wewnętrznie w interfejsie programistycznym systemu, natomiast w plikach i w sieci zdecydowanie dominuje UTF-8, który dla tekstu łacińskiego zajmuje o połowę mniej miejsca i nie ma problemu kolejności bajtów. Notatnik w nowszych wydaniach Windows zapisuje domyślnie w UTF-8, a warianty UTF-16 pozostawia w liście wyboru kodowania przy zapisywaniu pliku.

Objawy złego rozpoznania kodowania

Plik UTF-16 otwarty jako jednobajtowy pokazuje tekst rozstrzelony zerami, czyli literę, potem pusty znak, potem kolejną literę. Odwrotna pomyłka daje ciąg orientalnych krzaków. Import pliku CSV zapisanego w UTF-16 do arkusza kalkulacyjnego kończy się zwykle wciśnięciem całego wiersza do jednej komórki, bo separator nie zostaje rozpoznany. W bazach danych typ kolumny nvarchar w SQL Server przechowuje właśnie UTF-16, dlatego długość liczona funkcją znakową nie zgadza się z liczbą bajtów, a nieostrożne przycięcie łańcucha potrafi rozciąć parę zastępczą na pół i wygenerować nieprawidłowy znak zapisany do bazy.

Ratowanie eksportów i integracji z systemami sprzedaży

Najczęściej wzywają nas do sytuacji, w której plik wymiany danych między programem magazynowym a sklepem internetowym nagle przestaje się wczytywać po aktualizacji jednej ze stron, bo zmieniło się kodowanie eksportu. Rozpoznajemy faktyczne kodowanie pliku po jego początkowych bajtach, przekodowujemy dane bez utraty polskich znaków i poprawiamy ustawienia eksportu tak, aby problem nie wrócił przy kolejnej partii. Robimy to również dla wdrożeń oprogramowania handlowego takiego jak Subiekt, WAPRO czy Comarch, gdzie po stronie bazy SQL Server nieprawidłowe kodowanie potrafi popsuć nazwy towarów w całym katalogu.