RFC 2231 – kodowanie parametrów

RFC 2231 opisuje sposób kodowania parametrów nagłówków zawierających znaki spoza ASCII.

RFC 2231 – kodowanie parametrów w nagłówkach wiadomości

RFC 2231 – kodowanie parametrów to rozszerzenie zasad używanych przy budowie nagłówków wiadomości internetowych, szczególnie w formatach powiązanych z pocztą elektroniczną i dokumentami MIME. Jego znaczenie wynika z ograniczenia starszych standardów, które przewidywały przede wszystkim znaki ASCII. W praktyce nazwa pliku, opis części wiadomości, etykieta językowa albo inna wartość parametru może zawierać litery narodowe, znaki diakrytyczne, symbole oraz tekst zapisany w innym alfabecie. Bez dodatkowego mechanizmu taki zapis mógłby zostać uszkodzony podczas przesyłania albo błędnie zinterpretowany przez program pocztowy.

W RFC 2231 opisano kilka powiązanych sposobów przekazywania takich danych. Najbardziej rozpoznawalny jest zapis parametru z oznaczeniem rozszerzonym, w którym pojawia się gwiazdka przy nazwie parametru. Pozwala to wskazać zestaw znaków, język oraz sposób procentowego kodowania wartości. Dzięki temu odbiorca może odtworzyć pierwotny tekst, nawet gdy zawiera on znaki niewystępujące w podstawowym repertuarze ASCII. Rozwiązanie nie zmienia samego załącznika ani treści dokumentu. Dotyczy sposobu opisania informacji w nagłówku.

Przykładowo zwykły parametr może mieć postać filename="raport.txt", natomiast parametr rozszerzony może zostać zapisany jako filename*=UTF-8''raport%20za%C5%BC%C3%B3%C5%82cony.txt. W tym przykładzie UTF-8 oznacza użyty zestaw znaków, dwa apostrofy oddzielają zestaw znaków i opcjonalne oznaczenie języka, a sekwencje zaczynające się od znaku procentu przedstawiają zakodowane bajty. Program zgodny z odpowiednią interpretacją powinien zamienić taki zapis na nazwę czytelną dla użytkownika.

RFC 2231 i rozszerzone parametry MIME

Kontekst techniczny RFC 2231 wiąże się z formatem MIME, który pozwala opisywać różne części wiadomości, w tym tekst, obrazy, dokumenty i inne załączniki. Nagłówki MIME często wykorzystują parametry, takie jak charset, boundary albo filename. Starsze rozwiązania dobrze radziły sobie z prostymi nazwami zapisanymi znakami ASCII, lecz stawały się niewystarczające przy nazwach zawierających polskie litery, znaki cyrylicy, alfabet grecki lub symbole.

Warto odróżnić parametr zwykły od parametru rozszerzonego. W zapisie zwykłym wartość jest ograniczona regułami starszego formatu i może wymagać cudzysłowu, jeżeli zawiera spacje lub znaki specjalne. W zapisie rozszerzonym po nazwie parametru umieszczana jest gwiazdka, na przykład filename*. Po niej przekazywana jest informacja o kodowaniu znaków oraz wartość zakodowana procentowo. Taki sposób przypomina mechanizm spotykany w adresach internetowych, lecz jego zastosowanie w nagłówku wiadomości podlega regułom właściwym dla MIME.

RFC 2231 przewiduje również podział długich wartości na segmenty. Jest to przydatne wtedy, gdy parametr przekracza ograniczenia długości pojedynczego wiersza nagłówka. Segmenty mogą być oznaczone jako param*0*, param*1*, param*2* i tak dalej. Pierwszy segment może zawierać deklarację zestawu znaków i języka, a kolejne przenoszą dalszą część wartości. Odbiorca powinien połączyć segmenty w odpowiedniej kolejności, a następnie przeprowadzić dekodowanie. Nie należy traktować numerów segmentów jak niezależnych parametrów.

