I will try the latest version to see if that makes a difference. Thanks. > -----Original Message----- > From: Andreas Veithen [mailto:[EMAIL PROTECTED] > Sent: Monday, June 30, 2008 12:33 PM > To: [email protected] > Subject: Re: [Axis2] I18N problem > > Tony, > > This should be handled by the StAX implementation. For Axis2 this is > Woodstox by default. Maybe you can solve our problem by upgrading it > to a newer version. > > Andreas > > On 30 juin 08, at 14:52, Tony Dean wrote: > > > Andreas, > > > > JVM is doing the right thing: > > > > getBytes("UTF-8") transforms \u4e2d \u6587 \u6d4b \u8bd5 into > > [xe4 xb8 xad xe6 x96 x87 xe6 xb5 x8b xe8 xaf x95] > > > > I'm not sure where to look in the Axis2 code to determine what API > > they are using to transform the payload to wire format. > > > > Thanks. > > > >> -----Original Message----- > >> From: Andreas Veithen [mailto:[EMAIL PROTECTED] > >> Sent: Monday, June 30, 2008 6:24 AM > >> To: [email protected] > >> Subject: Re: [Axis2] I18N problem > >> > >> Tony, > >> > >> It would be interesting to know if it is a problem with Axis2 or > with > >> the UTF-8 implementation of the Java runtime environment. Can you > >> test > >> that by calling getBytes("UTF-8") on the string and check whether > the > >> result is correct? > >> > >> Andreas > >> > >> On 29 juin 08, at 08:19, Tony Dean wrote: > >> > >>> Hi, > >>> > >>> I have narrowed down an I18N problem when using Simplified Chinese > >>> characters in payload to Axis2 client side. > >>> > >>> I have an Axis2 client using ServiceClient to send a SOAP request > to > >>> my service. For example a couple of characters in the payload are > >>> as follows: > >>> > >>> U+4e2d U+6587 U+6d4b U+8bd5 > >>> > >>> When the service receives these characters, they appear as follows: > >>> > >>> U+002d U+6587 U+004b U+8bd5 > >>> > >>> The high-order byte of the 1st and 3rd characters are incorrect. > >>> > >>> When the Axis2 ServiceClient converts the payload to UTF-8 for > >>> sending across the wire, these bytes become (as seen in > >>> soapMonitor): > >>> 2de6 9687 4be8 af95 > >>> > >>> I think that they should be: > >>> e4b8 ade6 9687 e6b5 8be8 af95 > >>> > >>> Can anyone explain what's going on? Seems like an easy > >>> transformation of encodings for wire-format, but something is not > >>> quite right. > >>> > >>> To replicate try the following: > >>> > >>> ServiceClient client = new ServiceClient(ctx, null); > >>> ... > >>> > >>> String value = new String("Hello world: \u4e2d\u6587\u6d4b > >>> \u8bd5"); > >>> OMElement response = client.sendReceive(getPayload(value)); > >>> > >>> The Asian characters are not sent as expected. > >>> > >>> Thanks for any insight. > >>> > >>> I'll enter a bug if it so warrants. > >>> > >>> > >>> > >>> Tony Dean > >>> SAS Institute Inc. > >>> 919.531.6704 > >>> [EMAIL PROTECTED] > >>> > >>> SAS... The Power to Know > >>> http://www.sas.com > >>> > >>> > >>> > >>> ------------------------------------------------------------------- > -- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >> > >> > >> -------------------------------------------------------------------- > - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
