axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: XMLUtils does not encode FF / 0xC character in Java Strings...
Date Fri, 22 Oct 2004 18:39:33 GMT
I understand that... the whole point of xmlEncodeString (as I understand 
it) is to encode these characters so they can be sent... am I wrong?
Isn't the point of BeanSerializer / Java2WSDL and back to hide some of the 
complexity here? The same string being encoded had regular line-breaks 
(\r) as well as a large snippet of xml (with quotes, <,>,etc...).

Once I encode the '\f' as &#xc;, the AXIS client correctly decodes this as 
the '\f' on the client side... am I missing something? This seems like a 
good thing.


"Simon Fell" <> 
10/22/2004 11:34 AM
Please respond to


RE: XMLUtils does not encode FF / 0xC character in Java Strings...

That doesn't help, the characters that are illegal in XML  are illegal 
regardless of how they are represented &#xc; is still an invalid  xml 
character reference.

From:  [] 
Sent: Friday, October 22, 2004  11:27 AM
Subject: XMLUtils does  not encode FF / 0xC character in Java Strings... 

        I am developing an  AXIS/SOAP interface to a legacy system. A 
java-bean sent via soap includes a  java.lang.String that often contains 
FormFeeds/FF/0xC. This is causing a parse  error on the client side, with 
"invalid xml character... 0xc". 

        The  class org.apache.axis. XMLUtils' method xmlEncodeString is 
the method used by  the standard/default BeanSerializer to encode Java 
Strings. I would think it a  good goal of AXIS to support Java Strings 
without limiting the characters that  could be in those strings... I'm not 
sure the full set of special characters  that need to be checked for 
(possibly this is why the FF character missed the  implementation this 
far) but am pretty sure that other developers working  w/legacy systems 
will run into this problem as well. 

        The main classes that  (IMHO) need modification are: 
                 <method:  public static String xmlEncodeString(String 
orig > 
        and possibly (I'm  not sure what exactly this class does) 
                 <static int  int charRange[], possibly other  methods> 

         I've already implemented a workaround as I'm on a tight 
production  schedule, so am not asking anyone for 'help', but think fixing 
this bug will  help the AXIS community. The workaround 


The additional bit of code: 
case '\f' : sBuf.append("&#xc;"); 

Note: I think  there is another bug in, that even though the 
'\r' character is  recognized for encoding, it is not checked for in the 
above section that  determines the bool 'needsEncoding': 

switch(chars[i]) { 
             case '&': case '"': case '\'': case  '<': case '>': //***** 
where is the check for \r, or any others needed  (i.e. if '\f' gets 
                 needsEncoding =  true;

View raw message