Доброй ночи, ЛОР.
Разбирая в своей программе структуры vCard и vMessage, я наткнулся на поля, которые помечены как quoted-printable, но на самом деле таковыми не являются.
RFC 2045 определяет Literal representation только для ASCII-символов, всё остальное оборачивается в HEX (что-то типа =D0=9E=D0=BB=D0=B5=D0=B3). Такой quoted-printable у меня обрабатывался давно и обрабатывался нормально.
Но вот я столкнулся с полями, где указано ENCODING=QUOTED-PRINTABLE, а дальше идёт чистый текст в UTF8. В шестнадцатиричку закодированы только переносы (=0A=0A).
Варианты действий:
- игнорировать такие поля как неправильные. Самый простой и самый плохой подход (пользователь потеряет данные);
- ввести искусственный хак — при обнаружении non-ASCII символов в «кодированном тексте» возвращать его как уже декодированный (возможно, заменив =0A на символы перевода строки);
- сделать полноценный парсер с учётом юникода.
Сейчас я остановился на варианте 2. Это дёшево и сердито (и имхо, справедливо по отношению к такого рода данным). Смущает только, что я не знаю, какие ещё символы придётся обрабатывать отдельно.
По уму, если делать вариант 3, надо пробегаться по всем юникодным символам в ожидании знака =, и то, что с него начинается, уже трактовать как 16-ричку. Но при этом надо уметь для каждого UTF8-символа определять его длину, чтобы не принять за = какой-нибудь средний байт какого-нибудь 4-байтного символа. Алгоритм определения, в принципе, найти можно. Вопросов только 2: стоит ли этим заморачиваться для уже нестандартного случая, и нельзя ли сделать это как-нибудь проще?
