CSV a XML
Este conversor transforma filas CSV en elementos XML en tu navegador: un elemento raíz <records>, un elemento <record> por fila, y una etiqueta secundaria por encabezado. Los nombres de etiqueta se sanean para que sean XML legales, el texto se escapa, y los encabezados con puntos se anidan en elementos secundarios. No se sube nada.
CSV a XML: explicación
XML es más estricto que CSV con los nombres, y esa es toda la dificultad técnica aquí. Un encabezado como unit price no puede convertirse en una etiqueta porque los nombres de elemento no pueden contener espacios; 2fa no puede ser una etiqueta porque los nombres no pueden empezar con un dígito. Este conversor aplica la solución estándar: los caracteres no válidos se convierten en guiones bajos, y un nombre que empezaría con un dígito recibe un guion bajo inicial, de modo que cada encabezado produce una etiqueta que un parser XML real acepta, y el mapeo de columna a elemento permanece visible en lugar de ser mágico.
El lado CSV se parsea según RFC 4180: una máquina de estado que respeta las comillas dobles, las comas y los saltos de línea dentro de campos entrecomillados, detección del delimitador entre coma, punto y coma, tabulador y barra vertical, y la misma política de tipo estrecha que el sitio usa en todas partes: los valores se convierten en números solo bajo la gramática de número de JSON, por lo que 02134 conserva su cero inicial. Los encabezados con puntos conservan su estructura: address.city se convierte en un elemento address con un elemento hijo city, no en una etiqueta plana con un punto integrado en su nombre.
Todo se ejecuta en esta pestaña del navegador. El CSV es parseado por un motor en la página y el XML se construye a partir de los registros parseados; nada toca la red — abre DevTools, observa que el panel de red permanece en silencio, y la afirmación sobre privacidad se comprarta a sí misma.
Comprobar el viaje de vuelta es solo un pegado de distancia, porque el conversor de XML a CSV lee estas mismas convenciones al revés, convirtiendo filas de vuelta a elementos.
Si la elección del formato de salida sigue abierta, el comparativa JSON vs XML explica dónde el marcado gana su importancia y dónde es sobrecarga.
Cómo funciona la conversión en realidad
El pipeline es parsear, expandir, sanear, escapar — en ese orden, y cada etapa solo ve la salida de la anterior. Ese orden es por lo que una coma dentro de una celda entrecomillada nunca perturba la estructura de elementos: la cuadrícula se asienta antes de que exista XML, y el escritor de XML nunca toma decisiones sobre sintaxis CSV.
- Parsear: reglas RFC 4180 con concesiones del mundo real — una comilla en medio de un campo libre se toma literalmente, y las filas finales vacías se descartan.
- Expandir: los encabezados se decodifican como rutas, por lo que address.city anida city dentro de address, y tags[0], tags[1] se convierten en elementos repetidos.
- Saneamiento: cada nombre de elemento se comprueba contra las reglas de nombre XML 1.0 — letras, dígitos, guiones bajos, guiones, puntos y dos puntos — y se repara donde falle.
- Escapar: el contenido de texto recibe &, < y > donde la fuente tenía &, < o >, y los valores de atributo además escapan la comilla doble.
La política de nombres de etiqueta, con precisión
XML 1.0 permite que un nombre empiece con una letra, un guion bajo o dos puntos, y que continúe con dígitos, guiones y puntos; todo lo demás está fuera. El saneador reemplaza cada carácter fuera de ese conjunto con un guion bajo y añade un guion bajo cuando el primer carácter superviviente sería un dígito — así unit price se convierte en unit_price, 2fa en _2fa, y una columna llamada discount% en discount_. Los nombres válidos pasan intactos, incluido CamelCase y kebab-case, porque reescribir un nombre que ya era legal rompería a los consumidores que esperan él.
| Encabezado CSV | Elemento emitido | Por qué |
|---|---|---|
| name | <name> | ya es un nombre XML legal — se pasó tal cual |
| unit price | <unit_price> | el espacio se reemplazó por un guion bajo |
| 2fa | <_2fa> | los nombres no pueden empezar con un dígito |
| address.city | <address><city> | los encabezados con puntos se anidan, no aplanan |
Qué ocurre con los valores
XML no tiene un tipo numérico o booleano separado — cada valor es texto — por lo que las celdas cruzan tal cual sus caracteres exactos, sin coerción que pierda o invente precisión. Una celda vacía se trata como un campo ausente en lugar de un valor vacío, por lo que el elemento se omite en lugar de emitir una cadena de etiquetas auto-cerradas que nadie consume. El escapado se aplica al salir: una celda que contiene A & B se convierte en A & B en el documento, y cualquier parser XML que lea el resultado vuelve a ver el texto original.
- 02134 se queda como 02134; nunca se recorta el cero inicial, porque el valor es texto desde que deja la cuadrícula.
- Una celda de múltiples líneas conserva sus saltos de línea dentro del elemento, y esos saltos son datos, no formato.
- El elemento <record> es el mismo para cada fila, sea cual sea — las columnas que una fila carece simplemente no producen ningún elemento.
Casos extremos y cómo se reportan
Las negativas del conversor son la parte esencial de su contrato. Un campo entrecomillado no terminado detiene el parseo en esa línea con un error con nombre, porque adivinar dónde terminó el campo重塑aría silenciosamente cada fila siguiente. Una fila con un recuento de campos diferente al encabezado aún se convierte, pero una advertencia indica que los campos faltantes están ausentes y los extras se descartaron. Los encabezados duplicados se convierten con el valor más a la derecha ganando, y la advertencia lo dice — el comportamiento de importación de hojas de cálculo, hecho explícito.
- Comilla no terminada: parseo abortado, línea reportada, no se escribió salida.
- Filas irregulares: convertidas con una advertencia que nombra las filas afectadas.
- Encabezados duplicados: convertidos con una advertencia; la ocurrencia más a la derecha gana.
Preguntas frecuentes
¿Al convertir CSV a XML se sube mi archivo a algún sitio?
No. El parseo del CSV y la construcción del XML 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 endpoint de subida al que llamar, 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 aunque se intentara. Observa el panel de Red en DevTools mientras conviertes — permanece vacío.
¿Por qué mi salida está envuelta en etiquetas <records> y <record>?
XML necesita exactamente un elemento raíz, y un archivo CSV no tiene un nombre natural que darle, por lo que el conversor usa una forma fija: un raíz <records> con un elemento <record> por fila. Los encabezados se convierten en las etiquetas hijas dentro de cada registro. El envoltorio es lo que hace que la salida sea un documento bien formado en lugar de un fragmento, y cada fila es fácil de direccionar con un XPath como /records/record.
¿Cómo se manejan los nombres de etiqueta no válidos?
Cada encabezado se sanea según las reglas de nombre XML 1.0: los caracteres fuera de letras, dígitos, guion bajo, guion, punto y dos puntos se convierten en guiones bajos, y un nombre que empezaría con un dígito recibe un guion bajo inicial. Así unit price se convierte en unit_price y 2fa en _2fa. Los nombres que ya eran válidos pasan intactos, lo que importa cuando un sistema descendiente coincide con nombres de etiqueta exactos.
¿Cómo se escapan los caracteres especiales en los valores de celda?
El contenido de texto escapa los tres caracteres que XML requiere: & se convierte en &, < en < y > en >. Dentro de valores de atributo la comilla doble también se escapa como ". El escapado ocurre solo en la salida, por lo que una celda que contiene A & B vuelve a ser exactamente A & B cuando un parser XML lee el documento — nada se escapa dos veces y nada se pre-desescapa.
¿Mis números y códigos postales conservarán su formato?
Sí, porque los valores se convierten en texto XML tal cual — no hay un paso de coerción numérica que podría reformatearlos. 02134 conserva su cero inicial, 44.95 conserva su forma decimal exacta, y un valor como 1e5 se queda con los caracteres que escribiste en lugar de expandirse. La información de tipo es una preocupación de CSV o JSON; los elementos XML transportan texto, y el conversor no la vuelve a adivinar.
¿Y si mi CSV tiene filas irregulares o encabezados duplicados?
Ambos se convierten, cada uno con una advertencia explícita. Una fila más corta que el encabezado se completa con campos ausentes — no se inventan elementos vacíos — y una fila más larga que el encabezado tiene sus extras descartados, con la advertencia indicando cuántas filas se vieron afectadas. Los nombres de columna duplicados se resuelten con el más a la derecha ganando, igual que un importador de hojas de cálculo, y la advertencia enumera los nombres involucrados.
¿Qué herramientas relacionadas debería usar después?
- XML a CSVConvertidor que funciona en tu navegadorAbrir
- Reglas de CSV RFC 4180Guía en lenguaje sencilloAbrir
- JSON vs XMLComparativa directaAbrir
- Convertir CSV a JSONConvierte una exportación de hoja de cálculo en registrosAbrir
- Convertir JSON a XMLConvierte con atributos y nombres que XML aceptaAbrir
- Validar JSONValida la sintaxis con línea y columna exactas y repara los erroresAbrir