Exact text written on admin panel is Test’s, and our PHP server is using utf8_encode() method to encode this text, which results in response on mobile end like ::
Test\u00e2\u0080\u0099s
How could I decode it back to ’ to display on mobile app ?
I have tried so many solutions given including utf8 decoding, but it's not working, please help.
I also tried solution given in How to replace the \u00e2\u0080\u0099 this string into ' in iOS, but this solution is for only a specific character, and I am looking for some generalize solution, replacement of \u00e2\u0080\u0099 with ’ seems to be a temporary solution as it don't assure if I get some other unicode in response.
As per the OP...
The problem was with the server encoding, and not on the decoding end.
I'm adding this as an answer so other folks don't have to dig through the comments.
Related
I am working with 3rd party integrations which require encoding my payload to base64 format. I am using Rails to do this
Base64.encode64("No way") # output: "Tm8gd2F5\n"
Most of the 3rd parties I've worked with do not have any problem with this, however, a few do have problems decoding the encoded value with \n. After facing the issue, I found another version of base64 encoding called strict_encode64
Base64.strict_encode64("No way") # output: "Tm8gd2F5"
which solves the problem.
I am wondering why \n is added to the encoded string.
encode64 uses Array#pack under the hood. It uses the 'm' directive which according to the docs has the rather obscure note "if count is 0, no line feed are added, see RFC 4648". Taking a punt, the reverse might be true - if the count > 0 then add a new line. I've looked through RFC 4648 and can't find any mention of this, but I'm guessing it must in there somewhere.
Sorry if none of that helps. Went down the rabbit hole on this, but maybe there are some crumbs in there that are useful.
Edit: seems that Python also does this and it appears to be deliberate (is specified in their unit tests). So this looks even more like it's related to RFC 4648 (or maybe RFC 2045), but I can't for the life of me find any mention of it in either RFC.
Try to use Google to find Wikipedia article about De Morgan's laws.
Click the link, and see the URL. At least in Chrome, it will be
https://en.wikipedia.org/wiki/De_Morgan%27s_laws
' is percent-encoded as %27, despite it is a valid URL character (and even more, if you manually change it in address bar from %27 to ', it will work). Why?
While aposthrope may be valid char, URL-encoded version is also equally valid!
Not sure if there is a hard reason, so this is kinda "soft" answer: Aposthrope (and/or double quote) needs to be escaped somehow if URL is ever put into for example JSON or XML. URL encoding them as part of sanitizing URLs solves this one way, and protects against poor JSON/XML handling and programmer errors. It's just pragmatic.
Decoding these certain valid chars in HTTP responses' headers etc (so browser shows them "right") should be possible and maybe nice, but extra work and code. Note that there are also chars where decoding would not be ok, so this would have to be selective! So at least in this case it just wasn't done I guess. So if a char gets URL-encoded at any step of the whole page loading operation chain, they stay that way.
I tried to use Unicode characters in my FTP server's greeting, but the client seems to read them as two different characters each. Because of this, I need a way to encode them into UTF-8. For now, I have the greeting HTML encoded because I am displaying it on a webpage, but on any other client it will display the encoding. How can I set the greeting to be parsed as UTF-8? And if I can't, then is there a way I can parse the greeting correctly?
EDIT: Answered my own question, see below.
I found the answer to the question. It was actually UTF-8 encoded already, and I had to decode it from UTF-8. Here is what I did:
decodeURIComponent(escape(greeting))
Don't forget to replace the line breaks with <br> if you are displaying it on a webpage like I am!
decodeURIComponent(escape(greeting)).replace(/\n/g,'<br>')
I'm looking for a datausingencoding parameter that doesn't swallow up plus signs. I was using NSASCIIENCODING but since I'm trying to send a uiimage to the server and the base64 string had plus signs in them, it seems like that form of encoding takes out the plus sign sending a modified encoded string to the server thereby not allowing the image to be decoded server side. I'm looking for something that won't alter the base64 string.
Nevermind guys, here is the solution I found on stackoverflow
thanks, now I figured it out. It seems I needed to run my string through the stringByAddingPercentEscapesUsingEncoding: first, then I needed to run it through replaceOccurrencesOfString:#"+" withString:#"%2B" and several more of those replaces for different characters, because stringByAddingPercentEscapesUsingEncoding: doesn't escape them all
I have a simple problem for that I'd like to hear your thoughts:
I have this URL in Rails http://example.com/hosts/show/somehost
I'm getting the 'somehost' part via params[:id]. I'm calling URI.encode on 'somehost' but this does not encode '.' characters. Rails won't recognize ID parts with points in it so I tried to replace the points with '%2E' - That works, but Firefox (and I guess other browsers too) changes the '%2E' back to points right after the request. This makes copy&paste impossible and will lead to a lot of problems.
I'd like to encrypt and decrypt the 'somehost' part in an URL-safe way - Any suggestions? I can't call by an numeric primary key because of the underlying architecture. I have to look up by name.
Thank you all very much!
You could use base64 encoding, but it would be better to fix the actual problem you are having. This issue is described here. You need to set a :requirements key for your routes file with a regex that includes the dot.