XML a YAML
Este convertidor transforma un documento XML a YAML legible en tu navegador. Los atributos se convierten en claves con el prefijo @, el texto de un elemento se convierte en #text cuando comparte el elemento con atributos o elementos secundarios, y los elementos hermanos repetidos se convierten en secuencias YAML. Los valores permanecen como cadenas, por lo que un código postal se mantiene intacto, y no se sube nada.
XML a YAML: explicación
XML lleva valores en tres lugares — atributos, contenido de texto y elementos secundarios — y YAML tiene espacio para los tres en una sola asignación, siempre que cada uno tenga un nombre que no pueda entrar en conflicto con los otros. Esa es toda la convención que aplica este convertidor: id="bk101" se convierte en la clave "@id", el texto dentro de un elemento se convierte en "#text" cuando necesita un hogar propio, y los elementos secundarios se convierten en claves cuyos valores son asignaciones o listas. Los prefijos parecen ruido hasta que un elemento tiene un atributo, un hijo y texto a la vez — entonces son la única razón por la que el viaje de ida y vuelta puede ser sin pérdida.
El estilo YAML es el estilo del sitio: sangrado de dos espacios, los guiones de secuencia alineados con su clave principal en lugar de estar anidados debajo, y comillas solo donde la forma simple se malinterpretaría. Esa última regla hace un trabajo real aquí. El texto XML no tiene tipo, por lo que 44.95 es una cadena, y el emisor la escribe como "44.95" precisamente para que un analizador de YAML no reinfiera un número a partir de ella. El resultado es un documento que puede hacer el viaje de ida y vuelta: XML a YAML y de vuelta llega con los mismos valores, los mismos atributos y la misma estructura con la que comenzó.
Todo se ejecuta en esta pestaña del navegador. El XML se analiza con un motor en la página y el YAML se emite desde el árbol analizado; ninguno toca la red — abre DevTools, observa que el panel de red permanece en silencio, y la promesa se verifica a sí misma.
Para enviar el resultado en la otra dirección, el Convertidor de YAML a XML honra las mismas convenciones @ y #text, por lo que no es necesario renombrar nada manualmente.
¿Nuevo en la lectura de la salida YAML? El Guía básica de YAML explica el sangrado, las comillas y las reglas de escalares que sigue el emisor.
Cómo funciona realmente la conversión
El documento se tokeniza una sola vez en un árbol de elementos, atributos y texto, y el emisor de YAML solo ve ese árbol — por lo que las peculiaridades de formato en el origen (sangrado irregular, atributos divididos en varias líneas) no pueden filtrarse en la salida. El árbol encaja en un solo documento con una sola raíz o no lo hace, y el convertidor indica cuál es el caso.
- Análisis: un tokenizador de una sola pasada lee elementos, atributos, texto, comentarios y CDATA; las etiquetas no coincidentes o sin cerrar se rechazan con un número de línea.
- Conversión: cada elemento se convierte en una asignación — atributos como entradas "@clave", texto como "#text", elementos secundarios como claves anidadas.
- Recolección: los elementos hermanos repetidos se agrupan en una sola lista, por lo que <book> que aparece diez veces se convierte en una secuencia de diez elementos.
- Emisión: el árbol se serializa como YAML con un sangrado de dos espacios, con comillas solo donde un valor de otro modo se malinterpretaría.
Cómo las características de XML se representan en YAML
Cada característica del documento de origen tiene un asiento reservado en la salida, y los asientos se eligen para que dos características nunca peleen por una clave. La tabla muestra la asignación sobre las formas que realmente aparecen en documentos reales — un elemento con un atributo, un elemento con hijos, un elemento que se repite.
| Construcción XML | YAML producido |
|---|---|
| <book id="bk101"> | una asignación de libro con "@id": bk101 |
| <price>44.95</price> | price con "#text": "44.95" |
| diez elementos hermanos <book> | una clave book cuyo valor es una lista de diez elementos |
| <debug/> (vacío) | debug: {} — presente, explícitamente vacío |
Por qué existe #text y cuándo aparece
Un elemento cuyo contenido es solo texto — <price>44.95</price> — podría convertirse en la asignación simple price: 44.95, y para elementos sin atributos ni hijos, eso es efectivamente lo que obtienes para leer. Pero en el momento en que un elemento también lleva un atributo o un hijo, su texto necesita una clave que ningún nombre de atributo ni nombre de elemento hijo pueda ocupar nunca. #text es esa clave. Aparece solo cuando el texto debe compartir su elemento con otra cosa, lo que mantiene la salida ordinaria limpia mientras hace que la salida complicada sea inequívoca.
- Los elementos de solo texto mantienen su contenido legible en una sola línea.
- Elementos mixtos — atributos más texto, o hijos más texto — mueven el texto bajo "#text".
- Las entidades en el texto de origen se transportan textualmente; el analizador no es un analizador validante y no las reescribe.
Valores, tipos y la garantía de ida y vuelta
El texto XML es cadenas, y el emisor lo trata de esa manera: nada se fuerza a un número o un booleano en el camino. La consecuencia visible es el uso de comillas — 44.95 se escribe como "44.95" porque un 44.95 sin comillas se volvería a leer como un número en YAML, y un código postal como 02134 perdería su cero inicial de la misma manera. Los valores que no pueden confundirse con nada más, como bk101, se emiten en forma simple. Convierte el resultado de vuelta con el convertidor de YAML a XML del sitio y el documento que obtienes es el documento con el que comenzaste, byte por byte donde importa: nombres, atributos, texto y estructura.
- Sin inferencia de tipos: el texto cruza como texto, por lo que la precisión y los ceros iniciales se conservan.
- Las cadenas que parecen números se ponen entre comillas en la salida, lo que es lo que hace que el viaje de ida y vuelta sea sin pérdida.
- El espacio en blanco dentro de un nodo de texto se conserva; el espacio en blanco entre elementos nunca se convierte en datos.
Preguntas frecuentes
¿Al convertir XML a YAML se sube mi documento a algún sitio?
No. El análisis y la generación de YAML se ejecutan dentro de esta pestaña del navegador con código que se cargó una sola vez al abrir la página. No hay un punto final de subida, y la página se sirve con una Content-Security-Policy cuyo connect-src es 'self', por lo que el navegador rechazaría cualquier solicitud saliente independientemente del código. Observa el panel de red en DevTools mientras conviertes — permanece en silencio, y esa es la versión verificable de esta promesa.
¿Qué significan los prefijos @ y #text en la salida?
Ellos registran de dónde vino cada valor en el XML. Una clave como "@id" contiene un atributo — id="bk101" en el origen — y "#text" contiene el texto propio de un elemento cuando ese elemento también tiene atributos o hijos. Los prefijos garantizan que no haya colisiones: un atributo llamado price y un elemento hijo llamado price no pueden mapearse ambos a la misma clave, y el lector de YAML siempre puede saber qué tipo de valor está viendo.
¿Cómo se manejan los elementos repetidos?
Los elementos hermanos que comparten un nombre se recogen en una sola secuencia YAML: diez elementos <book> se convierten en una sola clave book cuyo valor es una lista de diez elementos, en orden de documento. Los elementos que aparecen una vez permanecen como asignaciones simples. Esta es la convención estándar de XML a datos, y es lo que hace que la salida sea natural de iterar en código — cada elemento de la lista es un registro, con atributos y elementos hijos plegados dentro de él.
¿Por qué 44.95 se escribe entre comillas en la salida YAML?
Porque el texto XML no tiene tipo, el valor es la cadena 44.95 — y un 44.95 sin comillas en YAML sería re-leído como un número por cada analista descendiente. Poner entre comillas las cadenas que parecen números es la forma del emisor de preservar lo que el origen realmente dijo, y es la misma regla que mantiene un código postal como 02134 de perder su cero inicial. Los valores que no pueden malinterpretarse, como bk101, se emiten sin comillas.
¿Qué partes del documento XML se ignoran?
Se omiten los comentarios, la declaración DOCTYPE y las instrucciones de procesamiento, ya que ninguno de ellos transporta datos de elemento. Se mantiene todo lo estructural: elementos, atributos, texto y secciones CDATA. El convertidor requiere un elemento raíz único — un pegado con dos elementos de nivel superior se rechaza con el nombre del segundo elemento y el número de línea, porque dos raíces son dos documentos y fusionarlos en silencio fabricaría una estructura que nunca estuvo ahí.
¿Qué pasa con los elementos vacíos como <debug/>?
Un elemento vacío se convierte en una asignación vacía explícita — debug: {} — en lugar de desaparecer, por lo que la clave sobrevive y un consumidor todavía puede decir que el campo estaba en el documento. Un elemento escrito con etiquetas de apertura y cierre separadas pero sin contenido, <note></note>, llega al mismo lugar: la estructura dice que el elemento existió, y solo el contenido estaba vacío. No se inventa nada para llenarlo.
¿Qué herramientas relacionadas debería usar después?
- YAML a XMLConvertidor que funciona en tu navegadorAbrir
- Fundamentos de YAMLGuía en lenguaje sencilloAbrir
- JSON vs XMLComparativa directaAbrir
- Convertir XML a JSONConvierte sin perder atributos ni listas de un solo elementoAbrir
- Convertir JSON a YAMLConvierte con las comillas necesarias para volver sin pérdidasAbrir
- Formatear JSONIndenta, ordena claves y quita comentariosAbrir