Почему размер приложения, заданный интерфейсом программирования Outlook, всегда неправильный?

Question

Пытаясь использовать Outlook Interop в C#, я заметил любопытную вещь.

• Сначала я получил размер вложения с Attachment.Size property.
• Во-вторых, я сохраняю вложение в файл, используя Attachment.SaveAsFile method.

Сравнивая реальный размер сохраненного файла и размер, заданный Outlook, я замечаю, что реальный, сохраненный файл всегда меньше ожидаемого от Attachment.Size. Сохраненные файлы выглядят действительными и не усекаются.

Sample results http://www.freeimagehosting.net/uploads/224d342eba.png

Итак, что случилось с ним? Есть ли ошибка в Attachment.Size? Или, может быть, ожидается, что он даст что-то иное, чем размер привязанности?

Я думал, что он преобразует CR в CRLF, включая двоичные файлы, что может объяснить накладные расходы, но некоторые вложенные файлы находятся в необработанном текстовом формате с CRLF, поэтому эта гипотеза неверна.

---

Первый редактировать:

Это не Base64 кодирование, потому что Base64 кодирование будет:

• 4/3 отношение. В моем случае у меня есть отношение, которое не так далеко от 1.0.
• Пропорциональный. Это не так: файл 1,9 МБ имеет накладные расходы 181 байт, тогда как у файла размером 27 КБ есть накладные расходы в размере 3 КБ.

Теперь, глядя на почти случайные издержки в диапазоне от 89 до 3658 байт, я бы согласился, что это могут быть некоторые странные заголовки.

---

Второе редактирование:

Я испытал это на большом наборе файлов. Я замечаю, что разница между реальным размером файла и размером, указанным в Outlook:

• Всегда равен нулю для приложения .msg. Но приложение .msg - очень особенный случай и имеет очень странное поведение.
• Это влияет на расширение файла и длину имени файла.
• Для того же расширения файла, в большинстве случаев, но не всегда, больше, когда длина имени файла больше.

Вот пример:

alt text http://www.freeimagehosting.net/uploads/a767d3cacf.png

ИМХО, Outlook делает что-то с именем файла, какой-то очень странной кодировке, может быть, поколение уникального идентификатора основе по имени файла. Это означает, что:

• , когда файл больше, уникальный идентификатор тоже больше.
• Когда происходит столкновение, что-то происходит с уникальным идентификатором, что делает его намного больше: строка 18 имеет то же имя файла, что и строка 11, но файл не совпадает; С другой стороны, строки 12, 13 и 14 имеют один и тот же файл.

Answer 1

Я не уверен, но я бы предположил, что это могут быть заголовки MIME и/или кодирование накладных расходов. Для получения дополнительной информации см. Статью this Wiki о Base64 и найдите служебные данные.

Редактирование: Извините, я был не очень ясен, я имел в виду статью Base64, как пример того, что могут быть накладные расходы, связанные с кодировкой, а не то, что на самом деле это Base64, поскольку, как упоминалось другими, накладные расходы Base64 вероятно, намного больше, чем эти различия.