On Tue, Mar 20, 2012 at 15:25, Francisco Serrano <francisco.serr...@multicom.co.uk> wrote: > > 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...
The scope of AXIS2-4468 is limited to the XmlBeans data binding and the issue occurs in the serialization of an outgoing message, not in the deserialization of an incoming message. > 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. > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org For additional commands, e-mail: java-user-h...@axis.apache.org
