XmlDocument和XDocument处理之间的区别＆＃x0;

Question

I have been trying to load a xml file which contains some null('&#x0') character. I have tried -

  XmlDocument document = new XmlDocument();
  document.LoadXml(xmlString);

and

XDocument.Load(stringReader);

XmlDocument.LoadXml() method successfully loads xml document whereas XDocument.Load() method gives XmlException for same xml string.

Sample Code to Reproduce :

string xmlFile = @"C:\dummyData.xml";

        string xmlString = File.ReadAllText(xmlFile);

        XmlDocument document = new XmlDocument();
        document.LoadXml(xmlString); //Work

        XDocument.Parse(xmlString); // Didn't work.

        using (StringReader reader = new StringReader(xmlString))
        {
            XDocument.Load(reader);
        }

Xml File

Copy the content of xml file from here

Answer 1

A character reference � is not allowed in XML (at least XML 1.0 as supported by Microsoft). However for legacy support I think an XmlTextReader or an XmlReader created with XmlReaderSettings to not check characters can load such markup. XmlDocument uses such an XmlReader while XDocument does not.

Answer 2

Why � is a problem

As defined by W3C, Entities are

CharRef ::=   '&#' [0-9]+ ';'
            | '&#x' [0-9a-fA-F]+ ';'

So at first sight, an entity like � looks good.

But you need to read the definition:

[Definition: A character reference refers to a specific character in the ISO/IEC 10646 character set, for example one not directly accessible from available input devices.]

So the character reference needs to point to ISO/IEC 10646 character, which is linked :

Characters referred to using character references MUST match the production for Char .

Luckily Char is in the same document and defined as:

Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]

Therefore, as mentioned by Martin Honnen before, neither the C# \\0 character nor the escaped versions � or � are allowed in XML documents.

XML parser reality

Some parsers might ignore parts of above rules and not fully adhere to the standard.

The real origin of the problem

The XML you posted seems to contain images/drawings:

<?xml version="1.0" encoding="utf-8"?>
<TestData>
        <Images>
            <Drawings>
&lt;?xml version="1.0"?&gt;
&lt;ArrayOfMarkerState &gt;
&lt;/ArrayOfMarkerState&gt;
&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;&#x0;</Drawings>
        </Images>
            <Date>2015-10-20T17:19:05.2656609+05:30</Date>
</TestData>

The nature of pixel graphics is that they contain binary data.

Developers who are not familiar with XML and faced with the problem of embedding binary data in XML will quickly think that any byte can be encoded as � ... ÿ .

Unfortunately this is plain wrong. Why? Well, because of the W3C definition above.

Other than that, this is even a bad idea regarding size. Even if it would work, a byte encoded like this will take 6 bytes in XML.

Solving the original problem

Binary data cannot go into XML documents as XML entities, so let's find something that works and needs less than +500% increase of size.

The answer is Base64 . Base64 has a rough increase of +33% in size.

Encoding the 47 � bytes would result in

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

which is only 64 bytes long, compared to the original 235 bytes.