¿Por tamaño de archivo adjunto dada por la interfaz de programación de Outlook siempre es malo?

Question

Tratar de utilizar Outlook interoperabilidad en C #, me di cuenta de una cosa curiosa.

• Primero obtener el tamaño de un archivo adjunto con Attachment.Size propiedad .
• En segundo lugar, guardar el archivo adjunto en un archivo utilizando método Attachment.SaveAsFile .

Al comparar el tamaño real de un archivo guardado y un tamaño dado por Outlook, noto que el archivo real, ahorrado es siempre menor de lo esperado de Attachment.Size. Los archivos guardados parecen ser válida y no truncada.

Resultados de muestra http://www.freeimagehosting.net/uploads /224d342eba.png

Así que, ¿qué pasa con ella? ¿Hay un error en Attachment.Size? O tal vez se espera para dar algo más que el tamaño de un archivo adjunto?

pensé que convierte a CRLF CR, incluyendo archivos binarios, lo que puede explicar la sobrecarga, pero algunos archivos adjuntos están en formato de texto sin formato con CRLF, por lo que esta hipótesis es incorrecta.

---

Primera edición:

No es la codificación Base64, porque la codificación Base64 sería:

• relación de 4/3. En mi caso, tengo una relación que no está tan lejos de 1.0.
• proporcional. No es el caso aquí:. Un archivo de 1,9 MB tiene una sobrecarga de 181 bytes, mientras que un archivo de 27 KB tiene una sobrecarga de 3 KB

Ahora, mirando a la cabeza casi al azar en un rango de 89 a 3658 bytes, estaría de acuerdo en que podría ser algunas cabeceras extraños.

---

Segunda edición:

He probado esto en un conjunto más amplio de archivos. Lo que noto es que la diferencia entre el tamaño real de archivo y el tamaño determinado por Outlook:

• ¿Es siempre cero para un archivo adjunto .msg. Pero el apego .msg es un caso muy especial y tienen un comportamiento muy extraño.
• es influenciada tanto por extensión de archivo y la longitud del nombre del archivo.
• Por la misma extensión de archivo, es decir, en la mayoría de los casos, pero no siempre , más grande cuando la longitud del nombre del archivo es más grande.

Este es un ejemplo:

texto alternativo http://www.freeimagehosting.net/ uploads / a767d3cacf.png

En mi humilde opinión, Outlook algo con el nombre del archivo, algún tipo de codificación muy extraño, tal vez una generación de un identificador único basado en el nombre de archivo . Esto significa que:

• Cuando el archivo es más grande, el identificador único es más grande también.
• cuando la colisión ocurre, algo que ocurre con el identificador único, lo que es mucho, mucho más grande: la fila 18 tiene el mismo nombre de archivo que la fila 11, pero el archivo no es lo mismo; Por otro lado, las filas 12, 13 y 14 tienen el mismo archivo.

Answer 1

No estoy seguro, pero me gustaría suponer que podría ser cabeceras MIME y / o codificación de arriba. Para obtener más información, ver este artículo Wiki sobre base 64 y la búsqueda de la palabra de arriba.

Edit: Lo siento, yo no estaba muy claro, me refería a la base 64 del artículo simplemente como un ejemplo de que puede haber gastos indirectos relacionados con la codificación, no que en realidad era base 64, ya que, como han mencionado otros, Base64 sobrecarga probablemente sería ser mucho más grande que esas diferencias.