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

Ср Сен 3 15:03:25 PDT 2008

Content-Transfer-Encoding определяет формат передачи содержимого и не
имеет никакого отношения к самому содержимого. Никто не запрещает
передавать данные как есть, используя бинарную кодировку передачи.
Есть только рекомендации касающиеся совместимости со старым
программным обеспечением, которое может стоять на промежуточных узлах
передачи и завернуть ваши данные.

2008/9/4 Maxim Vuets <maxim.vuets на gmail.com>:
> 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
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

-- 
Best regards, Ruslan.