ws-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Goh Tor Meng <torm...@mvitech.com>
Subject Re: Treatment of CR in XmlWriter
Date Fri, 30 Dec 2005 23:39:28 GMT
Hi,

Thanks for the reply. As the receiving end is an external party I'll 
have to check with
them. What I know for now is that they are coding in Delphi.

May I know what is meant by "Avoid normalization of CR to LF"?

code snippet from XmlWriter
-----------------------------------------------
          case '\r':
              // Avoid normalization of CR to LF.
              writeCharacterReference(c);
              break;
------------------------------------------------

The code above in XmlWriter.isValidXMLChar(char c) is preventing it to
return true when '/r' is encountered when is XmlWriter.ValidXMLChar(char c)
is called.

We encountered this when we're trying to debug on our side and found it 
strange.

Thanks again.

regards
Tor Meng

John Wilson wrote:

> If this is causing you a problem then you are not using an XML parser  
> to read the response.
>
> Can you please  tell us how you handing the XML-RPC response?
>
> John Wilson
> The Wilson Partnership
> http://www.wilson.co.uk
>
>

Code except from XmlWriter.java
=======================

  protected void chardata(String text)
      throws XmlRpcException, IOException
  {
      int l = text.length ();
      // ### TODO: Use a buffer rather than going character by
      // ### character to scale better for large text sizes.
      //char[] buf = new char[32];
      for (int i = 0; i < l; i++)
      {
          char c = text.charAt (i);
          switch (c)
          {
          case '\t':
          case '\n':
              write(c);
              break;
          case '\r':
              // Avoid normalization of CR to LF.
              writeCharacterReference(c);
              break;
          case '<':
              write(LESS_THAN_ENTITY);
              break;
          case '>':
              write(GREATER_THAN_ENTITY);
              break;
          case '&':
              write(AMPERSAND_ENTITY);
              break;
          default:
              // Though the XML spec requires XML parsers to support
              // Unicode, not all such code points are valid in XML
              // documents.  Additionally, previous to 2003-06-30
              // the XML-RPC spec only allowed ASCII data (in
              // <string> elements).  For interoperability with
              // clients rigidly conforming to the pre-2003 version
              // of the XML-RPC spec, we entity encode characters
              // outside of the valid range for ASCII, too.
              if (c > 0x7f || !isValidXMLChar(c))
              {
                  // Replace the code point with a character reference.
                  writeCharacterReference(c);
              }
              else
              {
                  write(c);
              }
          }
      }
  }

  /**
   * Section 2.2 of the XML spec describes which Unicode code points
   * are valid in XML:
   *
   * <blockquote><code>#x9 | #xA | #xD | [#x20-#xD7FF] |
   * [#xE000-#xFFFD] | [#x10000-#x10FFFF]</code></blockquote>
   *
   * Code points outside this set must be entity encoded to be
   * represented in XML.
   *
   * @param c The character to inspect.
   * @return Whether the specified character is valid in XML.
   */
  private static final boolean isValidXMLChar(char c)
  {
      switch (c)
      {
      case 0x9:
      case 0xa:  // line feed, '\n'
      case 0xd:  // carriage return, '\r'
          return true;

      default:
          return ( (0x20 <= c && c <= 0xd7ff) ||
                   (0xe000 <= c && c <= 0xfffd) ||
                   (0x10000 <= c && c <= 0x10ffff) );
      }
  }

Mime
View raw message