Acerca de esta herramienta
Las respuestas SOAP, los sitemaps, los POM de Maven y los informes JUnit XML son difíciles de leer en una sola línea. Este formateador comprueba primero que la entrada esté bien formada con el propio parser XML del navegador y después vuelve a aplicar la sangría con un tokenizador que deja las secciones CDATA, los comentarios, las instrucciones de procesamiento y el DOCTYPE exactamente como estaban escritos. Los elementos que solo contienen texto se quedan en una línea, así que la salida se lee como XML escrito a mano y no como una etiqueta por línea.
Cómo usarla
- Pega XML o carga el documento de pedido de ejemplo.
- Elige “Format” y una sangría (2 espacios, 4 espacios o tabulador), o “Minify” para dejarlo en una línea.
- Si el XML no está bien formado, corrige la línea y la columna que muestra el banner rojo.
- Copia o descarga el resultado.
Bien formado no es lo mismo que válido
Un XML bien formado sigue las reglas de sintaxis: exactamente un elemento raíz, todas las etiquetas cerradas y correctamente anidadas, valores de atributos entre comillas y caracteres especiales escapados. Un XML válido además está bien formado y se ajusta a un schema (XSD) o DTD que define qué elementos y valores se permiten. Este formateador comprueba que el documento esté bien formado, porque tiene que poder analizarse antes de volver a aplicar la sangría. Comprobarlo contra un XSD es un paso aparte.
Motivos habituales por los que un XML no se puede analizar
- Un ampersand o un signo menor que sin escapar en el texto: escribe
&y<, o envuelve el texto en una sección CDATA. - Etiquetas que solo difieren en mayúsculas, como
<Order>…</order>: XML distingue mayúsculas y minúsculas. - Más de un elemento de nivel superior: envuélvelos en una única raíz.
- Un valor de atributo sin comillas, como en
<item id=7>. - Un prefijo de namespace sin declarar, como
<soap:Envelope>sin atributoxmlns:soap="…". - Cualquier cosa antes de la declaración XML:
<?xml version="1.0"?>deben ser los primeros caracteres, sin espacios delante.
Dónde se encuentran los testers con XML
Las APIs SOAP y empresariales heredadas, los informes de test JUnit XML (el formato que leen la mayoría de los servidores de CI), los archivos pom.xml de Maven, los sitemaps, los feeds RSS y los layouts de Android son XML. Playwright genera JUnit XML con reporter: [['junit', { outputFile: 'results.xml' }]], y formatear ese archivo es la forma más rápida de ver por qué el CI dio un test por fallido.
Para hacer assertions sobre XML en código, REST Assured admite matchers XPath como body(hasXPath("/order/status[text()='SHIPPED']")). En la línea de comandos, xmllint --format file.xml formatea un archivo, y xml.dom.minidom.parseString(text).toprettyxml() de Python hace lo mismo en un script. Para probar expresiones XPath de forma interactiva, usa el probador de XPath y selectores CSS.
Preguntas frecuentes: Formateador XML
¿Formatear cambia mis datos?
El texto formado solo por espacios entre etiquetas se elimina y se recrea como sangría, y el texto dentro de los elementos se recorta. Es inofensivo en XML orientado a datos, pero en contenido mixto o en elementos donde importa xml:space="preserve", compara el resultado antes de usarlo.
¿Se conservan las secciones CDATA y los comentarios?
Sí. Se copian byte a byte, incluido cualquier marcado dentro de CDATA. En el modo “Minify” puedes eliminar opcionalmente los comentarios.