[Moscow.pm] определение наличия в файле непечатных символов

Ср Сен 3 13:19:45 PDT 2008

2008/9/3, Kaltashkin Eugene <zhecka на gmail.com>:

>> Если это msg, то наверняка это multipart content MIME, разве нет?
>> То есть, должен ведь быть какой-то разделить.
>>
> нету, Microsoft удивляет с каждым разом всё больше и больше.
> пример

Может быть я не вижу проблемы, но разделители я явно вижу.
Это обычный MIME "много в одном". Давайте смотреть вместе...

> --- хрум ---
> X-MimeOLE: Produced By Microsoft Exchange V6.5
> Received: by mx.xxxx.ru
>         id <01C8F7A4.79674211 на mx.xxxx.ru>; Wed, 6 Aug 2008 13:11:56 +0400
> MIME-Version: 1.0
> Content-Type: multipart/mixed;
>         boundary="----_=_NextPart_001_01C8F7A4.79674211"

Вот основной заголовок, в котором признак того, что тут multipart.
И разделитель body и первого вложения, который выгдятит как
"----_=_NextPart_001_01C8F7A4.79674211". Пропускаем все
до этой строки...

> Content-class: urn:content-classes:message
> Subject: FW: ERM report
> Date: Wed, 6 Aug 2008 13:11:56 +0400
> Message-ID: <546257E146388F42A4ECAAC5EA6586F11B039F на mx.xxxx.ru>
> X-MS-Has-Attach: yes
> X-MS-TNEF-Correlator:
> Thread-Topic: ERM report
> thread-index: Acjz7Cpp8OXcPWZeSGueKo0UAoz4mQDuEapQ
> From: "Alexander" <perfi на xxxx.ru>
> To: =?koi8-r?B?8d7Nxc7F1yDhzMXL08HOxNIg98HMxc7Uyc7P18ne?= <yach на xxxx.ru>
>
> This is a multi-part message in MIME format.

Опа, вот и она. Первое вложение:

> ------_=_NextPart_001_01C8F7A4.79674211
> Content-Type: multipart/related;
>         type="text/html";
>         boundary="----_=_NextPart_002_01C8F7A4.79674211"

Говорят, тут HTML. И говорят, что следующий кусок будет
после строки "----_=_NextPart_002_01C8F7A4.79674211".
Топаем...

И года не прошло, как вот она. Что-то HTML был пуст (:

> ------_=_NextPart_002_01C8F7A4.79674211
> Content-Type: text/html;
>         charset="koi8-r"
> Content-Transfer-Encoding: binary

Это снова HTML. Новый boundary не установлен, а это
значит, наверное, то, что он такойже как и в прошлый раз.
Тут мы имее HTML. А binary почему написано -- не знаю.
Может быть дабы уберечь от перекодировки или смены
символов конца строки?

> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=koi8-r">
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:w="urn:schemas-microsoft-com:office:word"
> xmlns:m="http://schemas.microsoft.com/office/2004/12/omml"
> xmlns="http://www.w3.org/TR/REC-html40">
>
> <head>
>
> <meta name=Generator content="Microsoft Word 12 (filtered medium)">
> <!--[if !mso]>
> <style>
> v\:* {behavior:url(#default#VML);}
> o\:* {behavior:url(#default#VML);}
> w\:* {behavior:url(#default#VML);}
> --- хрум ---
> </body>
> </html>

Вот еще одна часть. Тут тип -- картинка. Значит бинарная
по определению.

> ------_=_NextPart_002_01C8F7A4.79674211
> Content-Type: image/jpeg;
>         name="image001.jpg"
> Content-Transfer-Encoding: binary
> Content-ID: <image001.jpg на 01C8F3F4.8C27AF80>
> Content-Description: image001.jpg
> Content-Location: image001.jpg
> X-MS-UrlCompName: 1_multipart%EF%A3%BF1_multipart%EF%A3%BFimage001.jpg
>
> ЪьЪЮ^@^PJFIF^@^A^A^A^@`^@`^@^@Ъш^@C^@
> --- хрум ---

> после указателя MIME part голым кодом идёт бинарное содержимое
> файла(идиотизм)

base64 у них не рулит, значит (:

> MS даже на обычный text/html пишет Content-Encoding-Transfer: binary.

Да, это я уже вижу.

> Обычный греп не подходит, т.к. binary бывает и в начале сообщения и в
> любом другом его месте.

Значит надо либо определять по MIME-типу, либо разбивать на кусочки
по границам и кажду анализировать отдельно.

>> Как самостоятельное решение, попробуйте сделать поиск
>> по re типа такого /[\x00-\x08\x0b\x0e-\x1f]/, что ли. То есть,
>> управляющие символы (первых 32) без табуляции, возрата
>> карретки и перевода строки.
>>
> пока сделал поиск \x00, дальше посмотрим, но это не гут.

Очень "не гут". Лучше уже тогда искать /[\x00-\x1f]/ и делать
соотношение к к-ву байт вообще. Выше некого N -- бинарный,
ниже -- текстовый. Но концы строк все лучше выбрасывать,
наверно.

-- 
Hoc est simplicissimum!
maxim.vuets.name