Convertir XML a Texto en línea gratis

Convertir XML a texto plano: sacar el contenido de entre los corchetes angulares

Hay un tipo de archivo que aparece siempre que estás armando un corpus de texto: una exportación XML de algo realmente interesante — resúmenes de artículos científicos, transcripciones judiciales, un archivo digitalizado, una década de entradas de blog — donde la prosa que buscas está enterrada bajo un esquema que alguien diseñó en 2006. Las palabras están ahí. Solo que envueltas en tres capas de etiquetas con prefijos de espacio de nombres encima.

Esta página extrae ese contenido y te devuelve texto y nada más. Sin encabezados, sin tablas, sin marcado de ningún tipo. Es lo que quieres cuando el destino es un modelo de embeddings, un índice de búsqueda, un script de PLN o cualquier pipeline que trate la puntuación como ruido. Sube un archivo .xml arriba: gratis, sin registro, límite de 50 MB, nada se almacena.

Qué sale por el otro lado

Extraer no es simplemente borrar todo lo que hay entre < y >. Hay varias cosas que hay que resolver bien o la salida queda sutilmente mal:

• Las referencias de entidad se decodifican. Un XML no puede contener un ampersand suelto, así que los documentos reales están llenos de &, <, " y formas numéricas como ’ para un apóstrofo tipográfico. Si no se decodifican, contaminan los recuentos de palabras y hacen fallar las coincidencias de búsqueda. Aquí vuelven a ser los caracteres que representan.
• Las secciones CDATA se desenvuelven. <![CDATA[ ... ]]> es la forma en que XML cuela contenido que a su vez lleva marcado: HTML dentro de una descripción RSS, un fragmento de SQL, un bloque de JavaScript. La envoltura se va, el contenido se queda.
• Los nodos de texto que solo tienen espacios se descartan. Un XML indentado tiene un nodo de texto entre cada par de etiquetas que no contiene más que un salto de línea y unos espacios. Si los conservas, el 60 % de tu salida son líneas en blanco.
• Los nombres de elemento desaparecen del todo. A diferencia de la versión Markdown, aquí los nombres de etiqueta no se conservan como etiquetas descriptivas. Obtienes los valores, no el esquema.
• Comentarios, declaración XML, DTD e instrucciones de procesamiento se van. Ninguno de ellos es contenido.

El bug de las palabras pegadas, y por qué importa

Este es el fallo que se le escapa a casi cualquier eliminador de etiquetas ingenuo, incluidas muchas de las soluciones rápidas con expresiones regulares que la gente copia de los foros. Toma contenido mixto: texto y elementos hijos entremezclados dentro del mismo padre:

<p>See the <ref>appendix</ref> for details</p>

Si quitas las etiquetas sin cuidado acabas con «See theappendixfor details», porque la etiqueta que eliminaste estaba haciendo de separador de palabras. Y si te vas al otro extremo e insertas un salto de línea en cada etiqueta, obtienes una frase partida en tres fragmentos repartidos en tres líneas. Ninguna de las dos sirve: la primera rompe la tokenización, la segunda rompe la segmentación de oraciones, y ambas corrompen en silencio todo lo que venga después y dé por hecho que está leyendo prosa.

Un tratamiento correcto mantiene los elementos en línea en línea y solo corta en los límites de bloque de verdad. Si usas otra herramienta para extraer el texto de un archivo XML, esto es lo primero que hay que probar: busca un párrafo con una etiqueta en medio y comprueba que la frase sobrevivió.

El problema de los archivos de configuración

Ahora la advertencia honesta, porque te va a ahorrar cinco minutos de desconcierto. El XML guarda datos en dos sitios: entre las etiquetas y en los atributos que van dentro de ellas. La extracción de texto, por definición, se queda con lo primero. Hay XML muy común que casi no tiene nada de eso.

Los manifiestos de Android, el app.config de .NET, los archivos de build de Ant, las definiciones de beans de Spring, muchos SVG: todos ponen prácticamente todo en atributos. Pasa uno por un extractor de texto y recuperas cuatro palabras sueltas, o un archivo vacío, y parece que la herramienta falló. No falló; no había texto de elemento que encontrar.

Para esos archivos usa el conversor de XML a Markdown, que mantiene los atributos pegados a los elementos que califican. El selector de formato al principio de esta página cambia de página y se lleva tu archivo con él, así que es un clic y no otra subida. Regla práctica: la prosa vive en los elementos, los ajustes viven en los atributos. La extracción de texto es para los primeros.

Dónde el texto plano es claramente la decisión correcta

XML es el formato nativo de una cantidad enorme de texto bien curado, en buena medida porque las instituciones se estandarizaron en él antes de que existiera JSON. Ese legado es donde este conversor se gana el sitio:

