Как проверить действительный xml в строковом вводе перед вызовом .LoadXml ()
Я бы предпочел сделать это без перехвата исключения в LoadXml() и использовать эти результаты как часть моей логики. Любые идеи для решения, которое не требует ручного анализа xml самостоятельно? Я думаю, что VB имеет возвращаемое значение false для этой функции вместо того, чтобы генерировать исключение XmlException. Ввод XML предоставляется пользователем. Спасибо большое!
if (!loaded)
{
this.m_xTableStructure = new XmlDocument();
try
{
this.m_xTableStructure.LoadXml(input);
loaded = true;
}
catch
{
loaded = false;
}
}
Ответы 5
Использование XmlValidatingReader предотвратит исключения, если вы предоставите свой собственный ValidationEventHandler.
Просто поймай исключение. Небольшие накладные расходы от перехвата исключения исчезают по сравнению с синтаксическим анализом XML.
Если вам нужна функция (по стилистическим причинам, а не для производительности), реализуйте ее самостоятельно:
public class MyXmlDocument: XmlDocument
{
bool TryParseXml(string xml){
try{
ParseXml(xml);
return true;
}catch(XmlException e){
return false;
}
}
Вы сделали замеры, чтобы доказать это? Также помните, что try-catch налагает (относительно небольшое) снижение производительности только в том случае, если исключение действительно сгенерировано.
Откуда берется XML? Если большую часть времени вы ожидаете наличия действительного XML, не стоит тратить время на проверку при каждом вызове. Просто обработайте исключение и двигайтесь дальше.
Стоимость проверки предварительного синтаксического анализа XML - это, по сути, полный проход по XML с отслеживанием состояния и проверкой действительности всего текста. Не могу поверить, что это дешевле, чем случайное исключение XmlException.
Как уже было сказано, я лучше поймаю исключение, но, используя XmlParserContext, вы можете попытаться проанализировать «вручную» и перехватить любую аномалию; однако, если вы не анализируете 100 xml-фрагментов в секунду, почему бы не перехватить исключение?
Если уловка для вас слишком сложна, вы можете заранее проверить XML, используя XML-схему, чтобы убедиться, что XML в порядке, но это, вероятно, будет хуже, чем уловка.
Мне не удалось заставить работать XmlValidatingReader и ValidationEventHandler. Исключение XmlException по-прежнему создается для неправильно сформированного xml. Я проверил это, просмотрев методы с отражателем.
Мне действительно нужно проверять сотни коротких фрагментов XHTML в секунду.
public static bool IsValidXhtml(this string text)
{
bool errored = false;
var reader = new XmlValidatingReader(text, XmlNodeType.Element, new XmlParserContext(null, new XmlNamespaceManager(new NameTable()), null, XmlSpace.None));
reader.ValidationEventHandler += ((sender, e) => { errored = e.Severity == System.Xml.Schema.XmlSeverityType.Error; });
while (reader.Read()) { ; }
reader.Close();
return !errored;
}
XmlParserContext тоже не работал.
Кому-нибудь удается с регулярным выражением?
> Кому-нибудь удается с регулярным выражением? Напоминает мне известную цитату: «Некоторые люди, столкнувшись с проблемой, думают:« Я знаю, я буду использовать регулярные выражения ». Теперь у них две проблемы».
Вы шутите о регулярном выражении, верно? Инструмент не подходит для работы. По сути, это та же проблема, что и эта: stackoverflow.com/questions/1732348/…
этот недопустимый текст считается действительным: <root><elem>sdf</elem>>>>> </root>
@Amit String <root><elem>sdf</elem>>>>></root> (с добавленным XML-объявлением <?xml version = "1.0"?>) является допустимым XML. Действительность может быть подтверждена с помощью Валидатор W3C.
Это происходит при загрузке страницы в среде с очень высокой нагрузкой, накладные расходы из-за исключения небольшие, но достаточно значительны, чтобы их следует избегать.