LINUX.ORG.RU

Что нам делать с пьяным Quoted-printable

 ,


1

2

Доброй ночи, ЛОР.
Разбирая в своей программе структуры 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). Варианты действий:

  1. игнорировать такие поля как неправильные. Самый простой и самый плохой подход (пользователь потеряет данные);
  2. ввести искусственный хак — при обнаружении non-ASCII символов в «кодированном тексте» возвращать его как уже декодированный (возможно, заменив =0A на символы перевода строки);
  3. сделать полноценный парсер с учётом юникода.

Сейчас я остановился на варианте 2. Это дёшево и сердито (и имхо, справедливо по отношению к такого рода данным). Смущает только, что я не знаю, какие ещё символы придётся обрабатывать отдельно.

По уму, если делать вариант 3, надо пробегаться по всем юникодным символам в ожидании знака =, и то, что с него начинается, уже трактовать как 16-ричку. Но при этом надо уметь для каждого UTF8-символа определять его длину, чтобы не принять за = какой-нибудь средний байт какого-нибудь 4-байтного символа. Алгоритм определения, в принципе, найти можно. Вопросов только 2: стоит ли этим заморачиваться для уже нестандартного случая, и нельзя ли сделать это как-нибудь проще?

★★★★★

Последнее исправление: hobbit (всего исправлений: 1)

Ответ на: комментарий от Shadow

Последние версии программы MyPhoneExplorer в файле резервной копии (MPB). Моя программа этот MPB, соответственно читает.

К сожалению, несмотря на известные недостатки, это, на мой взгляд, лучшая программа по вытаскиванию контактов и сообщений с телефона и заливки обратно.

hobbit ★★★★★
() автор топика
Последнее исправление: hobbit (всего исправлений: 2)

CHARSET какой?

Многие реализации забивают на MIME и экранируют только спец. символы (=, табуляции, переводы строк и тп.)

anonymous
()
Ответ на: комментарий от hobbit

У меня был какой-то старый китайский телефон, он вообще все экранировал «=XX», независимо от того латинские буквы или нет.

anonymous
()
Ответ на: комментарий от anonymous

Ну эт как раз нормально:

Octets with decimal values of 33 through 60 inclusive, and 62 through 126, inclusive, MAY be represented as the US-ASCII characters which correspond to those octets

Слово MAY аж большими буквами написали…

hobbit ★★★★★
() автор топика
Ответ на: комментарий от hobbit

программы MyPhoneExplorer

Скорее всего, кривой vcard приходит с телефона, а программа тупо записывает как есть.

anonymous
()
Ответ на: комментарий от anonymous

Да, я и такого варианта не исключаю. Поэтому несмотря на то, что пока я остановился на варианте 2, придётся, возможно, делать 3-й — мало ли в какую сторону на других аппаратах радиус кривизны изменится…

hobbit ★★★★★
() автор топика
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

мало ли в какую сторону на других аппаратах радиус кривизны изменится…

И придется писать еще искривлятор :)

anonymous
()
Ответ на: комментарий от hobbit

Дык в RFC всегда так делают. Там модальные глаголы особое значение имеют. Кстати, посему они плохо переводимы :3

mertvoprog
()

надо пробегаться по всем юникодным символам в ожидании знака =, и то, что с него начинается, уже трактовать как 16-ричку. Но при этом надо уметь для каждого UTF8-символа определять его длину, чтобы не принять за = какой-нибудь средний байт какого-нибудь 4-байтного символа

Для этого не надо уметь определять длину символа. Все байты UTF-8 за пределами ASCII (включая средние) имеют значение >= 128. Можешь рассматривать её как произвольную 8-битную кодировку, совместимую с ASCII.

cdslow ★★
()

Но при этом надо уметь для каждого UTF8-символа определять его длину, чтобы не принять за = какой-нибудь средний байт какого-нибудь 4-байтного символа.

Такого в принципе не бывает. «Длинные» коды UTF8 кодируются верхней половиной значений байта и с 127-bit ASCII не пересекаются.

wandrien ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.