• Construir corpus. Volcados de resúmenes académicos, textos literarios codificados en TEI, actas parlamentarias y jurídicas, catálogos de museos y bibliotecas. Todo prosa densa, todo envuelto en esquemas pesados. Tú quieres la prosa.
• Embeddings y búsqueda vectorial. Si haces el embedding de un fragmento XML en bruto, una parte nada despreciable del vector resultante describe el marcado y no el significado: dos documentos sobre temas que no tienen nada que ver pueden acabar cerca uno del otro solo porque comparten esquema. Quitar las etiquetas te da embeddings sobre el contenido.
• Fragmentación. Los troceadores de tamaño fijo cortan el XML en bruto a mitad de un elemento y producen fragmentos con etiquetas huérfanas. El texto plano se parte por límites de frase y de párrafo, que es para lo que se diseñó el troceador.
• Indexado y análisis de texto. Frecuencias de términos, análisis de sentimiento, modelado de temas, extracción de entidades: todo se distorsiona con los tokens estructurales que se repiten en cada registro.
• Economía de tokens. La verbosidad del XML es llamativa incluso entre los formatos estructurados, porque cada nombre de elemento se escribe dos veces. Quitar las etiquetas de una exportación muy anidada elimina muchísimos tokens que nunca llevaron información. El contador bajo la salida te dice exactamente cuántos.

Cuándo quitar las etiquetas es un error

Los modelos manejan XML en bruto sin dificultad: es verboso pero no ambiguo, y hay muchísimo en los datos de entrenamiento. Convertir es una decisión que tomas por un motivo, no una regla.

• Escribir código contra el documento. Consultas XPath, una hoja XSLT, un parser SAX o DOM, un esquema. Todo eso necesita los nombres exactos de elemento, los prefijos de espacio de nombres y la distinción atributo/elemento intactos. La extracción de texto elimina justamente eso. Pega un fragmento del archivo real.
• La jerarquía es la respuesta. Si la pregunta es bajo qué padre cuelga algo — a qué entorno pertenece un ajuste, en qué sección está una cláusula — aplanar la destruye. Eso es trabajo de Markdown.
• Documentos cargados de atributos, como decíamos arriba.

Preguntas frecuentes

¿Cómo convierto un archivo XML a texto?

Arrastra el .xml al conversor de arriba y el contenido que hay entre las etiquetas vuelve como prosa limpia: sin corchetes angulares, sin prefijos de espacio de nombres, sin atributos. Descárgalo como .txt. Gratis, sin registro, 50 MB por archivo, sin retener nada.

¿Decodifica entidades como & y <?

Sí, y importa más de lo que parece. Un XML no puede contener un ampersand suelto, así que los documentos del mundo real están plagados de &, <, " y referencias numéricas de carácter. Una expresión regular ingenua que quite etiquetas deja todo eso literal en la salida. Un análisis sintáctico de verdad las resuelve a los caracteres que representan.

¿Por qué no borrar todo lo que hay entre corchetes angulares con una regex?

Porque tanto las secciones CDATA como los valores de atributo contienen caracteres que parecen marcado y no lo son. Una regex se comerá tan tranquila el contenido de un bloque <![CDATA[...]]> que lleve HTML dentro, y no tiene forma de distinguir una etiqueta real de un < que aparece dentro del texto entrecomillado de un atributo. Un parser acierta en esos casos; la coincidencia de patrones falla, y falla en silencio.

¿Salen los valores de los atributos?

Lo que obtienes es el texto de los elementos; los atributos son metadatos sobre el elemento, no contenido suyo. Normalmente eso es lo correcto: quieres el resumen, no la versión del esquema. Donde duele es en los formatos que guardan contenido real en atributos, así que si tu salida parece escasa, abre el original y comprueba si las palabras que buscabas están dentro de <tag attr="...">.

¿Funciona con feeds RSS y sitemaps?

Sí: los dos son XML y los dos se convierten. Un feed RSS te da títulos, descripciones y fechas como texto legible, que es una forma rápida de montar un corpus a partir del archivo de un blog. Un sitemap te da una lista de URL, que resulta más útil canalizada a otro sitio que leída como prosa.

Herramientas relacionadas

Un apunte sobre el XML con el que te topas de forma indirecta: los archivos .docx y .epub son XML comprimido por debajo. Puedes descomprimir uno y meter aquí el marcado interno, pero no lo hagas: está saturado de rangos de estilo y metadatos de revisión que ahogan el texto. Usa Word a texto o EPUB a texto, que saben qué partes son contenido. Para marcado que es HTML y no XML está HTML a texto, y para el otro gran formato de datos estructurados, JSON a texto. File2Txt acepta cualquier formato compatible si prefieres no elegir página.

Y cuando el XML está dentro de un repositorio — un POM, un descriptor de build, fixtures de prueba — convertirlo por su cuenta lo deja sin contexto. El conversor de GitHub a texto, el conversor de GitLab y el conversor de directorios locales te dejan meter el XML y el código que lo lee en una sola salida, que casi siempre es más útil. La guía para preparar archivos para LLM cubre el caso general.

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