Hello.
I've encountered an error in some of the xml transforms I work on. This error is "Unexpected end of file while parsing CDATA has occurred."

Essentially, within a <msg> tag is a CDATA string. Part of the transform is to remove the CDATA elements so we can store that string in the DB.
Example:
"<Msg><![CDATA[Message goes here.]]></Msg>"

NOTE: I have no control over the contents of these xml files, they are produced in a hardware element, developed by others.

Now, what is happening is that occasionally there will be invalid characters that the XML parser does not know how to handle. That is fine, I can deal with those. But what I can't deal with is essentially whatever message is copied over, into that CDATA tag, sometimes the EOF character is included. Which causes the error message above and even programs like NOTEPAD will stop displaying the contents of the xml file at that point, even though I am 100% certain that more content is supposed to follow.

I'm pretty certain there is no way to remove that during transform. So I was thinking of adding a for loop prior to the transform to find those extra EOF's and remove them...but I do not know what the EOF character is.

Has anybody experience this problem and know a work-around/fix? I am coding in C# for all actual code work.

If I missed including anything, please let me know. I tried to include everything I could that I felt was relevant.

Thank you!

This isn't really an XSLT question. XSLT can only handle XML input. If your input isn't XML, then you'll have to turn it into XML before the XSLT can start. Rather than trying to patch-up broken XML, I would encourage you to look hard at the process creating the broken XML and fix it at source.

Michael Kay
http://www.saxonica.com/
Author, XSLT 2.0 and XPath 2.0 Programmer's Reference

EOF means 'End Of File' - there is no specific 'character' that is an EOF character (at least I'm not aware of one.

What this probably means is that the XML parser is reading the CDATA section, and because of the invalid XML character doesn't realise that the CDATA has finished, and keeps reading till the end of the file.

As Michael said, there is nothing that XSLT can do to help you with this as it is an XML transformation language - and you don't have valid XML.

/- Sam Judson : Wrox Technical Editor -/

I agree with Michael that it is not an XSLT problem at all.
You will need to look at the file with a hex editor to see what kind of byte sequence is used in there.
Maybe the Wikipedia articles http://en.wikipedia.org/wiki/End_of_file, http://en.wikipedia.org/wiki/Control-Z help to identify what is in there.

--
  Martin Honnen
  Microsoft MVP - XML

Ya, I figured as much. And there is nothing I can do to control how the XML file is constructed. It's out of my hands.

I'll just have to figure out how to patch it correctly.
And I know that the CDATA tag closes and all other tags close and continue on with other elements.

Thanks for the help and confirming what I was afraid of.

Please don't call it an "XML file". It's a non-XML file.

XML is a really good way of constructing interfaces between systems. Before you patch up someone else's broken XML data, do remember that you are losing all the benefits that come from using a standard interchange syntax. You're keeping things together with sticky tape. It won't hold for long. It might be pragmatic, but it's not good engineering.

Michael Kay
http://www.saxonica.com/
Author, XSLT 2.0 and XPath 2.0 Programmer's Reference

Without getting into semantics too much, it still is an XML file. It has XML elements and, in rare cases, invalid characters get stuffed into it.
I've already made it clear to those that I can speak to that the XML files we receive are poorly formatted and are in need of serious help. It falls on deaf ears, or those that don't view it as high priority.
I agree with you 100% that I'm losing the benefits, but this is what I have to work with.
It's hard to explain. I'm just going to have to find a way to patch it or ignore it altogether.

>Without getting into semantics too much, it still is an XML file.

No it isn't. It might be nearly XML, but it's no more XML than 123456!?7 is a number.

Michael Kay
http://www.saxonica.com/
Author, XSLT 2.0 and XPath 2.0 Programmer's Reference

mhkay...you are a dick. A pompous, self-righteous dick.

BTW...123456!?7 is a number...with invalid characters stuffed into it.

THE GUARDIAN HAS SPOKEN!!!

Yes, I'm rather pedantic. Most good programmers are. There's a connection there somewhere.

__________________
Michael Kay
http://www.saxonica.com/
Author, XSLT 2.0 and XPath 2.0 Programmer\'s Reference