为什么Outlook编程接口给出的附件尺寸总是错误的？

Question

尝试在C＃中使用Outlook Interop，我注意到了一个奇怪的事情。

• 首先，我得到了附件的大小 附件尺寸属性.
• 其次，我使用的附件将附件保存到文件 附件.

比较保存文件的实际尺寸和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附件是一个非常特殊的情况，并且具有非常奇怪的行为。
• 是 受影响 通过文件扩展名和文件名的长度。
• 对于同一文件扩展程序，在大多数情况下是 不总是, ，当文件名长度更大时，更大。

这是一个示例：

Alt Text http://www.freeimagehosting.net/uploads/a767d3cacf.png

恕我直言，Outlook确实 某物 用文件的名称，某种非常奇怪的编码，也许是一代唯一的标识符 基于文件名. 。这意味着：

• 当文件更大时，唯一标识符也更大。
• 当发生碰撞时，唯一标识符会发生某些事情，使其更大得多：第18行具有与第11行相同的文件名，但文件不相同；另一方面，第12、13和14行具有相同的文件。

Answer 1

我不确定，但是我认为这可能是哑剧标题和/或在开销上进行编码。有关更多信息，请查看 这 Wiki关于Base64的文章，并搜索“开销”一词。

编辑：对不起，我不是很清楚，我的意思是base64文章，只是一个示例，可能有与编码有关的高架，而不是实际上是base64，因为正如其他人所述，Base64开销可能会更大得多比这些差异。