You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xalan.apache.org by Erik Ytterman <er...@ferrologic.com> on 2003/09/24 11:11:46 UTC
Numeric entity problem
Dear All!
I'm struggling with a problem that needs to be solve as soon as
possible. Hope that you will be able to help me. I will attach parts of
the code.
I'm doing the following:
1. Recive a callback with a proper XML document.
(DocumentHandler.handleDocument())
2. Use XPath to find the element to process
(DocumentHandler.translateDocument())
3. Find the text content of this element.
(DocumentHandler.translateDocument())
4. Translate the textual content of the element.
(OpenB2BUtil.translateString())
5. An ugly hack to transform any characters except ASCII into numeric
entities. (OpenB2BUtil.etitifyIsoString())
6. Replace the textual content of the element, including numeric
entities (DocumentHandler.translateDocument())
7. Serialize the resulting DOM tree using transformers
(OpenB2BUtil.documentToStream())
Problem:
As can be seen from the code, I replace the textual content of an
element, with a string that contains numeric entities (ý). My
problem is that the serialization seem to translate this into
(&#253;).
Questions:
1. Is this a bug in xalan, from my point of view, it should leave the
numeric entity in the text payload untouched, since it is proper XML.
2. If not, is there a way to disable this "feature" in Xalan, so that
these, perfectly legal numeric entities are let through in the
serialization
3. If not, any sugestions on how to solve the problem?
/Erik
SV: Numeric entity problem
Posted by Erik Ytterman <er...@ferrologic.com>.
Hello Simon!
Thank you for your quick response.
The reason for sending this message to two groups is the following:
I still think this is a bug/feature in the xalan package, and if so it
should be patched. Of course i could have written two mails with exactly
the same content.
Look at this example:
I have this element:
<element>I am tired</element>
I extract the text part
"I am tired"
I translate the text part into something like this:
"Ich bin müde"
I exchange the german y, which is an ISO-8859-1 charachter with a
character code larger than 127, into a proper XML numeric character
entity (ý) giving us the following string
"Ich bin mýde"
I exchange the text part of the element, giving (If the API works
properly)
<element>Ich bin mýde</element>
This is then serialized into
<element>Ich bin m&#253;de</element>
Which from my point of view is incorrect behaviour, since the text
content of the previous element was totally correct from an XML point of
view?!
Any godd ideas?!
BR
/Erik
-----Ursprungligt meddelande-----
Från: Simon Kitching [mailto:simon@ecnetwork.co.nz]
Skickat: den 24 september 2003 11:38
Till: Erik Ytterman
Kopia: xalan-j-users@xml.apache.org; 'Beatrice Nilsson'
Ämne: Re: Numeric entity problem
Hi Eric,
First of all, a minor note on etiquette: it is generally frowned upon to
post to both user and dev email lists. The user list is certainly the
best place for this sort of question.
I believe that Xerces is behaving exactly as expected; you told it that
the contents of a text node is a string containing the characters:
'&', '2', '3', etc
This is *text* to xerces, and because text cannot contain an ampersand,
it is escaped when writing the data out.
I suggest you try this:
char[] c = {253}; // array of 1 char which is unicode char #253
String str = new String(c);
Now put this string (containing the unicode character #253) into the
node.
I suspect there is actually a way to specify unicode chars directly in
string literals, maybe something like:
String s = "\xFD";
I'm not sure about that, though.
Regards,
Simon
On Wed, 2003-09-24 at 21:11, Erik Ytterman wrote:
> Dear All!
>
> I'm struggling with a problem that needs to be solve as soon as
> possible. Hope that you will be able to help me. I will attach parts
> of the code.
>
> I'm doing the following:
>
> 1. Recive a callback with a proper XML document.
> (DocumentHandler.handleDocument())
>
> 2. Use XPath to find the element to process
> (DocumentHandler.translateDocument())
>
> 3. Find the text content of this element.
> (DocumentHandler.translateDocument())
>
> 4. Translate the textual content of the element.
> (OpenB2BUtil.translateString())
>
> 5. An ugly hack to transform any characters except ASCII into numeric
> entities. (OpenB2BUtil.etitifyIsoString())
>
> 6. Replace the textual content of the element, including numeric
> entities (DocumentHandler.translateDocument())
>
> 7. Serialize the resulting DOM tree using transformers
> (OpenB2BUtil.documentToStream())
>
> Problem:
>
> As can be seen from the code, I replace the textual content of an
> element, with a string that contains numeric entities (ý). My
> problem is that the serialization seem to translate this into
> (&#253;).
>
> Questions:
>
> 1. Is this a bug in xalan, from my point of view, it should leave the
> numeric entity in the text payload untouched, since it is proper XML.
>
> 2. If not, is there a way to disable this "feature" in Xalan, so that
> these, perfectly legal numeric entities are let through in the
> serialization
>
> 3. If not, any sugestions on how to solve the problem?
>
> /Erik
>
>
>
>
>
Re: Numeric entity problem
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
Hi Eric,
First of all, a minor note on etiquette: it is generally frowned upon to
post to both user and dev email lists. The user list is certainly the
best place for this sort of question.
I believe that Xerces is behaving exactly as expected; you told it that
the contents of a text node is a string containing the characters:
'&', '2', '3', etc
This is *text* to xerces, and because text cannot contain an ampersand,
it is escaped when writing the data out.
I suggest you try this:
char[] c = {253}; // array of 1 char which is unicode char #253
String str = new String(c);
Now put this string (containing the unicode character #253) into the
node.
I suspect there is actually a way to specify unicode chars directly in
string literals, maybe something like:
String s = "\xFD";
I'm not sure about that, though.
Regards,
Simon
On Wed, 2003-09-24 at 21:11, Erik Ytterman wrote:
> Dear All!
>
> I'm struggling with a problem that needs to be solve as soon as
> possible. Hope that you will be able to help me. I will attach parts
> of the code.
>
> I'm doing the following:
>
> 1. Recive a callback with a proper XML document.
> (DocumentHandler.handleDocument())
>
> 2. Use XPath to find the element to process
> (DocumentHandler.translateDocument())
>
> 3. Find the text content of this element.
> (DocumentHandler.translateDocument())
>
> 4. Translate the textual content of the element.
> (OpenB2BUtil.translateString())
>
> 5. An ugly hack to transform any characters except ASCII into numeric
> entities. (OpenB2BUtil.etitifyIsoString())
>
> 6. Replace the textual content of the element, including numeric
> entities (DocumentHandler.translateDocument())
>
> 7. Serialize the resulting DOM tree using transformers
> (OpenB2BUtil.documentToStream())
>
> Problem:
>
> As can be seen from the code, I replace the textual content of an
> element, with a string that contains numeric entities (ý). My
> problem is that the serialization seem to translate this into
> (&#253;).
>
> Questions:
>
> 1. Is this a bug in xalan, from my point of view, it should leave the
> numeric entity in the text payload untouched, since it is proper XML.
>
> 2. If not, is there a way to disable this "feature" in Xalan, so that
> these, perfectly legal numeric entities are let through in the
> serialization
>
> 3. If not, any sugestions on how to solve the problem?
>
> /Erik
>
>
>
>
>
Re: Numeric entity problem
Posted by da...@us.ibm.com.
> Questions:
>
> 1. Is this a bug in xalan, from my point of view, it should leave the
numeric entity in the text payload untouched, since it is proper XML.
No, it's not a bug in Xalan. Rather, it's a bug in your understanding of
XML processing.
> 2. If not, is there a way to disable this "feature" in Xalan, so that
these, perfectly legal numeric entities are let through in the
serialization
No, there is no way to disable this, because it's not a "feature" -- it's
required behavior.
> 3. If not, any sugestions on how to solve the problem?
You are trying to modify the content of a document to control aspects of
serialization, which will never work. If you want pure ASCII
serialization, then create serializer with an encoding of "US-ASCII", and
the serializer will emit all non-ASCII characters as numeric character
references, which means you can skip step 5 of your process.
Dave
PS. Please don't cross-post!
"Erik Ytterman"
<erik.ytterman@ferr To: <xa...@xml.apache.org>, <xa...@xml.apache.org>
ologic.com> cc: "'Beatrice Nilsson'" <be...@ferrologic.com>, (bcc: David N
Bertoni/Cambridge/IBM)
09/24/2003 02:11 AM Subject: Numeric entity problem
Dear All!
I'm struggling with a problem that needs to be solve as soon as possible.
Hope that you will be able to help me. I will attach parts of the code.
I'm doing the following:
1. Recive a callback with a proper XML document.
(DocumentHandler.handleDocument())
2. Use XPath to find the element to process
(DocumentHandler.translateDocument())
3. Find the text content of this element.
(DocumentHandler.translateDocument())
4. Translate the textual content of the element.
(OpenB2BUtil.translateString())
5. An ugly hack to transform any characters except ASCII into numeric
entities. (OpenB2BUtil.etitifyIsoString())
6. Replace the textual content of the element, including numeric entities
(DocumentHandler.translateDocument())
7. Serialize the resulting DOM tree using transformers
(OpenB2BUtil.documentToStream())
Problem:
As can be seen from the code, I replace the textual content of an element,
with a string that contains numeric entities (ý). My problem is that
the serialization seem to translate this into (&#253;).
Questions:
1. Is this a bug in xalan, from my point of view, it should leave the
numeric entity in the text payload untouched, since it is proper XML.
2. If not, is there a way to disable this "feature" in Xalan, so that
these, perfectly legal numeric entities are let through in the
serialization
3. If not, any sugestions on how to solve the problem?
/Erik
(See attached file: OpenB2BUtil.java)(See attached file:
DocumentHandler.java)