I've actually filed a bug regarding the handling of return characters
in text nodes.
In my case, I had some text that included /r/n line endings, and the
parser was changing them to /n. Not cool when the other end is
expecting /r/n
http://support.realsoftware.com/feedback/viewreport.php?
reportid=ptmmmsxf
-jason
On Apr 5, 2006, at 1:11 PM, Marc Zeedar wrote:
On Wed, April 5, 2006 5:58 pm, Nick Lockwood wrote:
OK, so ignore my previous comment.
But isn't XML Unicode-savy? I thought if the text was Unicode, it'd be
okay. I shouldn't think I'd have to encode Unicode text as entities or
CDATA.
I had a user in Japan test files with Japanese and it seemed to
work fine.
I figured if it worked for Japanese it'd work for anything.
You say that it doesn't handle returns *in all cases*? What does this
mean exactly - when does it and when doesn't it?
Well, through trial and error, I found that text node tags with only a
carriage return and no other text in the node didn't work. The parser
would essentially strip them (it saw it as an empty tag).
Unfortunately, that's a common event with data in my application, so I
found that encoding the returns solved the problem as now the
parser sees
some data there and just replace my encodings with endOfLine to get
back
what the user originally had.
--
Marc Zeedar
Publisher
REALbasic Developer Magazine
http://www.rbdeveloper.com
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
