El parser de CSV que solo sale bien si le enseñas las filas de verdad

Martes por la mañana, llega el fichero de siempre: exportación de facturas del ERP de un cliente, unas cuatro mil líneas, hay que volcarlo a una tabla nuestra. No es un problema difícil. Es un problema sucio, que es peor.

Este venía con el paquete completo. Separador punto y coma, porque en España la coma es el decimal. Importes tipo 1.234,56 € y algún abono en negativo entre paréntesis. Un BOM al principio que convertía el nombre de la primera columna en algo que no casaba con nada. Fechas con el año en dos dígitos. La columna de observaciones con comas y saltos de línea dentro de las comillas. Y las eñes rotas, porque el fichero no era UTF-8, era Windows-1252.

Lo que cambia la partida

Abrí Elffuss Code y le pegué veinte líneas al chat. No veinte líneas de ejemplo inventadas: las veinte líneas feas de verdad. La del cliente con apóstrofo en el apellido, la observación de tres renglones, el abono negativo, la fila a la que le falta la última columna porque el ERP la corta si va vacía.

Con eso delante, lo que sale ya no es el parser genérico que todos hemos copiado alguna vez. Es el parser de este fichero:

• Nada de split(';'): una máquina de estados de dos estados, dentro o fuera de comillas, con la comilla doble escapada como "".
• Detección del separador contando candidatos en las primeras líneas, en vez de darlo por supuesto.
• Decodificar con TextDecoder probando UTF-8 y cayendo a Windows-1252 si aparecen caracteres de reemplazo.
• Comer el BOM antes de leer la cabecera.
• Normalizar importes: fuera separador de millar, coma a punto, paréntesis a signo menos.
• Filas con menos columnas de la cuenta: rellenar, no reventar.

Y después la parte que más se agradece: pedirle que convierta esas mismas filas raras en una tabla de casos de test. Los casos borde ya no te los tienes que imaginar, los tienes en el fichero.

El detalle incómodo

Esas veinte líneas llevan nombres, NIF, direcciones e importes de una empresa que no es la tuya. Pegarlas en un chat que sale a un servidor no es una decisión técnica: es una decisión que, si la piensas dos segundos, no te corresponde tomar a ti.

El fichero que mejor describe el problema es justo el que no deberías enseñar por ahí.

Lo normal entonces es anonimizar a mano, o inventarte un CSV limpio de mentira. Y el parser sale igual de limpio y de mentira: peta el jueves con la fila 2.847. Que el modelo corra dentro de tu propio navegador quita ese paso intermedio. El prompt, el fichero y el código se quedan donde ya estaban. Sin cuenta, sin cuota, y con el portátil en modo avión si te apetece.

No es una postura ideológica. Es, sencillamente, que así puedes trabajar con el caso real.