Cómo limpiar problemas de Windows-1251 y BOM de un CSV antes de importarlo

Un archivo puede parecer correcto y aun así tener la codificación equivocada

Un archivo CSV exportado desde software antiguo de contabilidad o de bases de datos muchas veces no está en UTF-8. Windows-1251 para texto en cirílico y Windows-1252 para caracteres acentuados de Europa occidental siguen siendo salidas habituales en sistemas creados hace años. Un programa de hoja de cálculo suele mostrar un archivo así sin quejarse, porque aplica automáticamente su propia suposición de codificación. Así que el archivo se ve normal hasta que lo lee algo menos tolerante, como un script, una canalización de importación o un cargador de base de datos, que da por hecho que es UTF-8 y recibe un muro de caracteres ininteligibles en lugar del texto que había.

Un marcador de tres bytes al principio puede romper un analizador estricto

Un byte order mark UTF-8 es un marcador invisible, solo tres bytes, que están justo al principio del archivo para indicar que el texto que sigue es Unicode. Le resulta útil a un programa como Excel, que lo busca. Se convierte en un problema en cuanto el destino es un importador JSON estricto o un script que no lo espera. Esos bytes extra se pegan al primer carácter del primer encabezado de columna, así que una columna que debería leerse como «id» deja de coincidir con ese nombre en cualquier parte donde el resto del código lo espera. Detectar y quitar ese marcador antes de la conversión, en lugar de dejarlo en el archivo resultante, evita un desajuste que puede ser difícil de rastrear después.

Detectar la codificación correcta sin ofrecer un menú de opciones

Una detección fiable de codificación, como la que hace CSV a JSON antes de leer una sola fila, busca primero un byte order mark, luego intenta validar de forma estricta el resto de bytes como UTF-8, y solo recurre a Windows-1251 o Windows-1252, según cómo se distribuyen los bytes de valor más alto, si esa validación estricta falla. Ese orden importa. Un archivo que ya está en UTF-8 no se reinterpreta como otra cosa por error, mientras que un archivo que no es UTF-8 se identifica correctamente en lugar de forzarlo como UTF-8 y convertirlo en texto ilegible por el camino. La misma detección va delante de CSV a Excel, para los casos en que el destino es una hoja de cálculo y no un script.

Los tipos de datos importan tanto como la codificación de caracteres

Ajustar bien la codificación de caracteres solo resuelve la mitad de lo que se rompe al convertir de CSV a JSON. La otra mitad es decidir qué valores deben convertirse en números o booleanos JSON y cuáles deben quedarse como texto plano. Un valor como 00123 que pasa a ser el número 123 pierde su cero inicial para siempre en el momento de la conversión, y un identificador de más de unos quince dígitos se redondea en cuanto se convierte en un número de coma flotante estándar en lugar de mantenerse como texto. Ambos deberían dejarse como cadenas, porque convertirlos cambia los datos en sí, no solo el formato o el aspecto.

Un encabezado duplicado suelto puede romper una importación de otra forma

Los objetos JSON no pueden tener dos propiedades con la misma clave. Así que un archivo de origen con dos columnas que comparten el mismo encabezado, algo nada raro en exportaciones armadas a partir de más de un sistema, necesita que esos duplicados se renombren a algo distinto durante la conversión. Si no, los datos de la segunda columna sobrescriben los de la primera en cada objeto resultante, sin ningún aviso. Es un modo de fallo distinto de los problemas de codificación o de tipos, pero puede corromper una importación de forma igual de silenciosa. Conviene comprobar que la herramienta de conversión avisa cuando esto ocurre en lugar de resolver el conflicto sin mostrarlo, y pasar el resultado por Formatear JSON deja ver las claves renombradas de un vistazo.

Paso a paso: revisar el archivo antes de que entre en la importación

Convierte la exportación una vez en CSV a JSON con el separador y la codificación en automático y comprueba las dos suposiciones: pasa el resultado a Formatear JSON, uno de los pasos siguientes que ofrece la página, y lee los primeros registros. Un cirílico ilegible o unos acentos rotos indican que falló la codificación; una única clave larga con los separadores todavía dentro indica que falló el separador. Fija a mano el que falló y convierte de nuevo: el menú de codificación ofrece Windows-1251, Windows-1252, UTF-8 con o sin BOM y UTF-16 LE, y el de separador, coma, punto y coma, tabulación, barra vertical o un carácter propio. Un archivo cuyo separador o codificación no se puede interpretar de ningún modo se rechaza con un mensaje en lugar de convertirse en un sinsentido.

Después decide cómo se tipan los valores: el ajuste por defecto ya deja como texto los valores con cero inicial y los identificadores largos, y para un archivo hecho de códigos, teléfonos o números de cuenta, poner los tipos de valor en mantener todo como texto no convierte nada. Con el resultado abierto en Formatear JSON, busca dos huellas de un origen desordenado: dos columnas con el encabezado id salen como id e id_2, y una fila con más campos que el encabezado lleva los sobrantes bajo una clave __extra. Las dos salen más baratas de corregir en el archivo de origen que en el sistema que acabaría atragantándose con ellas. Hasta veinte archivos, 300 MB en total, pasan en un solo lote sin salir de la pestaña del navegador.