Re: another UTF-8 problem
Thanks for your responses. The problem was not the response from the web service. Something must have been completely mixed up. I set the Java option -Dfile.encoding to utf-8 which solved the write to file problem and also put this in the code: if (req.getCharacterEncoding() == null) req.setCharacterEncoding(UTF-8); res.setContentType(text/html; charset=UTF-8); res.setCharacterEncoding(UTF-8); Which solved the encoding of the response I got from the servlet. Best Tim Christopher Schultz schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim, On 8/24/2010 9:06 AM, Tim-Christian Mundt wrote: I've encountered a UTF-8 problem and yes, URIEncoding=UTF-8 is set. If you're connecting-out to a SOAP service, then the URIEncoding setting doesn't matter. I'm connecting to a web service which returns UTF-8 encoded data. If I do so from a plain, regular, self-contained Java application everything is fine. However, if I run the same classes in tomcat (and trigger the action with a http request instead of a main() method in the application) I get latin-1 encoded characters. For instance when I make a call and receive a response which contains Łódź I finally get ?ód? (console, file, whatever output). Are you sure it isn't the encoding to your console/file/whatever that isn't set properly? If you are getting a response that contains non-ASCII characters, they ought to be encoded using the declared XML document's encoding. What is that? Are the bytes correct in the response (before your SOAP client parses them)? Does your SOAP client parse them correctly? You may have to use a profiler to verify that the characters in memory are what you expect them to be. Actually the URIEncoding option should not have anything to do with this, because I'm not sending a request to my application, but my application is issuing a SOAP call to a web service. Are there any other options to consider? Same response from the web service (checked with Wireshark) but different outputs. I've no idea. Any hint is welcome. So, when you use your own command-line app as a client, you get a different response from the SOAP server than when you use Tomcat as the client? You should look at the requests that are being sent. Perhaps there is a bad accept-charset header or something (although that probably shouldn't affect the XML response, since an XML parser is pretty much required to support UTF-8). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxz7SoACgkQ9CaO5/Lv0PCNOQCeLLBz/6e3QNsPyQtw4Ggfnh7R sYsAn3PNB9UqJDunLDeMyQrz6a3Edbao =/0N2 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
another UTF-8 problem
Hi, I've encountered a UTF-8 problem and yes, URIEncoding=UTF-8 is set. I'm connecting to a web service which returns UTF-8 encoded data. If I do so from a plain, regular, self-contained Java application everything is fine. However, if I run the same classes in tomcat (and trigger the action with a http request instead of a main() method in the application) I get latin-1 encoded characters. For instance when I make a call and receive a response which contains Łódź I finally get ?ód? (console, file, whatever output). Actually the URIEncoding option should not have anything to do with this, because I'm not sending a request to my application, but my application is issuing a SOAP call to a web service. Are there any other options to consider? Same response from the web service (checked with Wireshark) but different outputs. I've no idea. Any hint is welcome. Thanks Tim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: another UTF-8 problem
From: Tim-Christian Mundt [mailto:d...@tim-erwin.de] Subject: another UTF-8 problem I've encountered a UTF-8 problem and yes, URIEncoding=UTF-8 is set. Tomcat version? Using APR or not? JVM version? Platform? Default locale setting? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: another UTF-8 problem
Caldarale, Charles R schrieb: From: Tim-Christian Mundt [mailto:d...@tim-erwin.de] Subject: another UTF-8 problem I've encountered a UTF-8 problem and yes, URIEncoding=UTF-8 is set. Tomcat version? Using APR or not? JVM version? Platform? Default locale setting? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. tomcat 6.0.18 no APR JVM 1.6.0_14 currently on Windows XP I don't know how to get the default locale setting on Windows. I'm in Germany, have a German version and hence assume it's de. Hope this helps isolating the problem. Tim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: another UTF-8 problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim, On 8/24/2010 9:06 AM, Tim-Christian Mundt wrote: I've encountered a UTF-8 problem and yes, URIEncoding=UTF-8 is set. If you're connecting-out to a SOAP service, then the URIEncoding setting doesn't matter. I'm connecting to a web service which returns UTF-8 encoded data. If I do so from a plain, regular, self-contained Java application everything is fine. However, if I run the same classes in tomcat (and trigger the action with a http request instead of a main() method in the application) I get latin-1 encoded characters. For instance when I make a call and receive a response which contains Łódź I finally get ?ód? (console, file, whatever output). Are you sure it isn't the encoding to your console/file/whatever that isn't set properly? If you are getting a response that contains non-ASCII characters, they ought to be encoded using the declared XML document's encoding. What is that? Are the bytes correct in the response (before your SOAP client parses them)? Does your SOAP client parse them correctly? You may have to use a profiler to verify that the characters in memory are what you expect them to be. Actually the URIEncoding option should not have anything to do with this, because I'm not sending a request to my application, but my application is issuing a SOAP call to a web service. Are there any other options to consider? Same response from the web service (checked with Wireshark) but different outputs. I've no idea. Any hint is welcome. So, when you use your own command-line app as a client, you get a different response from the SOAP server than when you use Tomcat as the client? You should look at the requests that are being sent. Perhaps there is a bad accept-charset header or something (although that probably shouldn't affect the XML response, since an XML parser is pretty much required to support UTF-8). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxz7SoACgkQ9CaO5/Lv0PCNOQCeLLBz/6e3QNsPyQtw4Ggfnh7R sYsAn3PNB9UqJDunLDeMyQrz6a3Edbao =/0N2 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
