Compruebe XML bien formado sin try / catch?

¿Alguien sabe cómo puedo verificar si una cadena contiene XML bien formado sin usar algo como XmlDocument.LoadXml() en un bloque try / catch? Recibí comentarios que pueden ser XML o no, y quiero un código que reconozca que la entrada puede no ser XML sin depender de un try / catch, tanto para la velocidad como sobre el principio general de que circunstancias no excepcionales no deberían boost excepciones Actualmente tengo un código que hace esto;

 private bool IsValidXML(string value) { try { // Check we actually have a value if (string.IsNullOrEmpty(value) == false) { // Try to load the value into a document XmlDocument xmlDoc = new XmlDocument(); xmlDoc.LoadXml(value); // If we managed with no exception then this is valid XML! return true; } else { // A blank value is not valid xml return false; } } catch (System.Xml.XmlException) { return false; } } 

Pero parece algo que no debería requerir el try / catch. La excepción está causando un infierno durante la depuración porque cada vez que verifico una cadena, el depurador se romperá aquí, ‘ayudándome’ con mi molesto problema.

No conozco una forma de validar sin excepción, pero puede cambiar la configuración del depurador para que solo se rompa en XmlException si no se XmlException , eso debería resolver sus problemas inmediatos, incluso si el código aún no es elegante.

Para hacerlo, vaya a Debug / Exceptions … / Common Language Runtime Exceptions y busque System.Xml.XmlException, luego asegúrese de que solo esté marcada (no lanzada) “User-unhandled”.

Steve,

Tuvimos un tercero que accidentalmente a veces nos enviaba JSON en lugar de XML. Esto es lo que implementé:

 public static bool IsValidXml(string xmlString) { Regex tagsWithData = new Regex("<\\w+>[^<]+"); //Light checking if (string.IsNullOrEmpty(xmlString) || tagsWithData.IsMatch(xmlString) == false) { return false; } try { XmlDocument xmlDocument = new XmlDocument(); xmlDocument.LoadXml(xmlString); return true; } catch (Exception e1) { return false; } } [TestMethod()] public void TestValidXml() { string xml = "true"; Assert.IsTrue(Utility.IsValidXml(xml)); } [TestMethod()] public void TestIsNotValidXml() { string json = "{ \"result\": \"true\" }"; Assert.IsFalse(Utility.IsValidXml(json)); } 

Esa es una forma razonable de hacerlo, excepto que IsNullOrEmpty es redundante (LoadXml puede resolverlo bien). Si mantiene IsNullOrEmpty, haga if (! String.IsNullOrEmpty (value)).

Básicamente, sin embargo, su depurador es el problema, no el código.

Agregue el atributo [System.Diagnostics.DebuggerStepThrough] al método IsValidXml . Esto suprime que XmlException sea capturado por el depurador, lo que significa que puede activar la captura de excepciones de primer cambio y este método en particular no será depurado.

Tenga XmlDocument usar XmlDocument para poder cargar un elemento a lo largo de las líneas de <0>some text usando XmlDocument doc = (XmlDocument)JsonConvert.DeserializeXmlNode(object) sin una excepción.

Los nombres de elementos numéricos no son válidos xml, y en mi caso no ocurrió un error hasta que intenté escribir el xmlDoc.innerText en un tipo de datos de servidor Sql de xml.

Así como lo valido ahora, y se lanza una excepción
XmlDocument tempDoc = XmlDocument)JsonConvert.DeserializeXmlNode(formData.ToString(), "data"); doc.LoadXml(tempDoc.InnerXml);

La clase XmlTextReader es una implementación de XmlReader y proporciona un analizador rápido y de rendimiento. Hace cumplir las reglas de que XML debe estar bien formado. No es un analizador de validación ni de validación, ya que no tiene DTD o información de esquema. Puede leer texto en bloques o leer caracteres de una secuencia.

Y un ejemplo de otro artículo de MSDN al que he agregado código para leer todo el contenido de la transmisión XML.

 string str = "AQID"; XmlTextReader r = new XmlTextReader(new StringReader(str)); try { while (r.Read()) { } } finally { r.Close(); } 

fuente: http://bytes.com/topic/c-sharp/answers/261090-check-wellformedness-xml

No estoy de acuerdo con que el problema sea el depurador. En general, para casos no excepcionales, se deben evitar excepciones. Esto significa que si alguien está buscando un método como IsWellFormed() que devuelve verdadero / falso en función de si la entrada está bien formada XML o no, las excepciones no se deben arrojar dentro de esta implementación, independientemente de si son capturadas y manipuladas o no. .

Las excepciones son costosas y no deberían encontrarse durante una ejecución exitosa normal. Un ejemplo es escribir un método que comprueba la existencia de un archivo y usar File.Open y capturar la excepción en el caso de que el archivo no exista. Esta sería una implementación pobre. En File.Exists() lugar debe usarse File.Exists() (y es de esperar que la implementación de eso no se limite a poner a prueba / capturar algún método que arroje una excepción si el archivo no existe, estoy seguro de que no).

Solo mis 2 centavos, hay varias preguntas al respecto, y la mayoría de la gente está de acuerdo con el hecho de que “hay basura en la basura”. No estoy en desacuerdo con eso, pero personalmente encontré la siguiente solución rápida y sucia, especialmente para los casos en los que trata con datos xml de terceros que simplemente no se comunican fácilmente con usted. No evita usar try / catch – pero lo usa con una granularidad más fina, así que en los casos donde la cantidad de caracteres xml no válidos no es tan grande, ayuda … Usé XmlTextReader, y su método ReadChars () para cada elemento padre, que es uno de los comandos que no hacen comprobaciones bien formadas, como lo hace ReadInner / OuterXml. Por lo tanto, es una combinación de Read () y ReadChars () cuando Read () se repite en un nodo primario. Por supuesto, esto funciona porque puedo suponer que la estructura básica del XML está bien, pero los contenidos (valores) de ciertos nodos pueden contener caracteres especiales que no han sido reemplazados por & ..; equivalente … (encontré un artículo sobre esto en algún lugar, pero no puedo encontrar el enlace de origen en este momento)

Mis dos centavos. Esto fue bastante simple y sigue algunas convenciones comunes ya que se trata de analizar …

 public bool TryParse(string s, ref XmlDocument result) { try { result = new XmlDocument(); result.LoadXml(s); return true; } catch (XmlException ex) { return false; } } 
Intereting Posts