bug #24896 : I don't understand what we are doing in AbstractXMLE ncoder

[Cédric Chabanois <CC...@natsystem.fr>]

Hi all,

My correction for bug #24896 worked ie xml sent is in UTF-8 format (before
french accents, chinese characters ... were not transmitted correctly) but I
don't really understand what we are doing In AbstractXMLEncoder and
UTF8Encoder :
encode method takes a java String.
This string is converted to a byte array in UTF-8 (using
String.getBytes("UTF-8")) and
& becomes "&amp"
" becomes "&quot"
< becomes "&lt"
> becomes "&gt"
all other characters are encoded using UTF-8 (appendEncoded method in
UTF8Encoder).

Then the characters are converted back to a string (using UTF-8 charset
since my patch and using platform's default charset before my patch : the
bytes were not valid for the default charset)

I wonder why we use an UTF-8 byte array there just to reconvert it to a
string after since all we do is to convert some characters (& -> &amp ...).

There is probably something I missed somewhere ...

Cédric

Re: bug #24896 : I don't understand what we are doing in AbstractXMLE ncoder

[Davanum Srinivas <di...@yahoo.com>]

See http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19327 for more info.

--- C�dric_Chabanois <CC...@natsystem.fr> wrote:
> Hi all,
> 
> My correction for bug #24896 worked ie xml sent is in UTF-8 format (before
> french accents, chinese characters ... were not transmitted correctly) but I
> don't really understand what we are doing In AbstractXMLEncoder and
> UTF8Encoder :
> encode method takes a java String.
> This string is converted to a byte array in UTF-8 (using
> String.getBytes("UTF-8")) and
> & becomes "&amp"
> " becomes "&quot"
> < becomes "&lt"
> > becomes "&gt"
> all other characters are encoded using UTF-8 (appendEncoded method in
> UTF8Encoder).
> 
> Then the characters are converted back to a string (using UTF-8 charset
> since my patch and using platform's default charset before my patch : the
> bytes were not valid for the default charset)
> 
> I wonder why we use an UTF-8 byte array there just to reconvert it to a
> string after since all we do is to convert some characters (& -> &amp ...).
> 
> There is probably something I missed somewhere ...
> 
> C�dric


=====
Davanum Srinivas - http://webservices.apache.org/~dims/

Re: bug #24896 : I don't understand what we are doing in AbstractXMLE ncoder

[Davanum Srinivas <di...@yahoo.com>]

That's what am trying to figure out as well :) Right now, am writing more test cases against the
EchoHeaders.jws just to be sure we don't break anything.

-- dims

--- C�dric_Chabanois <CC...@natsystem.fr> wrote:
> Hi all,
> 
> My correction for bug #24896 worked ie xml sent is in UTF-8 format (before
> french accents, chinese characters ... were not transmitted correctly) but I
> don't really understand what we are doing In AbstractXMLEncoder and
> UTF8Encoder :
> encode method takes a java String.
> This string is converted to a byte array in UTF-8 (using
> String.getBytes("UTF-8")) and
> & becomes "&amp"
> " becomes "&quot"
> < becomes "&lt"
> > becomes "&gt"
> all other characters are encoded using UTF-8 (appendEncoded method in
> UTF8Encoder).
> 
> Then the characters are converted back to a string (using UTF-8 charset
> since my patch and using platform's default charset before my patch : the
> bytes were not valid for the default charset)
> 
> I wonder why we use an UTF-8 byte array there just to reconvert it to a
> string after since all we do is to convert some characters (& -> &amp ...).
> 
> There is probably something I missed somewhere ...
> 
> C�dric


=====
Davanum Srinivas - http://webservices.apache.org/~dims/