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

Question

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

• 首先，我使用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 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

我不确定，但我认为它可能是MIME标头和/或编码开销。有关更多信息，请查看有关Base64的this Wiki文章，并搜索单词开销。

编辑：对不起，我不是很清楚，我的意思是Base64文章只是作为一个例子，可能有与编码相关的开销，而不是它实际上是Base64，因为正如其他人所说，Base64开销可能比这些差异要大得多。