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

[Kaltashkin Eugene]

Vladimir V. Perepelitsa пишет:
> Разрешите поинтересоваться: зачем вам вручную распознавать где начались 
> бинарные данные?
>   
рассказываю по полочкам.
Есть такая система MS Exchange в которой данные хранятся в виде 
монолитных стораджей с кучей ящиков внутри.
нечто типа Объектной базы данных. Проблема заключается в том, что при 
наличии у меня в компании 700 человек
в ящиках каждого из сотрудников может находиться до 30000+ сообщений 
одновременно. Согласно методики бекапа
данных можно использовать два типа бекапов. Бекап полностью забитых 
сообщениями стораджей и бекап каждого сообщения
в отдельности для каждого пользователя в каждой папке. Первый 
исключается ввиду невозможности восстановления ящика и сообщений в 
отдельности.
Ежедневный инкрементальный бекап базы обычно получается 3-8 ГБ. Общий 
бекап базы доходит до 400 ГБ за раз(после зачистки
сообщений старше 90 дней). при среднем размере письма 2кб выборка 
миллионов писем затягивается на оооочень большое время.
Использовать Архивацию на локальных местах не выгодно в принципе, т.к. 
данные нужно или хранить на сервере или на локальной
станции. И то и другое чревато своими недостатками. В одном случае это 
возможностью потери связи с сервером и неконтролируемыми
ошибками провалившейся архивации, во втором случае риском потери 
жесткого диска пользователя.
Выходов немного. Добавление сервера проблемы не решит, т.к. объём данных 
будет постоянен и в том и в другом случае. Возможно
ускорится выборка из базы сообщений, но опять же ненадолго, до первой 
серьёзной фрагментации.
Выход два это промежуточный IMAP backup сервер на который складываются 
данные старше определенного времени с основного сервера.
В качестве IMAP backup сервера используется cyrus-IMAPD который жестко 
следует требованиям RFC. А в чудесном RFC написано, что
содержимое сообщения не должно содержать непечатных символов. И как 
следствие этого, все сообщения с аттачами в binary формате
благополучно посылаются нафиг при попытке залить их на сервер. Поэтому я 
написал систему перекодирования которая ловит сообщения
с аттачами в binary, разбирает их на кусочки, заново собирает из 
кусочков в единое целое, но уже в кодировке base64 и отправляет на IMAP
сервер. При файловом бекапе(в случае хранилища IMAP) мы получаем 
скорость бекапа близкую к скорости отдачи с поверхности, тем самым 
экономя время на резервное копирование.

Предшествуя вопросы "а почему не подключиться к ящику и напрямую не 
таскать данные из ящика в ящик?" сразу скажу, что все синхронизаторы
тупо используют метод "вынул-вставил" без каких либо перекодировок, 
соответственно будет тоже самое. Плюс ко всему MS Exchange не имеет функции
PROXYAUTH и даже админ не может подключиться к чужому ящику без пароля 
пользователя, а собирать для бекапа пароли меняющиеся раз в 30 дней 
просто анрил.
Вот в принципе и вся причина :)
ЗЫ: ну и последняя причина это то, что таких конверторов из Exchange 
Storage в IMAP просто не существует :) (пока)


> просто разберите сообщение при помощи, к примеру, MIME::Lite
>
> Content-Transfer-Encoding: binary выгоднее base64 в 4/3 раза по объему, 
> возможно именно поэтому они его и используют.
>
>