Cómo validar XML y corregir errores de formato

Quieres validar tu XML, lo pegas en un analizador y te devuelve una avalancha de errores en rojo: "not well-formed", "junk after document element" o un número de línea y de columna que no dice nada a primera vista. Casi todos estos errores vienen de uno de siete fallos de sintaxis, y cada uno tiene una solución rápida y predecible. El visor XML de Static.app, gratuito y en el navegador, avisa cuando la entrada no está bien formada y vuelve a aplicar la sangría al resto, y así es como encuentras dónde se rompe.

Bien formado frente a válido: dos comprobaciones distintas

Que un documento esté bien formado es una comprobación de sintaxis, y que sea válido es una comprobación de esquema que se añade a la anterior. Un documento bien formado cumple las reglas de sintaxis de XML. Un documento válido está bien formado y además se ajusta a un DTD o a un XSD. Mucha gente usa los dos términos como sinónimos, pero saber cuál de las dos comprobaciones falla te dice dónde mirar.

• Bien formado se refiere solo a la sintaxis. El documento tiene exactamente un elemento raíz, todas las etiquetas están cerradas, las etiquetas se anidan correctamente, los valores de los atributos van entre comillas y los caracteres especiales &, < y > están escapados. Los nombres de etiqueta distinguen mayúsculas de minúsculas, así que <Title> y </title> no coinciden. Si se rompe cualquiera de estas reglas, ningún analizador XML leerá el archivo.
• Válido es una comprobación más estricta y opcional que se suma a la de estar bien formado. Un documento válido está bien formado y se ajusta a un esquema, un DTD o un XSD, que define qué elementos se permiten, en qué orden y con qué atributos. Un documento puede estar perfectamente bien formado y aun así no ser válido frente a un esquema.

La mayoría de los problemas del día a día del tipo "mi XML no se analiza" son problemas de XML mal formado. Arregla primero la sintaxis y preocúpate del esquema cuando el analizador ya pueda cargar el archivo.

Los errores más comunes de XML mal formado y cómo arreglar cada uno

Siete fallos de sintaxis explican casi todos los errores de XML mal formado: etiquetas sin cerrar o que no coinciden, más de un elemento raíz, ampersands y corchetes angulares sin escapar, valores de atributo sin comillas, caracteres sueltos antes del prólogo, orden de anidación incorrecto y caracteres de control no válidos. Cada uno tiene un único arreglo mecánico.

Etiquetas sin cerrar o que no coinciden

Cada etiqueta de apertura necesita una de cierre con el mismo nombre y las mismas mayúsculas. <item>shoes</item> es correcto; <item>shoes o <item>shoes</Item> no lo son. Los elementos vacíos pueden cerrarse a sí mismos, como <br/>. Cuando un analizador informa de un final de archivo inesperado, la causa suele ser una etiqueta que se dejó abierta antes.

Más de un elemento raíz

Un documento XML debe tener un único elemento de nivel superior que envuelva todo lo demás. Dos elementos hermanos de nivel superior sin nada alrededor, como <user>...</user><user>...</user>, provocan "junk after document element". Envuélvelos en un contenedor, por ejemplo <users>...</users>.

Ampersands y corchetes angulares sin escapar

Un & sin escapar inicia una referencia de entidad, así que Ben & Jerry dentro del contenido de texto es un error. Escribe Ben & Jerry. Del mismo modo, un < o un > literal en el texto debe escribirse como < o >. Si tu contenido tiene mucho texto parecido a marcado, envuélvelo en una sección <![CDATA[ ... ]]> en lugar de escapar cada carácter.

Valores de atributo sin comillas

Todos los valores de atributo necesitan comillas. <book id=42> no está bien formado; usa <book id="42">. Valen comillas simples o dobles, siempre que coincidan en el mismo atributo.

Caracteres sueltos antes del prólogo

La declaración XML <?xml version="1.0"?> debe ser lo primero de todo en el archivo, sin espacios, líneas en blanco ni caracteres delante. Un culpable oculto frecuente es una marca de orden de bytes (BOM) de UTF-8 o un espacio copiado antes de la declaración, que produce errores como "content is not allowed in prolog". Borra todo lo que haya antes de <?xml.

Orden de anidación incorrecto

