Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #16103 > unrolled thread

Diactric in CDATA in XML reponse

Back to article view | Back to comp.lang.javascript

Contents

  Diactric in CDATA in XML reponse "Tom de Neef" <tdeneef@qolor.nl> - 2012-09-21 22:06 +0200
    Re: Diactric in CDATA in XML reponse Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-22 03:46 +0200
      Re: Diactric in CDATA in XML reponse "Tom de Neef" <tdeneef@qolor.nl> - 2012-09-22 15:12 +0200
        Re: Diactric in CDATA in XML reponse Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-22 16:46 +0200
          Re: Diactric in CDATA in XML reponse "Tom de Neef" <tdeneef@qolor.nl> - 2012-09-22 19:31 +0200
            Re: Diactric in CDATA in XML reponse Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-22 21:12 +0200

#16103 — Diactric in CDATA in XML reponse

I encounter a situation where the responseXML of a XMLHttpRequest contains a 
CDATA element, like:

<xml><mod><![CDATA[some text]]></mod></xml>

This is used to load data in a table. It works always in FF and in Chrome. 
But in IE8 the table is not always loaded.
It took me a while to find that the problem is related to the presence of a 
diacritic (ASCII>128) in the CDATA text block. In such cases the responseXML 
is returned by IE with firstChild=null.

My question is how to handle this. I presume that I need to specify the 
encoding somewhere.
The response is in answer to a request of the form
    asyncRequestor.open("POST",d2w.appID,true);
    asyncRequestor.setRequestHeader("Content-type","application/x-www-form-urlencoded");
    asyncRequestor.send(txt);

Can you pls give me advice.
TIA
Tom 

[toc] | [next] | [standalone]

#16116

Tom de Neef wrote:

> I encounter a situation where the responseXML of a XMLHttpRequest contains
> a CDATA element, like:
> 
> <xml><mod><![CDATA[some text]]></mod></xml>
> 
> This is used to load data in a table. It works always in FF and in Chrome.
> But in IE8 the table is not always loaded.
> It took me a while to find that the problem is related to the presence of
> a diacritic (ASCII>128) in the CDATA text block. In such cases the
> responseXML is returned by IE with firstChild=null.

It might be helpful for further diagnosis that the referred document object 
implements the IXMLDOMDocument interface which provides an `xml' property 
for its XML serialization. [1]

Generally, it is better to start with `….responseXML.documentElement' or an 
element node found with `….responseXML.getElementsByTagName("…")[…]', 
because the returned XML document may have a preamble (one or more of XML 
declarations, processing instructions, DOCTYPE declaration), which will 
create nodes in the document tree before the root element node.
 
> My question is how to handle this. I presume that I need to specify the
> encoding somewhere.

Make sure that your XML data uses one of the character encodings that XML 
applications must support (UTF-8 and UTF-16), or declare the used character 
encoding. [2]  Not doing that and having incompatible code sequences in the 
XML data leads to the XML document being empty.

Generally, UTF-8 is the best choice for XML data because it can encode all 
Unicode characters without using character references (such as &#x20AC; for 
the Euro sign), is widely supported, and in most cases has the smallest 
footprint while having all these properties.

This is not so much of an issue with characters with code point below U+0080 
because in that range most encodings (probably all that encode Latin 
letters) are compatible.  In particular, UTF-8 is compatible with 
Windows-1252 ("ISO-8859-1") below U+0080 (it has the same code sequences for 
the same characters there).  (For example, PHP 5.3.x uses "ISO-8859-1" by 
default.)

I have tested this in Internet Explorer 6.0.2800.1106 with a server-side PHP 
5.3.x application generating an XML 1.0 document from user input in the same 
HTML document.  The XHR object was created with

  new ActiveXObject("Microsoft.XMLHTTP")

BTW, there are no characters with *ASCII* code beyond 127 (0x7F).  US-ASCII 
is a 7-bit encoding (code points and sequences 0x00 to 0x7F).
 
> The response is in answer to a request of the form
>     asyncRequestor.open("POST",d2w.appID,true);
>     asyncRequestor.setRequestHeader("Content-type","application/x-www-
form-urlencoded");
>     asyncRequestor.send(txt);

If `asyncRequestor' would hold a reference to an object implementing the 
IXMLHTTPRequest, XMLHttpRequest or XMLHttpRequest2 interface, you would need 
to define an event listener for the `readystatechange' or `load' event.  As 
there is no such definition in the posted code, one could assume that 
`asyncRequestor' is referring to a user-defined object, in which case one 
would be left with guessing what actually happens.  Only in this case it is 
apparent that the method of submitting the HTTP request is not relevant.


PointedEars
___________
[1] <http://msdn.microsoft.com/en-us/library/ie/ms757878(v=vs.85).aspx>
[2] <http://www.w3.org/TR/REC-xml/#charencoding>
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#16118

"Thomas 'PointedEars' Lahn wrote:
>
>> I encounter a situation where the responseXML of a XMLHttpRequest 
>> contains
>> a CDATA element, like:
>>
>> <xml><mod><![CDATA[some text]]></mod></xml>
>>
>> This is used to load data in a table. It works always in FF and in 
>> Chrome.
>> But in IE8 the table is not always loaded.
>> It took me a while to find that the problem is related to the presence of
>> a diacritic (ASCII>128) in the CDATA text block. In such cases the
>> responseXML is returned by IE with firstChild=null.
>
> It might be helpful for further diagnosis that the referred document 
> object
> implements the IXMLDOMDocument interface which provides an `xml' property
> for its XML serialization. [1]

