Can we get Attachment FileSize in IMessageSummary BodyPartBasic??

[tinmac]

I would like to show attachment file size in bytes but only using IMessageSummary ie so we don't have the overhead of downloading the message.

I looked at IMessageSummary.Attachments[n].BodyPartBasic it has the Octets property, but this doesn't seem to reflect the actual filesize of the attachment as its byte size value is usually about 30% higher than the files in question, presumably meta data is in that octets value too? ie a 1.69MB attachment has an Octets value of 2429802 which is 2.43MB

Am I looking at this Octets value wrong?

If Octets is unusable for this is there a way to get the attachment file size from a summary or do I have to download the message?

[jstedfast]

but this doesn't seem to reflect the actual filesize of the attachment as its byte size value is usually about 30% higher than the files in question, presumably meta data is in that octets value too? ie a 1.69MB attachment has an Octets value of 2429802 which is 2.43MB

BodyPartBasic.Octets is the size of the body part in its transfer encoded state (and not the size that it would be decoded).

I'll add a note to this effect in the documentation.

If Octets is unusable for this is there a way to get the attachment file size from a summary or do I have to download the message?

Unfortunately, there is not.

As you've discovered, though, base64 encoding data tends to result in a size that is roughly ~33% larger than the original data (that's because for every 3 input bytes, it outputs 4 bytes of encoded data - and then every ~57 input bytes or so, there is also a newline sequence added which is an additional 2 bytes <CRLF>).

[tinmac]

Thanks for the clarification, it was a long shot.

I do however (because file size is not critical) feel a wee maths hack coming on

EDIT:

I know this is not exact but I multiplied Octets by 0.73 (to achieve a 27% reduction) and its pretty damn close, close enough for my purpose. Of course we cant be rely on this and its better to download the attachment if the exact file size is required

[jstedfast]

FWIW, MimeKit and probably other clients do a bit of math to figure out which encoding mechanism to use (base64 vs quoted-printable). If the number of bytes that need to be encoded is > 17%, then MimeKit opts for base64, otherwise it opts for quoted-printable.

The quoted-printable encoding transforms every byte that needs to be encoded into 3 bytes (=XX where XX is the hex representation). That might help with calculating a reduction for quoted-printable. Then again, that's kinda hard because it could be just 1 byte that needed encoding for all you know. So maybe leave that one alone.

Note: quoted-printable only really works for text parts