Las etiquetas deben cerrarse en orden inverso al de apertura. <b><i>text</b></i> está en desorden; lo correcto es <b><i>text</i></b>. Los elementos que se solapan son uno de los fallos estructurales más comunes cuando se edita XML a mano.

Caracteres no válidos

XML 1.0 no admite la mayoría de los caracteres de control, como un salto de página o un byte nulo, aunque parezcan invisibles. Suelen colarse al copiar y pegar desde otro programa. Eliminar el byte problemático, o sustituirlo por una referencia de carácter válida, resuelve el error.

Cómo el visor XML saca a la luz el fallo

El visor XML de Static.app saca a la luz el fallo volviendo a aplicar la sangría al documento y negándose a formatear una entrada que no esté bien formada. Leer el error en bruto de un analizador es mucho más fácil cuando puedes ver el documento formateado. El visor XML, gratuito, está pensado justo para esto y funciona por completo en tu navegador: nada de lo que pegas se sube a un servidor.

1. Pega tu XML en el panel de entrada o abre un archivo .xml de tu ordenador. Hay un botón Ejemplo si quieres probarlo primero.
2. Pulsa Formatear. El visor XML vuelve a aplicar la sangría al documento con la anidación correcta para que la estructura se recorra con facilidad, y comprueba sobre la marcha que la entrada esté bien formada.
3. Si algo está roto, el visor señala el problema en lugar de formatear en silencio un texto defectuoso, y así puedes ir directo a la etiqueta sin cerrar o al carácter suelto y corregirlo.
4. Cuando el documento esté limpio, copia el resultado formateado o descárgalo como archivo.

En cuanto a la seguridad, el visor XML rechaza las declaraciones DOCTYPE y las entidades externas, lo que lo protege frente a ataques XXE (XML external entity). Nunca deberías "activar la carga de DTD externos" para que un documento rebelde se analice; esa es justo la puerta por la que entra XXE. Si un archivo solo se analiza con las entidades externas activadas, trátalo como una señal de alarma sobre el archivo, no como un ajuste que haya que cambiar.

Cuando ya esté bien formado

Cuando tu XML esté bien formado, el conversor de XML a JSON de Static.app convierte el documento en un objeto JSON estructurado. Esa es la forma que suele esperar una aplicación JavaScript o una API. Y si estás dudando qué formato elegir en primer lugar, la guía JSON vs XML explica dónde encaja cada uno.

Preguntas frecuentes

Las cuatro respuestas siguientes explican qué separa un XML bien formado de uno válido, por qué un ampersand suelto rompe un documento, si el visor XML envía tus datos a algún sitio y si puede comprobar un documento contra un esquema.

¿Qué diferencia hay entre XML bien formado y XML válido?

Bien formado significa que el documento cumple las reglas de sintaxis de XML: un elemento raíz, etiquetas cerradas y bien anidadas, atributos entre comillas y caracteres especiales escapados. Válido significa que está bien formado y además se ajusta a un esquema (un DTD o un XSD) que define los elementos y la estructura permitidos. Un documento puede estar bien formado sin ser válido, pero no puede ser válido sin estar antes bien formado.

¿Por qué un ampersand hace que mi XML esté mal formado?

En XML, un & suelto inicia una referencia de entidad, así que el analizador espera que después venga algo como & o &. Un ampersand aislado en el contenido de texto rompe esa expectativa. Escápalo como & o envuelve el texto que lo rodea en una sección CDATA si contiene muchos caracteres especiales.

¿El visor XML envía mis datos a algún sitio?

No, siempre que tengas JavaScript activado. El visor XML formatea y comprueba entonces tu XML directamente en tu navegador, así que el contenido nunca se guarda en un servidor. Con JavaScript desactivado, el formulario se envía a nuestro servidor. Además, el visor bloquea DOCTYPE y las entidades externas, de modo que ver XML de origen dudoso es seguro.

¿Puede comprobar mi XML contra un esquema?

No. El visor XML de Static.app comprueba solo que el documento esté bien formado: confirma que la sintaxis es correcta y lo formatea para leerlo con comodidad. La validación completa contra un DTD o un XSD concreto es un paso aparte. Que el documento esté bien formado es el requisito previo, ya que un validador de esquemas no puede comprobar un archivo que el analizador ni siquiera es capaz de cargar.