Introducción

Creé esta herramienta por una razón simple. Hacerlo manualmente cada vez era agotador.

CSV de sistemas internos, archivos convertidos desde Excel, y configuraciones exportadas desde Linux, Windows o bases de datos. Cuando cambia el origen, también cambian la codificación, los saltos de línea y el BOM.

  • Parece UTF-8, pero era Shift_JIS
  • Parece LF, pero era CRLF
  • Hay sistemas que funcionan con BOM y otros que se rompen con BOM

Verificar y convertir todo esto a ojo no escala. Por eso hice una herramienta que acepta cualquier origen y normaliza la salida según el destino.

El problema real no es un único archivo roto

Si se rompe un solo archivo, normalmente se puede arreglar. Lo difícil es cuando llegan 10 o 100 archivos a la vez, todos de orígenes distintos.

Además, cada sistema de importación tiene su propia “verdad”.

  • Sistema A: solo UTF-8 sin BOM
  • Sistema B: más estable con UTF-8 con BOM
  • Sistema C: asume Shift_JIS; UTF-8 se ve bien pero falla al importar

Aquí, decir “unifica todo en UTF-8” no sirve. Se necesita una operación segura y repetible según el uso.

Qué quería lograr con esta herramienta

Solo tres principios:

  1. Aceptar cualquier origen
  2. Convertir según los requisitos del destino
  3. No aumentar incidentes en procesamiento por lotes

No es una demostración técnica; es una herramienta para reducir fricción operativa.

Procedimiento que uso en la práctica

1. Definir primero la especificación de salida

No empezar por la entrada, sino por la salida. Fijar estos tres puntos:

  • Codificación (UTF-8 / Shift_JIS, etc.)
  • Salto de línea (LF / CRLF)
  • BOM (con / sin)

Si esto queda ambiguo, el resultado cambia según quién opere.

2. Dividir el objetivo en lotes pequeños

No procesar todo de golpe. Separar por sistema, período o tipo de archivo y empezar con lotes pequeños.

¿Motivo? Si falla, se puede revertir. Un tiro único a volumen completo solo es rápido cuando sale bien.

3. Fijar condiciones y convertir en lote

Usar la herramienta de conversión con parámetros fijos por destino. No cambiar ajustes a mitad de proceso. La clave es la reproducibilidad.

4. No validar solo por inspección visual

“Se abre, así que está bien” es la puerta del incidente. Como mínimo, comprobar:

  • Igualdad de número de filas antes y después
  • Que no cambie el número de columnas CSV/TSV
  • Que no aumente � (carácter de reemplazo)
  • Que columnas clave (ID/código) mantengan longitud y tipo de caracteres

Si no pasa estas comprobaciones, no importar.

BOM no es religión; se decide por especificación del receptor

Debatir BOM sí/no rara vez aporta en operación. Solo importa cómo recibe el sistema destino.

  • Si el receptor es estable con BOM, salida con BOM
  • Si el receptor falla con BOM, salida sin BOM

Prioriza “formato que no rompe al otro lado” sobre “formato teóricamente correcto”. Así funciona la operación real.

El valor no está en convertir, sino en operar mejor

El valor real está en dos puntos:

  • Las decisiones no dependen de la persona
  • Baja el costo de verificación repetida

No se puede llevar a cero absoluto los incidentes de codificación. Pero sí se puede dejar de repetir los mismos errores. Por eso preparé una herramienta que recibe todo y devuelve archivos alineados al uso.

Conclusión

Esta herramienta no nació de una teoría ideal. Nació para eliminar ajustes de codificación tediosos y repetitivos del trabajo diario.

Recibe archivos de distintos orígenes, alinea codificación/salto de línea/BOM según el destino y devuelve resultados consistentes. Solo automatizar ese flujo ya aligera mucho la operación.

Resolver mojibake no debería depender de fuerza de voluntad. Hay que convertirlo en un procedimiento reproducible, con el mismo resultado para cualquiera. Solo entonces podemos hablar de rescate seguro en lote.