I guess it does:
  var asyncRequestor = new XMLHttpRequest();

>
> Generally, it is better to start with `..responseXML.documentElement' or 
> an
> element node found with `..responseXML.getElementsByTagName(".")[.]',
> because the returned XML document may have a preamble (one or more of XML
> declarations, processing instructions, DOCTYPE declaration), which will
> create nodes in the document tree before the root element node.

That helped to streamline my code since IE does not skip the 
processinstructions node when accessing firstChild, whereas FF and Chrome 
do.

>
>> My question is how to handle this. I presume that I need to specify the
>> encoding somewhere.
>
> Make sure that your XML data uses one of the character encodings that XML
> applications must support (UTF-8 and UTF-16), or declare the used 
> character
> encoding. [2]  Not doing that and having incompatible code sequences in 
> the
> XML data leads to the XML document being empty.
>
> Generally, UTF-8 is the best choice for XML data because it can encode all
> Unicode characters without using character references (such as &#x20AC; 
> for
> the Euro sign), is widely supported, and in most cases has the smallest
> footprint while having all these properties.

I have added encoding so that the xml string no reads
<xml>
  <?xml version="1.0" encoding="utf-8" ?>
  <mod><![CDATA[some text]]></mod>
</xml>

This seems to work!
Thank you.
Tom

[toc] | [prev] | [next] | [standalone]

#16119

Tom de Neef wrote:

> "Thomas 'PointedEars' Lahn wrote:
>>> I encounter a situation where the responseXML of a XMLHttpRequest
>>> contains a CDATA element, like:
>>>
>>> <xml><mod><![CDATA[some text]]></mod></xml>
>>>
>>> This is used to load data in a table. It works always in FF and in
>>> Chrome.
>>> But in IE8 the table is not always loaded.
>>> It took me a while to find that the problem is related to the presence
>>> of a diacritic (ASCII>128) in the CDATA text block. In such cases the
>>> responseXML is returned by IE with firstChild=null.
>>
>> It might be helpful for further diagnosis that the referred document
>> object implements the IXMLDOMDocument interface which provides an `xml'
>> property for its XML serialization. [1]
> 
> I guess it does:
>   var asyncRequestor = new XMLHttpRequest();

Refuse the temptation to guess.

>>> My question is how to handle this. I presume that I need to specify the
>>> encoding somewhere.
>>
>> Make sure that your XML data uses one of the character encodings that XML
>> applications must support (UTF-8 and UTF-16), or declare the used
>> character encoding. [2]  Not doing that and having incompatible code
>> sequences in the XML data leads to the XML document being empty.
>>
>> Generally, UTF-8 is the best choice for XML data because it can encode
>> all Unicode characters without using character references (such as
>> &#x20AC; for the Euro sign), is widely supported, and in most cases has
>> the smallest footprint while having all these properties.
> 
> I have added encoding so that the xml string no reads
> <xml>
>   <?xml version="1.0" encoding="utf-8" ?>
>   <mod><![CDATA[some text]]></mod>
> </xml>
> 
> This seems to work!

That would be negatively surprising, since it is _not_ Valid.  AISB, the 
declaration must come *before* the root element (here: `xml'), and declaring 
UTF-8 is not necessary because it is one of the defaults.  What matters is 
that the encoding declaration, if any, matches the encoding of the data.
I can see no relevant change there.

> Thank you.

You are welcome, but you are _not_ done there yet.


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

[toc] | [prev] | [next] | [standalone]

#16121

"Thomas 'PointedEars' Lahn"  wrote:
>
>> I have added encoding so that the xml string no reads
>> <xml>
>>   <?xml version="1.0" encoding="utf-8" ?>
>>   <mod><![CDATA[some text]]></mod>
>> </xml>
>>
>> This seems to work!
>
> That would be negatively surprising, since it is _not_ Valid.  AISB, the
> declaration must come *before* the root element (here: `xml'), and 
> declaring
> UTF-8 is not necessary because it is one of the defaults.  What matters is
> that the encoding declaration, if any, matches the encoding of the data.
> I can see no relevant change there.
>
>> Thank you.
>
> You are welcome, but you are _not_ done there yet.

You are right. And it took some experimenting with combinations of the 
native string types in my server environment and the encoding in the 
processing instruction. I've tried combinations of string types (ANSI, utf8, 
unicode) with encoding specs 'utf-8', 'utf-16' and absent. All work in 
Chrome. In IE8 all fail if there is a diacritic in the data. What does work 
is the combination of unicode string and 'iso-8859-1'. Doesn't make it 
universal but I can live with it until I understand this issue better.

<?xml version="1.0" encoding="iso-8859-1" ?>
<xml>
  <mod><![CDATA[some text]]></mod>
</xml>

Tom

[toc] | [prev] | [next] | [standalone]

#16123

Tom de Neef wrote:

> […] it took some experimenting with combinations of the native string
> types in my server environment and the encoding in the processing
> instruction. I've tried combinations of string types (ANSI, utf8, unicode)
> with encoding specs 'utf-8', 'utf-16' and absent. All work in Chrome. In
> IE8 all fail if there is a diacritic in the data. What does work is the
> combination of unicode string and 'iso-8859-1'. Doesn't make it universal
> […]

Correct, that makes it wrong.


PointedEars
-- 
Sometimes, what you learn is wrong. If those wrong ideas are close to the 
root of the knowledge tree you build on a particular subject, pruning the 
bad branches can sometimes cause the whole tree to collapse.
  -- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web