El trabajo en cristiano
Tienes un archivo CSV de una hoja de cálculo, un export, una respuesta de API. Lo necesitas como JSON para una base de datos, una webapp, un prompt de LLM. La conversión suena simple. La mitad de las veces sale al primer intento. La otra mitad pierdes datos sin enterarte.
Este es el checklist que pilla los fallos silenciosos antes de que se conviertan en un bug de producción.
Paso 1: Confirma el delimitador
Abre el archivo en un editor de texto plano. Mira la primera línea. Lo que esté entre los valores es tu delimitador.
La mayoría de archivos usan coma. Las hojas exportadas desde Excel en español, francés o alemán usan punto y coma a menudo. Las herramientas Unix viejas a veces usan tabulador. La extensión es .csv igualmente.
Si tu convertidor parsea todo como una sola columna, el delimitador está mal. Dile a la herramienta cuál usar, no adivines.
Paso 2: Comprueba la codificación
El bug silencioso más común es abrir un archivo UTF-8 como Windows-1252 o al revés. Los acentos salen como caracteres basura (pingüino se vuelve pingüino).
Los convertidores modernos detectan UTF-8 automáticamente la mayoría de las veces. Cuando no pueden, caen a Latin-1 y el archivo parece medio bien. Si tus datos tienen acentos y se ven raros, la codificación está mal.
El convertidor CSV a JSON de AldeaCode maneja UTF-8, Latin-1 y Windows-1252 de forma transparente. Si tu archivo usa otra cosa (raro en 2026), ábrelo en un editor de verdad y guárdalo como UTF-8 primero.
Paso 3: Vigila el BOM
El Byte Order Mark son tres bytes invisibles que algunas herramientas de Microsoft añaden al inicio de un archivo UTF-8. Le dicen al lector “esto es UTF-8”. La mayoría de parsers manejan el BOM correctamente.
Algunos no, y el BOM acaba como parte del header de la primera columna. Tu JSON acaba con una clave llamada Nombre en lugar de Nombre, y cualquier código que busque Nombre no encuentra nada.
Si tu primera clave de columna se ve rara y no la encuentras por nombre en el JSON resultante, sospecha del BOM. El arreglo es quitarlo antes de parsear, o usar un convertidor que sepa de él.
Paso 4: Decide qué son tus cabeceras
El CSV suele poner los nombres de columna en la primera fila. A veces no. A veces la primera fila es metadata y la segunda es las cabeceras. A veces no hay cabeceras y tienes que inventarlas.
Antes de convertir, decide:
- ¿Tiene el archivo una fila de cabeceras? Sí / no.
- Si sí, ¿están limpias (
nombre_producto) o sucias con espacios y mayúsculas (Nombre Producto)? - ¿Quieres que las claves del JSON coincidan con las cabeceras exactamente, o las normalizas (minúsculas, snake case, sin espacios al final)?
Un buen convertidor te deja controlar las tres cosas. Uno malo siempre usa la primera fila como cabeceras, y te enteras a la hora dos de que tu hoja tenía una fila de título que empujó todo abajo.
Paso 5: Manejo de comillas
Si un valor contiene el delimitador, el estándar dice envolverlo en comillas. Así que Hola, mundo se vuelve "Hola, mundo".
La trampa es que las comillas dentro del valor se pueden codificar de dos formas. Excel las duplica: "Dijo ""hola""". La mayoría de herramientas Unix aceptan ambas: duplicadas y escapadas con barra invertida: "Dijo \"hola\"".
Si tu convertidor se atraganta con una fila concreta, la fila probablemente tiene un valor entrecomillado con comillas internas en un estilo que tu parser no espera. Prueba el estilo de comillas opuesto.
Paso 6: Decide qué forma de JSON quieres
La conversión por defecto es un array de objetos. Cada fila se convierte en un objeto con claves de las cabeceras.
[
{ "id": "1", "nombre": "María", "ciudad": "Madrid" },
{ "id": "2", "nombre": "Carlos", "ciudad": "Lima" }
]Otras formas son útiles en algunos casos:
- Un único objeto indexado por id, cuando necesitas búsquedas rápidas (
{ "1": { "nombre": "María"... }, ... }). - Un array de arrays, cuando no tienes cabeceras (
[ ["1", "María", "Madrid"], ... ]). - Un formato streaming (un objeto JSON por línea), cuando los datos no caben en memoria.
El convertidor CSV a JSON te deja elegir la forma directamente. El formateador JSON es útil después para validar el resultado.
Paso 7: Inferencia de tipos, la peligrosa
Algunos convertidores convierten automáticamente "1" en 1, "true" en true, "2026-05-01" en una fecha. Suena útil y a menudo es un desastre.
Los números de teléfono que empiezan por 0 pierden el cero inicial. Los códigos postales 00214 se vuelven 214. Los booleanos como "sí" y "no" solo a veces se castean a strings. Las fechas parsean distinto según la locale.
El default seguro es “todo se queda como string”. Luego casteas al tipo correcto en el código que consume, donde tienes consciencia del esquema. Si tienes que inferir, infiere por columna con reglas explícitas, no globalmente.
Una checklist de 30 segundos
Antes de tratar la conversión como hecha:
- ¿Mismo número de filas en CSV y JSON?
- ¿Mismo número de campos por fila, sin líneas truncadas?
- ¿Los caracteres acentuados se ven bien?
- ¿La clave de la primera columna tiene un nombre normal, no bytes raros al principio?
- ¿Los números son números y los strings son strings, en las columnas donde esperas cada cosa?
El convertidor CSV a JSON, el formateador JSON, el contador de texto y el buscar y reemplazar de AldeaCode corren en tu navegador. Los datos no salen de tu pestaña. Cinco minutos con este checklist le ganan a cinco horas depurando un import roto.