|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Error and Fatal Error
Maybe I have got some attention but will it solve anything I wonder. I did post to my blog about this a few months back along with code http://stephengreenxml.blogspot.com/2011/03/xml-special-character-gotchas.html
The way the parser works (and its ancestors) is to throw a special exception (XMLException I think) when it encounters something illegal characters. This is, I assume, as per the spec telling it to stop
processing and report a fatal error. The developer catches this with a try/catch and passes control to a bit of code in order to attempt to fix the illegal character (as per the spec). This involves going through
each error in turn (since, as per the spec, several errors may have occurred only one of which was fatal) and determine whether it is an element name error (or attribute, etc) or whether the error is in the
content of an element (or attribute). In my scenario the code in the app itself created the error so there is not much chance of there being an error in an element name but the content came from a
webpage form (via AJAX in this case) so there is likely to be an error in the content of an illegal character in the user input; therefore the code will concentrate on finding and replacing such characters.
Call this preparsing if you like - using the same parser as used for normal parsing but using its features which it implements according to the spec to allow for error correction (which is what we mean by
pre-parsing). The Exception has enough information to allow the code, together with the XML as a string, to find the eroneous illegal character. But my bugbear is that in implementing the spec the
parser producers have thrown a fatal Exception meaning the state of the parser is not condusive to such error correction. I maintain that the spec is misleading in requiring a fatal error and at the same time
suggesting allowing error correction since both are mutually exclusive to some extent, as you'll see from how it works in practice and from parser instructional material which reports that after an XMLException
the state of the parser is unpredictable. To my mind this is as a result of it having to stop processing (according to the spec). Here's the code used to implement all this (a little simplistically because it is a
RAD application implemented with fast turnaround requirements). public static string
EscapeXmlSpecialCharacters(string
XmlString)
{
string resultString =
"";
//Create and load the XML document.
XmlDocument doc = new XmlDocument();
try
{
doc.LoadXml(XmlString);
resultString =
XmlString;
}
catch (XmlException ex)
{
StringReader str = new StringReader(XmlString);
StringWriter stw = new StringWriter(new
StringBuilder(resultString));
string output = "";
long i = 0;
string strline = "";
long linenumber = (int)ex.LineNumber;
long lineposition = (int)ex.LinePosition;
while (i <
linenumber - 1)
{
strline =
str.ReadLine();
stw.WriteLine(strline);
i = i +
1;
}
strline =
str.ReadLine();
string
strOffendingCharacter = strline.ToString().Substring((int)lineposition - 2, 1);
string
strOffendingCharacterAndFollowing5 = strline.ToString().Substring((int)lineposition - 2, 5);
switch
(strOffendingCharacter)
{
case "<":
strline =
strline.Substring(0, (int)lineposition - 2) +
"<" + strline.Substring((int)lineposition - 1);
break;
case "&":
//
ensure we are not replacing the ampersand in an already escaped special
character (<, >, ', " or &)
switch
(strOffendingCharacterAndFollowing5.Substring(1, 3))
{
case "lt;":
break;
case "gt;":
break;
default:
switch
(strOffendingCharacterAndFollowing5.Substring(1, 4))
{
case "amp;":
break;
default:
switch
(strOffendingCharacterAndFollowing5)
{
case "apos;":
break;
case "quot;":
break;
default:
strline =
strline.Substring(0, (int)lineposition - 2) +
"&" + strline.Substring((int)lineposition - 1);
break;
}
break;
}
break;
}
break;
}
stw.WriteLine(strline);
strline =
str.ReadToEnd();
stw.WriteLine(strline);
output =
stw.ToString();
str.Close();
str = null;
stw.Flush();
stw.Close();
stw = null;
resultString =
EscapeXmlSpecialCharacters(output);
}
return
resultString;
}
---- Stephen D Green On 18 July 2011 01:34, David Lee <dlee@calldei.com> wrote:
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








