Convertir XML a Markdown en línea gratis

Convertir XML a Markdown: fuera etiquetas, dentro la jerarquía

XML tiene una costumbre que no comparte ningún otro formato: escribe el nombre de cada elemento dos veces. Una para abrirlo y otra para cerrarlo. Súmale prefijos de espacio de nombres, atributos y la indentación que lo hace legible, y acabas de forma habitual con un archivo donde las etiquetas pesan más que el contenido que envuelven. Un catálogo de productos con 200 artículos puede ocupar miles de líneas y seguir conteniendo página y media de información real.

Pasar de XML a Markdown conserva el árbol y tira la ceremonia. El anidamiento de elementos se convierte en niveles de encabezado, los hermanos repetidos se convierten en listas o tablas, y los corchetes angulares desaparecen. Sube un archivo .xml arriba y lo tendrás de vuelta en unos segundos: gratis, sin registro, tope de 50 MB, sin retener nada.

En qué se convierte el árbol de elementos

La conversión recorre el documento y traduce cada construcción:

• Los elementos contenedores pasan a ser encabezados. Un elemento con elementos hijos pero sin texto propio es una sección. Su profundidad en el árbol fija el nivel de encabezado, así que un esquema empresarial de cinco niveles llega como un documento correctamente estructurado.
• Los elementos hoja pasan a ser valores etiquetados. <author>Ursula Le Guin</author> se lee como author: Ursula Le Guin. Un nombre en lugar de dos, sin corchetes.
• Los hermanos repetidos pasan a ser listas o tablas: lo vemos más abajo, porque es donde está casi todo el valor.
• El contenido mixto se conserva en línea. Es el caso en que se entremezclan texto y elementos hijos, como en <para>See the <ref>appendix</ref> for details</para>. Los conversores ingenuos parten eso en fragmentos y pierdes la frase. Debe salir como una única línea legible con la referencia intacta.
• Comentarios, instrucciones de procesamiento y declaración XML se van. Ninguno de ellos es contenido.

Los atributos: lo que se pierde sin que nadie se dé cuenta

XML guarda datos en dos sitios: entre las etiquetas y dentro de ellas. El texto de los elementos es evidente. Los atributos son fáciles de pasar por alto, y muchas extracciones ingenuas los tiran sin avisar. Eso está bien cuando son metadatos del tipo id="4471". Es un desastre cuando son la carga útil.

Y pasa a menudo. <price currency="GBP">49.99</price> no significa nada sin la moneda. Los formatos de configuración son peores: Maven, Ant, Spring, los manifiestos de Android y los app.config de .NET meten casi todo en atributos, así que una extracción que solo mire el texto de los elementos devuelve un documento estructuralmente correcto y prácticamente vacío. Si conviertes un archivo de configuración y la salida parece sospechosamente corta, este es el motivo.

En la salida Markdown los atributos deben quedarse junto al elemento al que pertenecen en lugar de esfumarse: como un breve calificador al lado del valor, o como columnas extra cuando el elemento forma parte de un conjunto repetido. Contrasta la primera pantalla de salida con el original antes de confiarle nada importante. Diez segundos de repaso valen más que una conversación confusa con un modelo media hora después.

Los hermanos repetidos se vuelven tablas

La mejor forma posible de un XML es un padre con muchos hijos idénticos: elementos <item> en un feed RSS, elementos <row> en una exportación de base de datos, registros <employee> en un volcado de recursos humanos. Cada hijo tiene los mismos subelementos en el mismo orden.

Eso colapsa en una sola tabla Markdown con barras verticales. Los nombres de los subelementos pasan a ser cabeceras de columna, cada registro pasa a ser una fila, y la repetición de etiquetas — que en el archivo original significaba escribir el nombre de cada campo dos veces por registro — ocurre exactamente una vez, en la cabecera. Es la mayor reducción que vas a ver en cualquier conversión de XML, y es la razón para elegir Markdown en lugar de texto plano con cualquier cosa que tenga forma de registro.

Se degrada cuando los registros son irregulares: elementos opcionales presentes en unos hijos y en otros no, o un hijo que contiene un bloque anidado que los demás no tienen. Te saldrán huecos, o la parte anidada empujada fuera, debajo de la tabla. Si tus datos son realmente rectangulares, exportar a CSV y usar el conversor de CSV a Markdown produce tablas más limpias. Y si el origen tiene forma de JSON y no de etiquetas, el conversor de JSON a Markdown aborda el mismo problema desde el otro lado.

Espacios de nombres, sobres SOAP y ruido corporativo

El XML del mundo real casi nunca está limpio. Hay tres cosas que lo inflan muy por encima de su contenido informativo:

• Espacios de nombres. Las declaraciones xmlns y los prefijos tipo soap:, xsi:, atom: o dc: existen para evitar colisiones de nombres entre vocabularios. Para quien lee no significan nada. Los prefijos se eliminan en la conversión, así que <dc:creator> se lee como creator. La única vez que importa es cuando dos espacios de nombres usan de verdad el mismo nombre local para cosas distintas: es raro, pero compruébalo si estás fusionando vocabularios.
• Sobres SOAP. La respuesta de un servicio web envuelve la parte que te interesa en Envelope y Body, a menudo con cabeceras llenas de tokens de seguridad y datos de enrutado. Al convertir obtienes un documento donde por fin se ve la carga útil en lugar de estar enterrada cuatro niveles dentro de plantilla que tienes que ir saltándote mentalmente.
• Referencias a esquemas. xsi:schemaLocation, las declaraciones DTD y los atributos de validación describen cómo debe comprobarse el archivo, no qué dice. Ruido para cualquier propósito de los que nos ocupan aquí.

