Hi all,
I am using native HTTP client (cordova-plugin-advanced-http) in my Ionic 3 project and I think I have found a problem with UTF8 chars on Android.
I am getting the data back from a POST call and the response is usually a JSON that I can parse with the normal JSON.parse function. Whenever there are some non-ascii chars inside (like à è ò ì ù) the json content is returned incorrectly as follows:
Actual data in the HTTP reponse:
{"activityResponse" :{"activityId":"2113000190","errorCode":"0002","errorDesc":"Guasto già chiuso"}}
Response.data from the native POST:
chiuso"}}
This problem seems to happen only on Android. The iOS side of the plugin is dealing with these chars just fine.
Unfortunately I have to use the native client for CORS issues and cannot switch back to the standard angular http client.
Anyone having a similar issue or ideas on how to solve it?
Thanks
Mat
in your request add headers with UTF-8 like this
var headers = new Headers();
headers.append('Content-Type', 'application/json; charset=UTF-8');
return this.http.post(this.url, body, { headers: headers }).map(res => res.json());
Thanks but that doesn’t seem to have any effect.
I tried both
let headers = {
'Content-Type': 'application/json; charset=utf-8',
'Accept-Charset': 'utf-8'
};
and
this.http.setHeader('*', 'Content-Type', 'application/json; charset=utf-8');
this.http.setHeader('*', 'Accept-Charset', 'utf-8');
Same results also with “UTF-8” instead of “utf-8”
The JSON is badly coded, it is a backend problem.
“Guasto già chiuso” = “Guasto gi\u00E0 chiuso”
Check this URL: https://www.freeformatter.com/json-escape.html#ad-output
Thank you, I am running extra test and see if something can be changed on the backend side. I still cannot understand why this is not giving any problem on iOS…
Hi,
It is a requirement of the json specs that all data use a Unicode encoding. You need to follow the format specs to work fine in all platforms.
Good luck!
Problem solved with an extra Content-Type header in the response (“application/json;charset=utf-8”). Apparently the encoding was ok, but the native Java client is using ISO-8559 as a default when nothing else is specified in the HTTP headers.