Base64-Codierung auf dem iPhone, arbeitet im Simulator, bricht auf dem Gerät

Question

ich den einfachen SMTP-Client-Code verwenden, zuerst auf Google Code veröffentlicht unter:

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

Das scheint Repo unmaintained gegangen zu sein, als Der Projektbesitzer ist jetzt bei Apple beschäftigt und hat vielleicht bessere Dinge zu tun. Es ist ein Fork des Codes ist, dass in jüngster Zeit bei Github gehalten, was finden Sie unter:

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

Ich habe Probleme, Anhänge immer auf dem iPhone-Gerät zu arbeiten, dachte seltsam sie in der Arbeit Simulator. Mein Github Kommentar ist hier zu finden:

http://github.com/kailoa/iphone-smtp/commit/50cbd49f351c2f0bb3a5ad6aea7736ac82d40af2#comment_27560

Mit allem, als Kontext ... meine Frage ist: hat jemand in der Lage gewesen, erfolgreich eine Datei anhängen (vorzugsweise eine Audiodatei, aber jede Datei für tun jetzt) ​​an eine E-Mail gesendet mit einem SMTP-Client auf dem iPhone? Ich möchte wirklich Dateien an E-Mails anhängen können, die ich mit einem direkten SMTP-Client sende, aber bis jetzt habe ich noch keinen Code gefunden, der richtig funktioniert und funktioniert, und ich konnte meinen eigenen Code nicht erfolgreich schreiben sagte Meisterstück.

Gibt es einen Grund, warum Dateien auf dem iPhone anders kodieren als im Simulator? Denn wenn ich mir die rohe base64-Zeichenfolge anschaue, die in beiden Kontexten erstellt wird, unterscheiden sie sich. Ich bin nur verloren, warum das der Fall wäre.

Der relevante Teil meines Codes ist dies:

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]; 

Wenn mehr Code oder Referenzen sind notwendig, um dies herauszufinden, ich bin das Hinzufügen glücklich zu halten. Aber der ganze Code ist auf GitHub verfügbar, so dass jeder, der daran interessiert ist, alles sehr leicht sehen kann.

Dank Ryan

Answer 1

es könnte sein, dass Sie [imgData encodeWrappedBase64ForData] anstelle von [imgData encodeBase64ForData], das ist das Problem der Typ here hatte verwenden müssen.

Answer 2

Haben Sie nach endianness gesucht?

Der Code läuft auf zwei verschiedenen Architekturen; im Allgemeinen, wenn Sie Maschinen wechseln, könnten ein paar Dinge sich ändern:

• die Größe bestimmter Arten, wie CGFloat s oder Zeiger
• die Standard-Codierung Byte-Reihenfolge innerhalb von Worten (endianness)
• locale- sensitive Daten
• Gespeicherte Präferenzdaten
• andere definierte Konstanten innerhalb des Codes.

und wahrscheinlich ein paar mehr.

Wie debuggen Sie das genauer? Zwei Ideen:

1. Ist es wirklich ein Fehler?Wenn es auf dem Gerät wie vorgesehen funktioniert, lohnt es sich, die Zeit auf dem Simulator zu "reparieren"?
2. Wenn ja, dann könnten Sie das erste Byte finden, das anders codiert ist (diff kann helfen), und legen Sie einen Haltepunkt auf dem Code der niedrigsten Ebene fest, auf den Sie Zugriff haben, der Bytes setzt. Ich gehe davon aus, dass Sie Zugriff auf diese Funktionalität haben, da ich sie im SDK nicht kenne. Sobald Sie diesen StackTrace auf beiden Rechnern haben, können Sie rückwärts arbeiten, Schlüsselvariablenwerte in den signifikanten Frames prüfen und herausfinden, woher der Unterschied stammt.