Introdução

Criei esta ferramenta por um motivo simples. Fazer isso manualmente toda vez era cansativo demais.

CSVs de sistemas internos, arquivos vindos do Excel e configurações exportadas de Linux, Windows ou banco de dados. Quando a origem muda, mudam também codificação, quebra de linha e BOM.

  • Parece UTF-8, mas era Shift_JIS
  • Parece LF, mas era CRLF
  • Alguns sistemas exigem BOM, outros quebram com BOM

Fazer detecção e conversão no olho não escala. Por isso criei uma ferramenta que aceita qualquer origem e padroniza a saída conforme o destino.

O problema real não é um arquivo corrompido

Se apenas um arquivo quebra, geralmente dá para recuperar. O problema é quando chegam 10 ou 100 arquivos ao mesmo tempo, de origens diferentes.

Pior: cada sistema de importação tem sua própria definição de “correto”.

  • Sistema A: só aceita UTF-8 sem BOM
  • Sistema B: fica estável com UTF-8 com BOM
  • Sistema C: presume Shift_JIS; UTF-8 parece legível, mas falha no import

Nesse cenário, a recomendação “padronize tudo em UTF-8” não resolve. É preciso um processo seguro e repetível orientado ao destino.

O que eu queria com esta ferramenta

A ideia tem apenas três princípios:

  1. Aceitar arquivos de qualquer origem
  2. Converter conforme requisitos do destino
  3. Não aumentar incidentes em processamento em lote

Não é vitrine técnica; é uma ferramenta para reduzir atrito operacional.

Procedimento que uso de verdade

1. Defina primeiro a especificação de saída

Comece pela saída, não pela entrada. Fixe estes três itens:

  • Codificação (UTF-8 / Shift_JIS etc.)
  • Quebra de linha (LF / CRLF)
  • BOM (com / sem)

Se isso ficar ambíguo, o resultado muda conforme a pessoa operadora.

2. Divida os alvos em lotes pequenos

Não rode tudo de uma vez. Separe por sistema, período ou tipo de arquivo e comece com lotes pequenos.

Motivo: se falhar, dá para reverter. Rodada única em volume total só é rápida quando dá certo.

3. Congele condições e rode conversão em lote

Use o conversor de codificação com condições fixas por destino. Não altere configuração no meio da execução. O essencial é repetir sempre as mesmas condições.

4. Não use só inspeção visual como critério de sucesso

“Abriu, então está ok” é porta de incidente. No mínimo, confira:

  • Se o número de linhas é igual antes e depois
  • Se a quantidade de colunas CSV/TSV foi mantida
  • Se � (caractere de substituição) não aumentou
  • Se colunas-chave (ID/código) mantêm tamanho e tipo de caractere

Se não passar, não prossiga para importação.

BOM não é religião; decida pelo requisito do outro lado

Debate “com BOM vs sem BOM” quase não ajuda na prática. Só importa como o sistema de destino lê o arquivo.

  • Se o destino é estável com BOM, gere com BOM
  • Se quebra com BOM, gere sem BOM

Priorize “formato que não quebra o outro lado” acima de “formato teoricamente correto”. Operação real é isso.

O valor desta ferramenta não é a conversão em si

O valor real está em dois pontos:

  • Decisão não varia por pessoa
  • Custo de verificação recorrente diminui

Não dá para zerar totalmente incidentes de codificação. Mas dá para parar de repetir os mesmos acidentes. Foi para isso que preparei uma ferramenta que aceita tudo e devolve alinhado ao uso.

Conclusão

Esta ferramenta não nasceu de teoria ideal. Ela nasceu para eliminar o ajuste tedioso e repetitivo de codificação no dia a dia.

Receber arquivos de origens diferentes, alinhar codificação/quebra de linha/BOM ao destino e devolver saída consistente. Só automatizar esse fluxo já facilita muito a operação.

Tratar mojibake não deve ser questão de “força de vontade”. Tem de virar procedimento reproduzível, com o mesmo resultado para qualquer pessoa. Só então podemos dizer que a recuperação em lote é realmente segura.