błąd kodowania treści (np. UTF-16 zamiast UTF-8)

Błąd kodowania treści, np. użycie UTF-16 zamiast UTF-8, powoduje nieprawidłowe wyświetlanie znaków w wiadomości e-mail.

Na czym polega błąd kodowania treści

Błąd kodowania treści powstaje wtedy, gdy sekwencja bajtów zapisanych przez jeden program zostanie odczytana według innego zestawu reguł. W przypadku wiadomości e-mail często dotyczy to znaków spoza podstawowego alfabetu łacińskiego, takich jak ą, ę, ł, ś, ż, znaki cyrylicy lub symbole matematyczne. Sam tekst widoczny na ekranie nie jest przechowywany jako abstrakcyjne litery, lecz jako bajty. Program pocztowy musi wiedzieć, jak te bajty zinterpretować, aby odtworzyć prawidłowe znaki.

UTF-8 i UTF-16 są sposobami kodowania znaków zgodnymi ze standardem Unicode, ale zapisują tekst w inny sposób. UTF-8 używa od jednego do czterech bajtów na znak, natomiast UTF-16 zasadniczo używa dwóch lub czterech bajtów. Litera „A” zajmuje jeden bajt w UTF-8 i dwa bajty w UTF-16. Jeżeli treść zapisana w UTF-16 zostanie oznaczona w nagłówku jako UTF-8, odbiorca może zobaczyć przypadkowe symbole, znaki zastępcze albo tekst z dodatkowymi zerowymi bajtami. Odwrotna pomyłka również prowadzi do nieczytelnego wyniku.

Rola nagłówka MIME i deklaracji charset

Wiadomość e-mail może zawierać nagłówki MIME opisujące sposób interpretacji treści. Dla zwykłego tekstu spotykany jest nagłówek w rodzaju Content-Type: text/plain; charset=UTF-8, a dla wiadomości HTML Content-Type: text/html; charset=UTF-8. Parametr charset informuje program odbiorcy, według jakiego kodowania należy odczytać dane. Deklaracja musi odpowiadać rzeczywistemu sposobowi zapisania treści. Samo wpisanie charset=UTF-8 nie konwertuje tekstu z UTF-16 na UTF-8; zmienia tylko informację przekazywaną odbiorcy.

Kodowanie znaków należy odróżnić od kodowania transferowego MIME. Nagłówek Content-Transfer-Encoding może wskazywać między innymi 8bit, quoted-printable albo base64. Te mechanizmy opisują sposób przesłania bajtów, a nie to, czy tekst jest zapisany jako UTF-8, UTF-16 lub w innym kodowaniu. Prawidłowa wiadomość może więc zawierać jednocześnie charset=UTF-8 oraz Content-Transfer-Encoding: base64. Najpierw trzeba poprawnie odtworzyć bajty z warstwy transferowej, a następnie zinterpretować je według zadeklarowanego kodowania znaków.

Objawy, lokalizacja i bezpieczna konwersja

Typowym objawem jest tak zwane mojibake, czyli tekst zniekształcony wskutek odczytania bajtów w niewłaściwym kodowaniu. Może pojawić się ciąg znaków przypominających przypadkowe symbole, pytajniki w rombach albo litery z niepasujących alfabetów. Pytajnik może oznaczać, że wcześniejszy program nie potrafił zapisać danego znaku i zastąpił go bezpowrotnie. Znak zastępczy Unicode, często wyświetlany jako romb z pytajnikiem, wskazuje natomiast na problem z interpretacją lub uszkodzenie danych.

Diagnostykę rozpoczyna się od sprawdzenia surowej wiadomości, a nie tylko widoku w programie pocztowym. Należy porównać deklarację charset w nagłówkach MIME z faktycznym kodowaniem pliku lub treści generowanej przez aplikację. W wiadomości HTML warto sprawdzić także deklarację <meta charset="UTF-8">, pamiętając, że nie powinna ona zastępować prawidłowego nagłówka HTTP lub MIME. Istotne jest również ustalenie, na którym etapie pojawia się błąd: podczas zapisu, generowania wiadomości, wysyłki, konwersji przez program pocztowy czy dopiero podczas wyświetlania.

Naprawa polega na odczytaniu oryginalnych bajtów w ich rzeczywistym kodowaniu, a następnie na jednokrotnej konwersji do uzgodnionego kodowania, zwykle UTF-8. Nie należy wielokrotnie otwierać i zapisywać tego samego pliku przy zmienianych ustawieniach, ponieważ każda błędna konwersja może utrwalić utratę znaków. Przy plikach UTF-16 trzeba zwrócić uwagę na kolejność bajtów, czyli little-endian albo big-endian, oraz na obecność znacznika BOM. BOM może pomóc programowi rozpoznać wariant kodowania, ale nie jest zamiennikiem poprawnej deklaracji MIME.

Serwisowanie problemów z wyświetlaniem tekstu

W środowisku domowym lub biurowym źródłem problemu może być ustawienie programu pocztowego, nieprawidłowo zapisany plik HTML, błędny eksport kontaktów albo aplikacja, która deklaruje inne kodowanie niż faktycznie stosuje. Przed zmianą konfiguracji warto zachować oryginalną wiadomość i wykonać kopię pliku źródłowego. Pozwala to odróżnić błąd prezentacji od trwałego uszkodzenia treści oraz sprawdzić, czy problem występuje w jednym programie, czy także w innych aplikacjach.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, w tym diagnostyką problemów z oprogramowaniem powodujących nieprawidłowe wyświetlanie treści. Podczas analizy można sprawdzić ustawienia systemu, program pocztowy, pliki źródłowe oraz zależności między kodowaniem znaków i deklaracjami MIME, bez utożsamiania samego sposobu kodowania z kodowaniem transferowym wiadomości.