Los feeds RSS y Atom están en el extremo amable de esto. Son uniformes, poco profundos, y se convierten en una lista limpia de entradas con fecha: una forma razonable de darle a un modelo un mes de publicaciones de un blog. Ten en cuenta que las descripciones de los feeds suelen llevar HTML escapado dentro del XML, que llega como marcado a tu salida; pásalo por el conversor de HTML a Markdown si lo quieres limpio, o usa Web2Txt para descargar las páginas como es debido.

Cuándo conviene quedarse con el XML en bruto

Respuesta directa, ya que muchas páginas que venden conversores no te la van a dar: los modelos leen XML sin problema. Es verboso, pero no es ambiguo y está extraordinariamente representado en los datos de entrenamiento. Convertir es una elección, no un requisito.

Déjalo en bruto cuando pidas expresiones XPath, una hoja XSLT, un parser o un esquema: cualquier cosa en la que el modelo tenga que reproducir nombres exactos de elemento, prefijos de espacio de nombres y la distinción entre atributo y elemento. Markdown suaviza a propósito justamente esos detalles. Pega en su lugar un fragmento representativo del archivo real.

Convierte cuando lo tenga que leer una persona, cuando estés intentando entender rápido un esquema desconocido, o cuando el archivo original sea casi todo etiquetas y vayas justo de contexto. Esas son ventajas reales. Lo demás es preferencia.

El XML que no sabías que era XML

Bastantes formatos que consideras binarios son XML comprimido por debajo. Renombra un .docx a .zip, descomprímelo y encontrarás document.xml más un montón de archivos de relaciones. Con EPUB pasa lo mismo: documentos de contenido XHTML y un manifiesto de paquete XML dentro de un zip. Y con .pptx, y con .xlsx.

Podrías descomprimir uno y convertir el XML a mano. No lo hagas: el marcado interno está lleno de rangos de estilo, control de cambios e instrucciones de maquetación que ahogan el texto. Usa Word a Markdown o EPUB a Markdown, que saben qué partes de ese XML son contenido y cuáles son instrucciones de formato. Esta página es para el XML que te llegó como XML: feeds, exportaciones, respuestas de API, configuración, intercambio de datos.

Preguntas frecuentes

¿Cómo paso de XML a Markdown?

Sube el .xml aquí arriba y la estructura del documento se proyecta sobre Markdown: la jerarquía de elementos pasa a niveles de encabezado y los elementos hermanos repetidos pasan a listas o tablas. Gratis, 50 MB por archivo, sin registro. Conserva la forma del documento, que es la diferencia con aplanarlo a texto.

¿La jerarquía de elementos se convierte en niveles de encabezado?

Esa es la correspondencia, sí: un elemento anidado se convierte en un encabezado más profundo. Funciona bien con XML con forma de documento, como DocBook, TEI o la exportación de un artículo, donde el anidamiento refleja de verdad secciones dentro de secciones. Funciona mal con XML con forma de datos, donde el anidamiento refleja un esquema de base de datos y acabas con doce niveles de encabezado describiendo un registro.

¿Qué pasa con los prefijos de espacio de nombres?

Se eliminan de la salida. Un encabezado que ponga dc:title o tei:head no le dice nada a una persona y menos aún a un modelo, así que los prefijos se quitan y se usa el nombre local del elemento. Si dos espacios de nombres del mismo documento definen el mismo nombre local, se fundirán en uno: es raro, pero merece un vistazo si ves encabezados que parecen duplicados.

¿Sirve para convertir DocBook o DITA?

Para una primera pasada, sí. La prosa, las secciones, las listas y el énfasis en línea se trasladan bien porque esos formatos los marcan de forma explícita. El perfilado condicional, las referencias de contenido, las inclusiones por entidad y la resolución de referencias cruzadas no sobreviven: son justo las partes por las que valía la pena usar el formato, y ningún conversor genérico puede resolverlas.

¿Cuál elijo para un corpus XML grande?

Texto, en la mayoría de los casos. Si estás generando embeddings sobre miles de registros, la sintaxis de encabezados es sobrecarga repetida en cada fragmento sin ninguna ventaja para la recuperación. Markdown se gana el sitio cuando una persona o un modelo va a leer un documento y necesita saber dónde están las secciones.

Texto plano en su lugar, y el resto de las herramientas

Si no quieres ninguna estructura — texto para embeddings, un índice de búsqueda o el menor número de tokens posible — usa XML a texto plano, que saca el contenido de entre las etiquetas y no deja nada más. El selector de formato de arriba alterna entre los dos y mantiene tu archivo cargado, así que comparar ambas salidas cuesta un clic. El contador de tokens bajo la salida te dice cuánto cuesta cada una.

Si el XML es un archivo dentro de un proyecto — una configuración, un descriptor de build, una fixture — convertirlo solo le da al modelo los datos sin el código que los rodea. El conversor de repositorios de GitHub a texto y el conversor de directorios locales te permiten llevarte el XML y quien lo consume a la vez, que suele ser la unidad más útil. File2Txt maneja todos los formatos compatibles en un solo sitio, y la guía para preparar archivos para LLM cubre los principios generales.

Repo2Txt está desarrollado y mantenido por v12hero, un desarrollador independiente que crea aplicaciones nativas y web centradas en la privacidad.