Poprawna konfiguracja czytników niusów

Dość często zadawanym pytaniem jest: dlaczego w artykułach niusowych są widoczne krzaki? Powodem tego jest używanie przez sporą część użytkowników nieskonfigurowanych czytników. Prowadzi to również do zupełnie niepotrzebnego zaniechania przez nich używania polskich znaków narodowych.

Podstawowym problemem jest brak deklaracji zestawu znaków używanego w treści artykułów. Czytnik odbierający artykuł nie mogąc automatycznie przestawić się, wyświetla krzaki w miejscach, gdzie użyto znaków narodowych. Konieczne jest dokonfigurowanie czytnika tak, by w polu content-type znalazła się deklaracja użytego standardu, przy czym znacznie ważniejszy jest sam fakt wystąpienia tej deklaracji niż wybranie takiego czy innego standardu kodowania. Oczywiście standard deklarowany musi być taki jak używany i celowe jest użycie wystarczająco popularnego zestawu znaków by programy odbierające nie miały problemu z rozkodowaniem artykułu.

Drugim kłopotem jest złe kodowanie znaków narodowych w nagłówkach. Skutkiem tego jest brak możliwości ich rozkodowania. Użytkownicy widzą krzaki w tematach artykułów. Powód jest właściwie taki sam tzn. brak deklaracji użytego standardu. Nie należy się jednak sugerować, że jeśli istnieje deklaracja kodowania dla całego artykułu to odnosi się ona również do nagłówków. Tak nie jest! Bierze się to z faktu, że pole to (ContentType) przeznaczone jest zasadniczo do informowania o type zawartości, niekoniecznie użytym kodowaniu znaków. Przykładem niech będą przesyłki wieloczęściowe, dla których podawanie kodowania w nagłówku nie ma żadnej wartości, bo poszczególne części mogą używać różnych kodowań a także posiadać zawartość, do której nijak ma się kodowanie znaków, np. rysunek. Jakaś metoda na oznaczenie tych nagłówków, by dały się rozkodować musi jednak być. Zgodnie z nowym draftem opisującym wygląd przesyłek niusowych nagłówki mogą być wyrażone bezpośrednio w Unikodzie Utf-8 lub zgodnie z dotychczas stosowanymi sekwencjami Mime polegającymi na zapisaniu części łańcuchów zawierających kody większe niż 127, czyli wymagające oznaczenia, w reprezentacji 7-bitowej quoted-printable lub base64 i poprzedzeniu deklaracją. W ten sposób czytniki zdolne są do rozkodowania każdego pola nagłówka zupełnie niezależnie od innych np. deklaracji kodowania dotyczącej treści i wykorzystanie np. w procesie filtrowania nim jeszcze cały artykuł zostanie sprowadzony i o jego zawartości nie można powiedzieć nic.

Używanie 7-bitowych kodowań takich jak quoted-printable, czy base64 miast 8-bitowych jest w pełni prawidłowe a nawet mocno uzasadnione dla możliwości przechowania długich linii tekstu. Kłopot polega na tym, dużo czytników, w tym najbardziej popularne, mają z takimi kodowaniami problemy. Wiele w ogóle nie potrafi ich rozkodować a inne nieprawidłowo składają linie. Nie mając gwarancji rozkodowania, nawet bardzo dobre czytniki, jak Outlook Express, nie korzystają z możliwości tych kodowań np. przy cytowaniu w formacie text/plain. Wydaje się jednak, że przesłanie nieuszkodzonej zawartości jest istotniejsze niż ryzyko, że jakiś mało popularny czytnik nie poradzi z nią sobie. Używanie właściwego kodowania (quoted-printable, base64) i formatu (text/html) gwarantuje możliwość dostarczenia zawartości użytkownikom sprawnych czytników.


Niezbędne testy wykonujemy raczej na grupach przeznaczonych do tego celu niż pierwszej pod ręką. W ten sposób otrzymamy bardziej wiarygodne informacje i nie będziemy zawracali głowy całej reszcie. W przypadku polskojęzycznych niusów są to:


Konfiguracja programów nadających się dla polskiego użytkownika:



Wszelkie prawa zastrzeżone © Piotr Trzcionkowski 1999-2005