Base64 encoding on the iPhone, works in simulator, breaks on device

Question

Hi

I am using the simple SMTP client code, first posted on google code at:

http://code.google.com/p/skpsmtpmessage/

That repo seems to have gone unmaintained, as the project owner is now employed at apple, and maybe has better things to do. There is a fork of the code, that is more recently maintained at github, which you can find at:

http://github.com/kailoa/iphone-smtp/tree/master

I am having trouble getting attachments to work on the iPhone device, thought oddly they work in the simulator. My github comment can be found here:

http://github.com/kailoa/iphone-smtp/commit/50cbd49f351c2f0bb3a5ad6aea7736ac82d40af2#comment%5F27560

With all that as context...my question is: has anyone been able to successfully attach a file (preferably an audio file, but any file will do for now) to an email, sent with a SMTP client on the iPhone? I really want to be able to attach files to emails that I send with a direct SMTP client, but so far I have yet to find any code that correctly functions and works, and I have not been able to successfully write my own code to accomplish said feat.

Is there any reason why files would encode differently on the iPhone than in the simulator? Because when I look at the raw base64 string that is created in both contexts, they are different. I'm just lost as to why that would be the case.

The relevant portion of my code is this:

NSString* emailBody = @"This is a test email body";

NSDictionary *plainPart = [NSDictionary dictionaryWithObjectsAndKeys:@"text/plain",kSKPSMTPPartContentTypeKey, emailBody,kSKPSMTPPartMessageKey,@"8bit",kSKPSMTPPartContentTransferEncodingKey,nil];

NSString *imgPath = [[NSBundle mainBundle] pathForResource:@"screenshot" ofType:@"png"];

NSData *imgData = [NSData dataWithContentsOfFile:imgPath];

NSDictionary *imgPart = [NSDictionary dictionaryWithObjectsAndKeys:@"image/png;\r\n\tx-unix-mode=0644;\r\n\tname=\"screenshot.png\"", kSKPSMTPPartContentTypeKey, @"attachment;\r\n\tfilename=\"screenshot.png\"", kSKPSMTPPartContentDispositionKey, [imgData encodeBase64ForData],kSKPSMTPPartMessageKey, @"base64",kSKPSMTPPartContentTransferEncodingKey,nil];

testMsg.parts = [NSArray arrayWithObjects:plainPart,imgPart,nil];

If more code or references are necessary to figure this out, I'm happy to keep adding. But all the code is readily available on github, so anyone who is interested in this can see everything very easily.

Thanks Ryan

Answer 1

it might be that you need to use [imgData encodeWrappedBase64ForData] instead of [imgData encodeBase64ForData], that's the problem the guy here was having.

Answer 2

Have you checked for endianness?

The code is running on two different architectures; in general, when you switch machines, a few things could be changing:

• the size of certain types, like CGFloats or pointers
• the default encoding byte order within words (endianness)
• locale-sensitive data
• stored-preference data
• other defined constants within the code.

and probably a few more.

How to debug this in more detail? Two ideas:

1. Is it really a bug? If it works on the device as intended, is it worth your time to "fix" on the simulator?
2. If yes, then you could find the first byte that's being encoded differently (diff can help), and set a breakpoint at the lowest-level code you have access to which sets bytes. I'm assuming you have some access to this functionality since I'm unaware of it in the SDK. Once you have that stacktrace on both machines, you can work backward, checking key variable values in the significant frames, and figure out where the difference originated.

Answer 3

Hi All,

I am having the same issue; I downloaded the code from http://github.com/kailoa/iphone-smtp/tree/master - which has the sample application which uses the SMTP client;

The sample app works great on Simulator (the encoded image can be decoded by mail applications) BUT when I run the sample app on the real phone the attached image is corrupt (the binary is different from the one that the application creates when running on the real phone.)

Any thoughts on this? Yes, endianness sounds promising but was anyone able to resolve this?

Thanks for the help,

-tunc