IBM Worklight - Error charset/encoding in data response from webservice

Question

I use IBM worklight to develop a hybrid app. In the local development environment everything is OK.

I have an issue when I deploy to an external server (with oracle database). My app calls a webservice via an adapter, but the data in the response has an encoding problem: unicode characters do not display correctly. I changed the charset (in the adapter invoke function) to ISO-8859-1, and then unicode characters display correctly.

function invokeWebService(body, headers, soapAction) {
var input = {
    method : 'post',
    returnedContentType : 'xml',
    path : '/transaction/services/TransactionService.TransactionServiceHttpSoap11Endpoint/',
    body: {
        content : body.toString(),
        contentType : 'text/xml; charset=ISO-8859-1'
    }
};

//Adding custom HTTP headers if they were provided as parameter to the procedure call
//Always add header for SOAP action 
headers = headers || {};
if (soapAction != 'null')
    headers.SOAPAction = soapAction;
input['headers'] = headers;

return WL.Server.invokeHttp(input);
}

However the problem then happens again when I want to insert data to database (oracle with default charset UTF-8). The data has been inserted with error charset (because ISO-8859-1).

How can I get data response correct charset with UTF-8 without having to change the encoding from the webservice?

Or get data with ISO-8859-1 charset and insert data to database with UTF-8?

If I use contentType : 'text/xml; charset=UTF-8', data return from webservice has display error. It's only happen on deploy server worklight. On local is OK — Kenshichi, Sep 10 '15 at 09:30
This doesn't answer your question, but to be clear, contentType describes what type of data you are *sending* from the adapter to the webservice (in other words, the result of body.toString()). It has nothing to do with what your webservice sends back (which is specified by the Accept: header). If your webservice is responding differently, it's only because it's interpreting your input differently (or it's in some other way faulty). — Andrew Ferrier, Sep 10 '15 at 10:39
Yes. That's best solution. But I don't know how to config all to UTF-8 — Kenshichi, Sep 12 '15 at 04:48

score 1 · Answer 1 · edited May 23 '17 at 12:15

1

@Idan Adar It's a solution for system use Liberty but I use tomcat. I have found solution for it. Just change Tomcat's default charset:

set "JAVA_OPTS=%JAVA_OPTS% -Dfile.encoding=UTF8"

Change Tomcat's Charset.defaultCharset in windows

edited May 23 '17 at 12:15

Community

1
1

answered Sep 15 '15 at 02:55

Kenshichi

11
2

score 0 · Answer 2 · answered Sep 10 '15 at 10:54

This may be due to the encoding of what Andrew mentioned, but because you say this is working in the development server but failing in the remote server, you may want to attempt the following.

If the remote server is WebSphere Liberty, locate the jvm.options file and add the following:

-Dfile.encoding=UTF-8
-Duser.language=en
-Duser.country=US

If the remote server WebSphere ND, there is an Admin panel where you can set the encoding at. Consult with the WebShere documentation: http://www-01.ibm.com/support/knowledgecenter/SSEQTJ_8.5.5/com.ibm.websphere.nd.doc/ae/xrun_jvm.html

Of course, also revert any changes you did previously...

Thank @Idan Adar alot. I'ld try it ^^ – Kenshichi Sep 12 '15 at 04:48 — Kenshichi, Sep 12 '15 at 04:48
It's a solution for system use Liberty but I use tomcat. – Kenshichi Sep 15 '15 at 02:56 — Kenshichi, Sep 15 '15 at 02:56

IBM Worklight - Error charset/encoding in data response from webservice

2 Answers2

Linked