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

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

1 голос
/ 20 июня 2010

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

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

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

Примеры результатов 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 имеют один и тот же файл.

1 Ответ

1 голос
/ 20 июня 2010

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

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

...