IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
2 replies Latest Post - ‏2013-10-01T17:11:27Z by datacrush
3 Posts

Pinned topic How to set URL encoding to UTF-8

‏2013-10-01T13:39:31Z |


I'm on Websphere Liberty profile. Version
Requested for /res?val=%E4%B8%80 using Chrome and Safari browser.
HTTPServletRequest.getParameter(val) does not return the correct character. It should be Chinese character "一" but all that came out is gibberish. The hex value is c3a4c2b8c280 and the displayed character is "一" instead.
I've created a jvm.options file in the server directory with "-Dfile.encoding=UTF-8" defined in it.
I've also defined <webContainer decodeUrlAsUtf8="true" /> in server.xml.
It seems that there is a problem decoding character from the URL using UTF-8 as default.
It would work however if I write a HTTP client and manually insert a header to indicate charset=UTF-8. But this is not the default.
Appreciate any help. Thanks!
  • bergmark
    42 Posts

    Re: How to set URL encoding to UTF-8

    ‏2013-10-01T14:57:10Z  in response to datacrush

    WebSphere Liberty profile should decode URLs as UTF-8 by default. 

    I assume this is a GET request, and not a POST correct?

    Is it possible your problem is in how the response is encoded?  How are you "displaying" the character?  If you are writing it back in the response, then encoding used for the response could affect things as well.

    Does the output change if you call request.setCharacterEncoding to UTF-8 before calling request.getParamter?  Does the output change if you call response.setCharacterEncoding to UTF-8 before writing anything to the response writer?


    • datacrush
      3 Posts

      Re: How to set URL encoding to UTF-8

      ‏2013-10-01T17:11:27Z  in response to bergmark

      Thanks, request.setCharacterEncoding solved it.

      Yes, it is a GET.

      No, not displaying the character. I suspect Websphere should be running UTF-8 but "displaying" may not always be accurate. I used String.getBytes("UTF-8") and converted the byte[] to hex and display the hex instead. From there I could tell whether the character is correctly encoded in UTF-8.

      Using this method, it seems, I do not require a jvm.options file. Which is good. Because AS/400 would throw "QEJBSVR: FAILED TO CREATE CONSOLE FILE: /QIBM/UserData/WebSphere/AppServer/V85/Base/wlp/output/servers/server1/logs/console.log" each time I restart the server without manually deleting console.log. That is only when jvm.options file is in use to declare -Dfile.encoding=UTF-8.

      Separately, I also found out that specifying -Dclient.encoding.override=UTF-8 in the jvm.options file works. But I like your solution setCharacterEncoding solution better.