I am trying to load base64 encoded data in a webview.Following is the code i am using
NSDictionary *fileFormatDic=[[NSDictionary alloc]initWithObjectsAndKeys:#"text/html",#"html",#"mage/jpeg",#"jpe",#"image/jpeg",#"jpeg",#"image/jpeg",#"jpg",#"application/pdf",#"pdf",#"application/vnd.ms-powerpoint",#"pdf",#"text/plain",#"txt",#"application/vnd.ms-excel",#"xls",#"application/msword",#"doc",nil];
NSData *fileData= [dbServiceMgr getDocumentDataForTheTaskId:[_fileDetailsDic objectForKey:#"taskId"] andFileId:[_fileDetailsDic objectForKey:#"fileId"]];
NSLog(#"filedata length---%d",fileData.length);
NSString *mimeType=[fileFormatDic objectForKey:[_fileDetailsDic objectForKey:#"fileFormat"]];
[_webView loadData:fileData MIMEType:mimeType textEncodingName:#"Base64" baseURL:nil];
But nothing is displayed in my webview. Can someone tell me, what is going wrong. Thanks in advance
I'm not sure that this is the reason for which you get a white screen (could be) but you must understand that textEncodingName expects a text encoding (meaning a method to encode a Unicode string to byte sequences) and you are providing a binary data-to-text encoding. So it's a different kind of encoding so to speak. Valid values would be UTF8 or UTF16 (althoulgh UTF8 is what you usually want). So, you should first decode your Base64 data and then present it to the screen.
You can read more about Unicode encodings here.
Related
I had my server encoding in ISO-8859-1 and decided to chango into UTF-8. The problem is that the filenames creates in ISO now crashes because I change the encoding type in my code. I try to connect with an iOS app and show the directories and files, the news are shown well but the olds with ISO not.
How can I detect if the filename is in one or other encoding to process in the right way each one? Because now, the filename in ISO it can be represent in UTF-8 but the string to access is not the same. (Ex: %E1p%F1 --> %C3%A1p%C3%B1)
I try this, but it doesn't work:
NSString *isoL = [item.href stringByAddingPercentEscapesUsingEncoding:NSISOLatin1StringEncoding];
char const *iso2utf = [isoL UTF8String];
NSString *utf = [[NSString alloc]initWithCString:iso2utf encoding:NSUTF8StringEncoding];
You need to have the server declare the content encoding of the response, much like how HTTP does.
I don't believe it's possible to auto-detect ISO-8859-1/UTF-8 text encoding.
I am getting this kind of data ElbowWristHand_DeQuervian\U00e2\U0080\U0099s Tenosynovitis through a web service, But actually the content is "ElbowWristHand_DeQuervian's". I have followed all the methods mentioned in the following link:
Using Objective C/Cocoa to unescape unicode characters, ie \u1234
but still i am unable to convert the unicode characters to the proper string. Please suggest.
Thanks
While initializing string us unicode string encoding -
NSString *dataString = [[NSString alloc] initWithData:recievedData usingEncoding:NSUnicodeStringEncoding]
In my app I need to send some parameters to the url, when I am trying with the stringByAddingPercentEscapesUsingEncoding it is not converting correctly. If I am not using this encoding I am getting null(Exception) from the nsurl.Here is me code.
http://www.mycompurl.co?message=xyz&id=____ here I am sending the id 1 or 2 or any number.
when I convert this string to url by using stringByAddingPercentEscapesUsingEncoding I got
"http://www.mycompurl.co?message=xyz&id=**%E2%80%8B**1" (when I send 1 as parameter). Then I got the 0 data from the Url.
str = [NSString stringWithFormat:#"%#?message=xyz&id=%#",Application_URL,bootupdateNew];
str = [str stringByAddingPercentEscapesUsingEncoding: NSUTF8StringEncoding];
url=[NSURL URLWithString:str];
NSError* error = nil;
data1 = [NSData dataWithContentsOfURL:url options:NSDataReadingUncached error:&error];
Thank you In advance
Basics
A URL is composed of several components.
Each component has its own rule how the component's source string must be encoded, so that this component becomes valid within the URL string.
Applying stringByAddingPercentEscapesUsingEncoding: will never always produce a correct URL if the string consists of more than one component (and if we assume, we have an unbounded set of source strings - so that the encoded string actually differs from the source string).
It even won't work always with a string which represents any single component.
In other words, for what's worth, stringByAddingPercentEscapesUsingEncoding: should not be used to try to make a URL out of several components. Even getting the URL query component correctly encoded is at least error prone, and when utilizing stringByAddingPercentEscapesUsingEncoding: it still remains wonky. (You may find correct implementations on SO, though - and I posted one myself).
But now, just forget about it:
It took awhile for Apple to recognize this failure, and invented NSURLComponents. It's available since iOS 7. Take a look! ;)
Here is how I encrypt the string:
+ (NSString *)encrypt:(NSString *)message password:(NSString *)password {
NSData *encryptedData = [[message dataUsingEncoding:NSUTF8StringEncoding] AES256EncryptedDataUsingKey:[password dataUsingEncoding:NSUTF8StringEncoding] error:nil];
NSString *base64EncodedString = [NSString base64StringFromData:encryptedData length:[encryptedData length]];
return base64EncodedString;
}
The plain text is:
{"roomID":"{\"array\":[\"949156\",\"949157\"]}","duration":15,"link":"","type":"text","thumbnailBlobID":"","posy":103.6809424405021,"text":"Aa","className":"Message","originalBlobID":"","datetime":"20140319214528457","selfDestructive":0,"userID":"949157","posx":1.347154229880634,"status":"normal","entityID":"20140319214528457and949157and{\"array\":[\"949156\",\"949157\"]}"}
This is what I get
gXqxfDhImRD7S20lUdYuCPAlXfqRnG6xk4w4K5Op/WnYMh6VgJUUqMifK2vHkUpAbnZ+wKdSWjfzU1PuOwvJ4dJ9EiHwjeyyorezFNG6eylYcOvMWNeU6+5Z9XxfcFngqhmxM6k1lf7bkttTu0FnEHad/czFgiMVTy60DJpFMLSODkKEVezqQB9s/f3Qy/B6+sF5Hs5E0FDn7kU6Jtm6mLkFjGzDCXTdFXNjdussbkTL8C1gcOnn4hrNkqQKb82MgqqYf8sVgs4FVIjsmoJd0ALY8y/5QbBkgc6ZyB4aOQPPx/u4HS3F7HXHkIkkAjZS/hiHQBRyfwCvi2uwFedno5twYogNW56pSMQqBeJBxBAhPMpXzb51853GLP4bCotGtOyEfU96x5kWHDOR5QA2WhYZkB3AALDJ2kfqzWR8iOKHo3zE6DCQ7aH0RwEFlNPi8vsNwvUqtQ7nUODA5lUMYah6W2rfDh/em8BD8dGF5J6IUTIlSerx8wWPA9bn/SxO
From website http://aesencryption.net (256 bit)
(Which i assume to be the correct answer
5MdV0TelF++/8Cy9bnkeah0nQ5JbC04CEdCcHfdlavQtZaxg3ZSXklp9yXbeP05hcIeQDgFcMr9NlD6aKhjBL3Xh70ksYqc6Xv5BZvCbXrvO4ufAf4gjmDRQr9DYSbjFct6N82fFGDtrcuFm36Zv+QAQtR/scT86A++Vn/EBlPwFb7ZmxlMPkJWjQ98ObreXHeKkZ8f2npMKfJ0i36nIZ8CZeL0EYeg/njo9ykPTfm9wfKieqlIICn1qNZAXE//P9hTleW/GNs5+ET2gxNSCmdO+ByUB9Q3sZ/+57qXbsfCxHr8dsuBrsbRI+cVIXyquQL1IC/zuz3G3fcyoiLrD/PnFtV5z5XR0hpUiU8JjovjYwyXaBfyTBnO71zxmdoZdsyPwA1LQO0pedn8UsICT2KbfBKwuumW2CJPexbnMmVzpIJ/VPISikdg18V3rdJqiPMIb4Zq2PGKO0Wtq1dCTMusTv/ZnqxgVQFQlUivgBqtnOLCDaMAGL636NXda95V2
There is no single standard way to apply AES, or standard data format for the output. AES requires a number of helpers when used on data that is not exactly 16-bytes long, and they can be configured in different ways. I have no idea how the aesencryption.net tool is applying these helpers; it doesn't say. If AES256EncryptedDataUsingKey: is the particular piece of code I assume it, it applies them very poorly (it's very similar to the code I discuss in Properly Encrypting With AES With CommonCrypto). I would not be surprised if aesencryption.net does something different.
If you have a piece of plaintext and a key, and you pass it to an encryptor twice and get the same answer back, then your encryptor is broken. A correct AES encryptor (for almost any common use of AES) should always return different results for the same plaintext+key (otherwise an attacker can determine that two plaintexts are equal, which breaks the security proof of AES). In the most common case, this is achieved by having a unique initialization vector (IV). For password-based AES, you also include a random salt. So even if these were good implementations of AES, you wouldn't expect your results to match.
Is it possible that the escape characters (the back slashes) are being interpreted differently in code versus via the web? The bottom line here is I would (in code) decode what you just encoded and you should come out with the same as what you put in. This is probably the test you want to conduct. Hope this helps. Also see comment below from #RobNapier
I am working on an iPhone app which allows people to send messages with Emoji icons. I saved the icon in Mysql with charset utf8mb4 and collation utf8mb4_unicode_ci, and all the emoji icons is saved correctly in my database. However, when I return json back to the client (php json_encode), the Emoji is encoded as something like this: '\ud83d\ude04', and iPhone displays it as a square. However, if I return as XML, the Emoji Icon won't become unicode like this: '\ud83d\ude04', it will just be the icon.
I am wondering if this is an issue on my server, or on my client. If it is my client, how can object c decode it correctly.
Can someone please help?
Thanks
"\ud83d\ude04" is the JSON Unicode escape sequence for U+D83D U+DE04, which is the "surrogate pair" for the Unicode U+1F604 (SMILING FACE WITH OPEN MOUTH AND SMILING EYES).
But NSJSONSerialization decodes this correctly, as can be seen in the following example:
const char *jsonString = "{ \"emoji\": \"\\ud83d\\ude04\" }";
NSLog(#"JSON: %s", jsonString);
NSData *jsonData = [NSData dataWithBytes:jsonString length:strlen(jsonString)];
NSError *error;
NSDictionary *jsonDict = [NSJSONSerialization JSONObjectWithData:jsonData options:0 error:&error];
self.myLabel.text = [jsonDict objectForKey:#"emoji"];
NSLog(#"Emoji: %#", self.myLabel.text);
Output:
JSON: { "emoji": "\ud83d\ude04" }
Emoji: 😄
and the Emoji symbol is also displayed correctly (tested with iPhone device and Simulator).
Please follow following steps:
Convert Emoji characters to base64 and send to server using Json.
On server side save base64 in database without decode.
When you want to display Emoji on Application then retrieve same base64 data from server.
Decode retrieve string and display on app.
Your Emoji character will display properly.
Note: When you want to Show on webPage then Decode data when you display data on WebPage.
Our team fixed this problem by transfer utf data to server, saving them in mysql utf8mb4 codepage and receiving with base64. Server convert saved data to base64 on demand.