1
試圖在C＃中使用Outlook Interop，我注意到一件奇怪的事情。爲什麼Outlook編程接口提供的附件大小總是錯誤的？
- 首先我得到與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具有相同的文件。
第7排的排列比其他的要大得多。該文件與其他文件有什麼不同？文件類型，編碼等？ – cHao 2010-06-20 09:05:27
@cHao：第7行是一個PNG圖像。表格中沒有其他PNG圖像。 – 2010-06-20 11:35:04