W praktyce można spotkać także połączenie zgodności wstecznej z rozszerzonym zapisem. Nadawca może umieścić prostszy parametr filename oraz dodatkowy filename*. Starszy program odczyta pierwszy wariant, natomiast nowszy wybierze wariant rozszerzony, który zachowuje pełną nazwę w UTF-8. Różne programy pocztowe i biblioteki stosują jednak odmienne strategie wyboru wartości, dlatego poprawna obsługa wymaga testów z wieloma odbiorcami.

RFC 2231 – kodowanie parametrów a starsze rozwiązania

RFC 2231 bywa porównywany z mechanizmem opisanym w RFC 2047. Oba rozwiązania dotyczą problemu znaków spoza ASCII, lecz działają w innych miejscach. RFC 2047 służy przede wszystkim do kodowania niektórych wartości tekstowych w nagłówkach, takich jak temat wiadomości albo nazwa nadawcy. RFC 2231 odnosi się do parametrów, czyli elementów przypisanych do pól nagłówków, na przykład nazwy pliku załącznika w nagłówku Content-Disposition lub informacji o typie danych w Content-Type.

Pomieszanie tych mechanizmów może prowadzić do niepełnej zgodności. Nazwa pliku załącznika zakodowana jako słowo opisane przez RFC 2047 nie zawsze będzie prawidłowo rozpoznana jako parametr MIME. Z kolei zastosowanie składni RFC 2231 w miejscu, w którym oczekiwane jest klasyczne kodowane słowo, może skutkować wyświetleniem surowego zapisu zamiast czytelnego tekstu. Przy analizie nagłówków należy więc najpierw ustalić, czy obserwowany element jest osobną wartością nagłówka, czy parametrem dołączonym do pola.

Różnicę widać również przy kodowaniu spacji i znaków specjalnych. W zapisie RFC 2231 spacja może zostać przedstawiona jako %20, zgodnie z kodowaniem procentowym. Nie należy automatycznie zamieniać jej na znak plus, ponieważ znak plus nie pełni tu tej samej roli co w kodowaniu formularzy internetowych. Błąd w tym miejscu może zmienić nazwę pliku albo pozostawić w niej niepożądane symbole.

Współczesne biblioteki pocztowe zwykle ukrywają szczegóły RFC 2231 przed użytkownikiem. Problemy ujawniają się dopiero przy nietypowych nazwach, bardzo długich parametrach, wieloczęściowych załącznikach lub komunikacji pomiędzy programami o różnym poziomie zgodności. W razie potrzeby analizuje się pełne nagłówki wiadomości, a nie wyłącznie nazwę widoczną w oknie programu.

Typowe problemy z RFC 2231 i nazwami załączników

Jednym z częstych problemów jest wyświetlanie nazwy załącznika jako ciągu procentowych sekwencji, na przykład %C5%82, zamiast jako tekstu z właściwymi znakami. Zwykle oznacza to, że program odebrał parametr rozszerzony, ale nie wykonał odpowiedniego dekodowania. Przyczyną może być niepełna implementacja, błędne oznaczenie zestawu znaków albo uszkodzenie nagłówka w trakcie przekazywania wiadomości.

Inny przypadek polega na utracie części nazwy. Może się tak stać, gdy segmenty *0*, *1* i kolejne zostaną potraktowane jako niezależne pola albo zostaną połączone w złej kolejności. Szczególną uwagę zwraca się na brakujący segment, powtórzony numer, nieciągłą numerację oraz nieprawidłowe zakończenie wartości. Nawet jeden uszkodzony fragment może spowodować skrócenie nazwy lub odrzucenie całego parametru.

Czasem program pokazuje nazwę zastępczą, mimo że w źródle wiadomości znajduje się poprawny zapis rozszerzony. Może to wynikać z obecności dwóch wariantów tego samego parametru. Jeżeli jeden jest zgodny ze starszym formatem, a drugi zawiera pełną nazwę, ostateczny wybór zależy od implementacji klienta. Warto wtedy sprawdzić, czy wariant rozszerzony ma dokładnie nazwę filename*, czy zawiera właściwe apostrofy, czy zestaw znaków jest rozpoznawalny oraz czy sekwencje procentowe mają prawidłową postać.

