[TIMOB-14794] iOS: HttpClient responseText does not keep the correct encoding
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | High |
Status | Closed |
Resolution | Won't Fix |
Resolution Date | 2013-08-16T23:30:36.000+0000 |
Affected Version/s | n/a |
Fix Version/s | 2013 Sprint 17, 2013 Sprint 17 API |
Components | iOS |
Labels | n/a |
Reporter | Davide Cassenti |
Assignee | Sabil Rahim |
Created | 2013-08-09T15:38:45.000+0000 |
Updated | 2017-03-20T20:34:18.000+0000 |
Description
Problem description
Trying to load a document encoded not with UTF-8 (in the sample, Chinese Big5), the responseText returned is not shown correctly.Steps to reproduce
Use the following code:
var xhr = Ti.Network.createHTTPClient({
onload: function() {
alert(this.responseText);
}
});
xhr.open("GET", BIG5_FILE_URL);
xhr.send();
[~dcassenti] This request won't possible for us to fix. The response from the url does not contain any information about the encoding type or charset involved. Without this information we cannot find out what encoding to be used for the response. So we try to decode it using utf8 first and if that fails we try 8-bit ISO Latin 1 encoding. This is the default behavior. Here is the response header that we get back from the url. (lldb) po [request responseHeaders] { "Accept-Ranges" = bytes; Connection = close; "Content-Length" = 83254; "Content-Type" = "text/plain"; Date = "Fri, 16 Aug 2013 17:17:43 GMT"; Etag = "\"1c32204-14536-4e3ffa299d9c0\""; "Last-Modified" = "Thu, 15 Aug 2013 17:16:31 GMT"; Server = "Apache/2.2.24 (Unix) mod_ssl/2.2.24 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4 mod_jk/1.2.35 mod_fcgid/2.3.6"; } This ticket cannot be fixed unless some changes are done on the server side to include the encoding type or charset in the response header.
Closing ticket as the issue will not fix.