Could not decode based64-encoded string by System.Convert.ToBase64String - ios

I am encountering an issue about based64 encode/decode for an image.
My iOS client downloads a string, which is a based64-encoded image on the server side by an API named System.Convert.ToBase64String.(dotnet)
However, some pictures could not be decoded on the client side by NSData.initWithBase64EncodedString. It always returns nil.
I have tried the same based64-encoded string on Android and some tools on the web, all works fine.
I have no idea how to debug this issue to figure out which byte causes this problem.
Any idea?

Related

How can I use JSONata in Electron?

I have gone to https://try.jsonata.org/ and copied the addresses json file. I have entered into my code the expression on the right side and run my app. I do not get the result in my app that is shown in https://try.jsonata.org/. So, I know this is a very generic question, but is there anything "special" I need to do to get JSONata to work in an Electron app?
Turns out that I was evaluating the stringified JSON. Once I evaluated on the actual JSON object, everything worked as expected.

Graph File Upload API - Images are getting corrupted

When I am trying to upload image using graph EndPoint then images are getting corrupted.
Endpoint - PUT https://graph.microsoft.com/v1.0/drives/{drive_id}/items/{item_id}:/{file_name}:/content
Anything I am missing here?
SharePoint Message When trying to view uploaded (through above code)image. Tried without encoding as well. Even file name is not encoded then also its same behavior.
Note - This issue is with only images. Other files like PDF, CSV are working fine.
Changing form-data to binary solved my problem.

Swift, image from URL returns nil due to corrupted file type hiding as JPG

I'm experiencing a large issue right now with XCode and just MacOS/iOS in general.
For background, the website application framework I'm using is laravel and the image editor I use to crop profile images is called image intervention, a quite popular extension for laravel.
To skip straight into it- I'm creating a basic companion application for my website, which, like pretty much all other websites, stores images on the server. This can be reached with the www.mywebsite.com/storage/ base URL, with the addition of the file name on the end. There is a bit more to it, but none of that is the issue.
I've been using it many times already, as there are multiple folders for different image relationships. One folder, lets just call it postimages (so link is now www.mywebsite.com/storage/postimages), returns images with no issue, and I've been using it multiple times up to this point. The code I use in swift to return the different images is as follows (in my specific views)
func getPic(urlLink: String)-> Image? {
let baseURL = "https://www.mywebsite.com/storage"
let url = URL(string: baseURL + urlLink)
let data = try? Data(contentsOf: url!)
let image = UIImage(data: data!)
let image2 = Image(uiImage: (image ?? nil)!)
return image2
}
So this might be badly written or whatnot, but that's definitely not the source of any issue, so approach it as you wish. Anyways, again, I've used this function in multiple views to retrieve multiple different images from different folders on the storage endpoint.
The issue just came up when trying to retrieve images from a different endpoint, specifically my /profileimages endpoint. Up until now, as I've stated, this function has never had an issue. Now, when I try to use it to get profile images, it crashes the app with the error
"Unexpectedly found nil while unwrapping an Optional value"
around the line where it is let data = try? Data(contentsOf: url!).
Now this gave me much grief because the URL (when hovered) showed the
correct URL link, and when I entered them into the browser it returned
the image in question. So why is the image somehow returning nil? I
don't know.
To add to the mystery, I've been trying to work around the issue, by downloading the default profile image and just changing the function to return the default image if there was no data at the URL (even though there should be, 100% of the time).
When I tried to download the default profile picture, by using the https://www.mywebsite.com/storage/profileimages/blank.jpg link, I tried adding it to XCode as an asset and it had a big red exclamation point over it. Trying to open it with preview gave me the error "The file "blank.jpg" could not be opened. It may be damaged or use a file format the Preview doesn't recognize." This is surprising because on my Windows computer, trying to do the same thing has no issue at all.
My suspicion is that because I used the extension to crop and fit the profile images to a square size, somehow in that process of saving it, image intervention corrupted the file, and while Windows recognizes it as JPEG, Swift does not.
I ask any of those who are more experienced with image manipulation please help me understand this, obviously displaying user's profile pictures is vital to creation of a website mobile companion application, and right now I can't do anything besides basic text tabviews without this working as intended.
I'm going to post my own answer as I've been able to solve the mystery. The first problem was the default image was, indeed, corrupted. I made a new one with GIMP and have been using that one instead. Why Windows could still open it and MacOS couldn't is beyond me, perhaps they have stricter guidelines for what constitutes a JPG file and therefore the file sneaks past Windows but not Mac, whatever the issue, obviously replacing the file solved my problem. The second issue was returning nil, which I found out was because I wasn't percent encoding the URL link. Some users post pictures with spaces in it, so I needed to add percent encoding in order for it to work (for some reason). Both of those solutions combined has removed the entire problem I was facing and I no longer have pictures returning nil.
I am facing same issue but I found solution, The image is in webp format, which is specially designed by google for chrome. iOS wont support webp.

AppMobi fails json parsing on iOS

I am developing a mobile app with the AppMobi tools and xdk. If I make a call to (accepts POST only) http://mg.smartmax.com/sightmaxwebservices/sightmaxwebservice.svc/jsoperator/TestjqMobi
The returned json fails parsing on iOS only (android works fine). This same call works fine in mobile safari, but it seems when its called from the app, it takes a different path and errors. This seems to be a known issue and was wondering if anyone had a good workaround?
I work at appMobi - this appears to be a bug with the native container in iOS. Have you tried building your app and testing (app*lab doesn't have the latest code base).
What are you using to parse the JSON? Something like
var obj = JSON.parse(data);
As a workaround for now I suppose you could just include and use another parser.
Make sure that your server is properly encoding the JSON.
I ran into this exact same issue. If you are using Drupal as your backend, use their function drupal_json_encode instead of PHP's json_encode. The information I was passing to the app was generated by a WYSYWIG editor, and perhaps that is what drupal's json encoding function takes into account that php's json encoding doesn't.

iOS NSJSONSerialization returning null

The App that I'm working on requires to parse a very big Json file (17.5 MB or 17mil characters).
I have coded and tested the App using smaller Json file and was successful doing the parsing, Only when I test using that 17.5 MB file it returns me null object.
I'm using iOS 5.1 and used JSON reader API of iOS 5.0 as well as JSONKIT which both return the same response, NULL.
Any advice would be highly appreciated
Thanks
If it is really a size problem you might break it into pieces on some natural boundaries. I have done that with large xml files in the past with good results.
But as #Alladinian mentions in the comments do verify that it is a valid JSON file.
fwiw, i recently uncovered a bug where NSJSONSerialization fails when the JSON file being parsed is > 32k in size. when we trimmed the source JSON down, the same code path works just fine.

Resources