尝试在 C# 中使用 Outlook 互操作时，我注意到了一件奇怪的事情。
- 首先，我使用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 MB 的文件有 181 字节的开销，而一个 27 KB 的文件有 3 KB 的开销。
现在，看看 89 到 3658 字节范围内的几乎随机开销，我同意它可能是一些奇怪的标头。
第二次编辑：
我在一组更大的文件上对此进行了测试。我注意到的是 Outlook 给出的实际文件大小和大小之间的差异：
- 对于 .msg 附件，始终为零。但是 .msg 附件是一种非常特殊的情况，并且具有非常奇怪的行为。
- 受文件扩展名和文件名长度的影响。
- 对于相同的文件扩展名，在大多数情况下，但并非总是如此，文件名长度越大则越大。
这是一个例子：
替代文字 http://www.freeimagehosting.net/uploads/a767d3cacf.png
恕我直言，Outlook 对文件名做了一些处理，某种非常奇怪的编码，可能是基于文件名的唯一标识符的生成。这意味着：
- 当文件更大时，唯一标识符也更大。
- 当发生冲突时，唯一标识符会发生一些事情，使其变得非常大：第 18 行与第 11 行具有相同的文件名，但文件不同；另一方面，第 12、13 和 14 行具有相同的文件。