Re: AW: [Axis2] Axis2 client generated from WSDL ignoring encoding

[Francisco Serrano]

Hello Josef, Thanks a lot for your reply. The exact version I'm using is 1.0 and I can confirm that the stub is generated by WSDL2JAVA. The problem is that from my client I'm using the stub to call an external service. The response from this service is using UTF8 to encode the content, I've checked with Wireshark the communications and messages and the response is specifying UTF8 and the problematic character (a dash) is correctly encoded with UTF8. The response specifies "text/xml; charset=utf-8" in the HTTP header and the xml message within it "<?xml version='1.0' encoding='utf-8'?>" and the character in the payload is specified as: e2 80 93 (UTF-8 (hex) representation for EN DASH: http://www.fileformat.info/info/unicode/char/2013/index.htm). But when the control comes back to my application, the stub is using ISO-8859-15 (which is the charset specified for my JVM) to decode that response so the response is showing incorrect characters for the dash, debugging the code I'm getting: â According to http://osdir.com/ml/axis-dev-ws.apache.org/2009-08/msg00132.html looks like before version 1.6 the encoding wasn't being taken into account in a reliable way... Wouldn't be any other way to solve this rather than generating the client with a newer version? Thanks, Francisco. On 20/03/2012 09:12, Stadelmann Josef wrote: Francisco   What is your exact version of AXIS2?   And just to be sure; are you creating a Java Client calling a stub generated by WSDL2JAVA?   Are you using SOAP-XML over HTTP? THEN XML cannot keep all ISO-8859-1 characters. To transfer you need to escape certain characters before inserting it into your ISO-8859-1 XML string, and it might be better to use UTF-8 for that.   We had recently a similar issue which we did not have unless we changed to AXIS2-1.6.1 Guess it has to do with Axiom version delivered with this release of AXIS2.   I strongly suggest to use TCP Monitor to look what you get back by the sender which is in your case the service-response.   How does the service return payload characters i.e. a "ä ö ü è é or > < & %"   and I think that will get you further. http://osdir.com/ml/axis-dev-ws.apache.org/2009-08/msg00132.html     let me know if it helps.   Josef         Von: Francisco Serrano [mailto:francisco.serr...@multicom.co.uk] Gesendet: Montag, 19. März 2012 15:47 An: java-user@axis.apache.org Betreff: [Axis2] Axis2 client generated from WSDL ignoring encoding   Any advice on this please? -------- Original Message -------- Subject: [Axis2] Axis2 client generated from WSDL ignoring encoding Date: Thu, 23 Feb 2012 17:02:42 +0000 From: Francisco Serrano <francisco.serr...@multicom.co.uk> To: java-user@axis.apache.org   Hello,   I have an axis2 client generated from a WSDL, which is working fine but I'm having some problems since it's ignoring the charset specified in the response it's getting back.   The response specifies charset=UTF-8 in the Content-Type HTTP header and the same in the encoding parameter in the xml message.   Instead of using UTF-8 to decode the xml content, it's using ISO-8859-1 which is the one set for the JVM where the client is running. For this reason I'm getting some strange characters in the response. I've double checked that the characters are encoded correctly using UTF-8.   It's an old client generated with version 1.0. Does anybody know if there's some issue about that version regarding this problem? Are there any parameters to specify the charset to use to decode the response?   Best regards, Francisco.   Multicom Products Limited is a company registered in England and Wales (Registered Number 2447353 Wales) with its registered office at 33 Victoria Street, Bristol, BS1 6AS. This email is confidential to the addressee and may contain privileged information. If you have reason to believe that you are not the intended recipient of this communication, please delete it from your system and contact the sender immediately. You are not permitted to use or copy this email or its attachments nor may you disclose the same to any third party. Unauthorised use or disclosure of this email is prohibited and may be unlawful. We reserve the right to intercept and read emails sent or received by our employees. This is to ensure compliance with our internal policies and to protect our business. If you do not wish for your communications to be subjected to such scrutiny, you should not communicate via this email system. We endeavour to exclude viruses and other malware from our data but it is the responsibility of the recipient to scan all emails and attachments for viruses before opening them. We accept no liability for any damage caused by any virus transmitted by this email. Email may not be completely secure or error free, can be intercepted or corrupted and may arrive late or not at all. Anyone who communicates with us by email accepts these risks.   -- Francisco Serrano Java Developer Email: francis...@multicom.co.uk Tel: 0117 908 1250 Address: 33 Victoria St. 2nd Floor, Bristol, BS1 6AS Facebook: www.facebook.com/multicomproductslimited Twitter: @MulticomFAB LinkedIn: www.linkedin.com/company/multicom-products-ltd www.multicom.co.uk Multicom Products Limited is a company registered in England and Wales (Registered Number 2447353 Wales) with its registered office at 33 Victoria Street, Bristol, BS1 6AS. This email is confidential to the addressee and may contain privileged information. If you have reason to believe that you are not the intended recipient of this communication, please delete it from your system and contact the sender immediately. You are not permitted to use or copy this email or its attachments nor may you disclose the same to any third party. Unauthorised use or disclosure of this email is prohibited and may be unlawful. We reserve the right to intercept and read emails sent or received by our employees. This is to ensure compliance with our internal policies and to protect our business. If you do not wish for your communications to be subjected to such scrutiny, you should not communicate via this email system. We endeavour to exclude viruses and other malware from our data but it is the responsibility of the recipient to scan all emails and attachments for viruses before opening them. We accept no liability for any damage caused by any virus transmitted by this email. Email may not be completely secure or error free, can be intercepted or corrupted and may arrive late or not at all. Anyone who communicates with us by email accepts these risks.