Problemy bywają mylone z uszkodzeniem samego załącznika. Nieprawidłowo wyświetlana nazwa nie musi oznaczać, że zawartość dokumentu jest naruszona. Nagłówek opisuje załącznik, natomiast jego dane są przekazywane osobno, często z użyciem kodowania transportowego. Przed wyciągnięciem wniosku sprawdza się zatem nagłówki, strukturę MIME oraz możliwość otwarcia danych w niezależnym programie.

RFC 2231 – kodowanie parametrów w praktycznej diagnostyce

Przy diagnozowaniu trudności należy zachować oryginalną wiadomość wraz z pełnymi nagłówkami. Zrzut ekranu nazwy załącznika nie pokazuje, czy problem powstał po stronie nadawcy, po stronie programu odbiorczego, czy podczas pośredniego filtrowania wiadomości. Pomocne bywa porównanie tej samej wiadomości w kilku klientach pocztowych albo sprawdzenie jej w widoku źródłowym. Szczególnie istotne są pola Content-Disposition i Content-Type.

Warto zweryfikować, czy deklaracja kodowania odpowiada faktycznym danym. Dla tekstu zawierającego polskie znaki często stosowane jest UTF-8, jednak sama obecność napisu UTF-8 nie naprawi bajtów zapisanych w innym kodowaniu. Następnie sprawdza się składnię wartości po drugim apostrofie, poprawność sekwencji procentowych oraz kolejność segmentów. Znak procentu powinien być poprzedzony dwiema cyframi szesnastkowymi. Niekompletna sekwencja może przerwać dekodowanie całej nazwy.

Przy przygotowywaniu własnych wiadomości wskazane jest korzystanie ze sprawdzonych bibliotek MIME zamiast ręcznego konstruowania nagłówków. Biblioteka może dobrać zgodny wariant zapisu, podzielić długą wartość, zastosować odpowiedni zestaw znaków i zachować wariant przeznaczony dla starszych odbiorców. Ręczna edycja nagłówka zwiększa ryzyko pomylenia kodowania treści z kodowaniem parametru.

Jeżeli problem występuje tylko na jednym komputerze, przydatne jest sprawdzenie aktualności klienta pocztowego, ustawień językowych oraz sposobu zapisywania załączników. Gdy ten sam błąd pojawia się u wielu odbiorców, większe znaczenie ma analiza wiadomości po stronie nadawcy albo konfiguracji pośredniego systemu pocztowego. W obu przypadkach zachowanie oryginalnego źródła ułatwia rozróżnienie błędu prezentacji od błędu w samym komunikacie.

Kiedy zgłosić RFC 2231 – kodowanie parametrów do serwisu

Do serwisu warto zgłosić się wtedy, gdy problem z nazwami załączników powtarza się mimo aktualizacji programu, dotyczy wielu wiadomości albo współwystępuje z innymi nieprawidłowościami poczty. Dotyczy to między innymi znikających polskich znaków, samoczynnego skracania nazw, pojawiania się ciągów procentowych, trudności z zapisem załączników oraz różnic w wyświetlaniu tej samej wiadomości na kilku urządzeniach.

Przydatne jest przygotowanie przykładowej wiadomości w oryginalnej postaci, informacji o używanym programie pocztowym i opisu tego, jak powinien wyglądać prawidłowy rezultat. Nie powinno się przesyłać haseł ani przypadkowych danych prywatnych. Wystarczający może być bezpiecznie wybrany przykład, w którym widoczny jest problem z parametrem MIME. Warszawskie Pogotowie Komputerowe 24/7 może pomóc w rozdzieleniu kwestii związanych z RFC 2231 od problemów systemowych, ustawień programu i uszkodzeń profilu użytkownika.

Podczas analizy sprawdza się najpierw strukturę wiadomości, następnie sposób dekodowania parametrów, a na końcu wpływ konkretnego programu na zapis i prezentację nazw. Takie uporządkowanie pozwala uniknąć pochopnego uznania załącznika za uszkodzony. RFC 2231 – kodowanie parametrów jest przede wszystkim regułą opisu danych w nagłówku, dlatego właściwa diagnoza powinna obejmować zarówno źródło wiadomości, jak i środowisko, w którym jest ona odczytywana.