Artículo
Convertir entre CSV, XML, JSON y YAML: guía práctica
CSV, JSON, XML y YAML son los cuatro formatos que los desarrolladores encuentran con más frecuencia en pipelines de datos, archivos de configuración y APIs. Convertir entre ellos es sencillo cuando los modelos de datos coinciden, y sorprendentemente costoso en información cuando no lo hacen. Esta guía explica qué puede y qué no puede representar cada formato, dónde desaparece información durante la conversión y las trampas de codificación que provocan corrupción silenciosa. La herramienta data-converter de este sitio gestiona tres de los cuatro (CSV, JSON y YAML) completamente en el navegador; las secciones sobre XML de esta guía son referencia para cuando muevas datos a mano o con otra herramienta.
Los cuatro formatos y sus modelos de datos
CSV organiza los datos como una cuadrícula plana de filas y columnas. La primera fila suele nombrar las columnas; cada fila siguiente es un registro. No hay anidación, ni información de tipo, ni estándar para nada más allá de texto plano en las celdas. Cada valor es una cadena a menos que la aplicación consumidora imponga un tipo. JSON modela los datos como un árbol de objetos (mapas clave-valor) y matrices. Los valores pueden ser cadenas, números, booleanos, null, objetos anidados o matrices de cualquier profundidad. Esto permite que un único documento JSON represente un registro de cliente con objetos de dirección incrustados, matrices de líneas de pedido y totales numéricos tipados. XML modela los datos como un árbol de elementos. Cada elemento puede tener atributos con nombre y contener elementos hijo o contenido de texto. No hay tipos numéricos ni booleanos integrados; todo es texto. Los esquemas como XSD pueden imponer tipos en el momento de la validación, pero el formato de transmisión es siempre datos de carácter. YAML usa la sangría para expresar el mismo modelo de objetos y matrices que JSON, con una sintaxis más limpia y legible. YAML es un superconjunto de JSON: cualquier documento JSON válido es también YAML válido. Añade cadenas multilínea, comentarios y referencias de ancla y alias para bloques repetidos. YAML es común en archivos de configuración; JSON es común en respuestas de API.
Conversiones con pérdida: aplanamiento y la ambigüedad de XML
La conversión con pérdida más común es aplanar JSON o XML anidado a CSV. Un objeto JSON con un campo de dirección anidado no puede mapearse limpiamente a una fila CSV. La solución habitual son nombres de columna con notación de punto: customer.address.city se convierte en su propia columna. Esto funciona para un nivel de anidación, pero falla por completo cuando aparece una matriz. Un cliente con tres números de teléfono requiere tres columnas separadas (codificando el máximo), dividirse en un segundo archivo CSV, o codificar la matriz como una cadena delimitada dentro de una celda. Ninguna de estas opciones permite reconstruir el JSON original sin metadatos adicionales. XML introduce una ambigüedad adicional: la elección entre atributo y elemento hijo. El valor Paris podría almacenarse como atributo (<city name="Paris">) o como elemento hijo (<city><name>Paris</name></city>). Cuando un convertidor lee XML y produce JSON, debe decidir cómo mapear los atributos. Las convenciones habituales incluyen anteponer @ a las claves de atributo o colocarlas bajo una clave "_attributes". La elección no está estandarizada, lo que significa que dos convertidores que leen el mismo XML pueden producir JSON estructuralmente diferente. Si planeas hacer ida y vuelta de datos entre XML y JSON, fija una convención antes de empezar.
Trampas de CSV: delimitadores, entrecomillado y codificación
CSV no tiene un único estándar formal, solo RFC 4180 como referencia ampliamente citada. El delimitador más común es la coma, pero los puntos y comas (habituales en locales europeos donde las comas sirven de separadores decimales), los tabuladores (TSV) y las barras verticales también aparecen en la práctica. Un archivo llamado .csv puede usar cualquiera de estos sin indicar cuál. Cuando el valor de un campo contiene el propio delimitador, RFC 4180 exige envolver el campo entre comillas dobles: "San Francisco, CA". Una comilla doble dentro de un campo entrecomillado debe escaparse duplicándola: "He said ""hello""". Un campo que contiene un salto de línea literal también debe entrecomillarse. Los analizadores que omiten este paso producen errores en el número de filas difíciles de rastrear. La codificación es una trampa aparte. Los archivos CSV generados por herramientas Windows suelen llevar un BOM UTF-8 (marca de orden de bytes: los tres bytes EF BB BF al inicio del archivo). El BOM ayuda a Excel a identificar la codificación, pero muchos analizadores de lenguajes de programación tratan el BOM como parte del nombre de la primera columna, produciendo una columna llamada "id" en vez de "id". Esto rompe cualquier código descendiente que busque columnas por nombre. Al leer un archivo CSV mediante programación, elimina el BOM antes de analizar, o usa una biblioteca que lo gestione explícitamente.
Elegir un formato: configuración, intercambio y hojas de cálculo
La elección del formato suele estar determinada por el contexto, no por la preferencia. JSON es el estándar para las APIs REST y el intercambio entre navegador y servidor. Es compacto, se analiza de forma nativa en todos los lenguajes de programación y lleva información de tipo para números y booleanos. Su debilidad es la ausencia de comentarios, lo que lo hace inadecuado para archivos que los desarrolladores leen y editan a mano. YAML se prefiere para archivos de configuración (manifiestos de Kubernetes, definiciones de pipelines CI, playbooks de Ansible) porque permite comentarios en línea y es más fácil de leer que JSON con muchos niveles de sangría. Su principal riesgo es que los errores de sangría son silenciosos: una clave mal sangrada se mueve a un ámbito diferente sin ningún error de análisis. XML sigue siendo el estándar en sistemas empresariales más antiguos, servicios web SOAP, formatos de documento (DOCX, SVG, RSS) y contextos que requieren validación de esquemas o desambiguación de espacios de nombres. Es verboso, pero las herramientas XPath y XSLT son maduras. CSV es la opción correcta cuando los datos son genuinamente planos y el consumidor es una aplicación de hoja de cálculo o un analista de datos. No es adecuado para configuración o intercambio de API porque no tiene sistema de tipos ni anidación.
Hacerlo localmente con data-converter
La herramienta data-converter de este sitio analiza y convierte entre CSV, JSON y YAML completamente dentro del navegador; no lee ni escribe XML. En ningún momento se transmiten datos a un servidor. La conversión se ejecuta en tu entorno de ejecución JavaScript local, y el resultado está disponible para descargar o copiar sin que nada salga de tu dispositivo. Esto importa para los datos que no te corresponde compartir: respuestas de API que contienen información personal, archivos de configuración con nombres de host internos, o exportaciones CSV de bases de datos internas. Pegar esos datos en un convertidor basado en web que se ejecuta en un servidor significa que el contenido se envía por la red y se procesa en hardware que no controlas. Con data-converter, la pestaña del navegador es el entorno de procesamiento. La herramienta aplica el entrecomillado RFC 4180 al leer o escribir CSV, y espera un array plano de objetos cuando convierte JSON o YAML a CSV: un valor de objeto o array anidado bajo una clave no recibe aplanamiento automático con notación de punto, así que aplana esos campos tú mismo antes de convertir si los necesitas como columnas separadas. Si necesitas mover datos hacia o desde XML, conviértelos primero a JSON o YAML con una herramienta dedicada a XML y luego trae el resultado aquí.
Herramientas en este artículo
Preguntas frecuentes
¿Puedo hacer ida y vuelta de JSON a través de CSV y recuperar el original?
Solo si el JSON es una matriz plana de objetos sin campos anidados ni matrices como valores. En el momento en que hay un objeto anidado o un valor de tipo matriz, la representación CSV requiere una decisión estructural (columnas con notación de punto, múltiples filas o cadenas codificadas) que no puede revertirse automáticamente. Si tus datos tienen anidación, JSON, XML o YAML harán la ida y vuelta limpiamente; CSV no.
¿Por qué mi CSV se ve mal en Excel después de exportarlo desde una aplicación europea?
Los locales europeos suelen usar puntos y comas como delimitador CSV porque las comas están reservadas para la notación decimal. Excel en un local europeo espera puntos y comas. Si el archivo usa comas, Excel trata toda la fila como una única columna. La solución es cambiar el delimitador en la configuración de exportación, o usar el asistente de importación de datos de Excel, que permite especificar el delimitador manualmente. El problema del BOM UTF-8 es aparte: sin BOM, Excel también puede malinterpretar los caracteres acentuados como texto ilegible.
¿Cuál es la diferencia entre YAML y JSON en la práctica?
Ambos representan el mismo modelo de datos subyacente: objetos, matrices, cadenas, números, booleanos y null. YAML añade comentarios (líneas que empiezan por #), literales de cadena multilínea y referencias de ancla para bloques repetidos. JSON es estrictamente un subconjunto de YAML válido, pero los analizadores JSON no leen YAML. La regla práctica: usa JSON para cargas de API y almacenamiento de datos; usa YAML para archivos de configuración que los humanos editan y que se benefician de comentarios en línea.