前言

我做这个工具的原因很简单。 每次都手动处理，真的很累。

内部系统联携 CSV、Excel 转 CSV、以及 Linux/Windows/数据库导出的配置文件，来源一变，编码、换行、BOM 就跟着变。

  • 以为是 UTF-8，结果是 Shift_JIS
  • 以为是 LF，结果是 CRLF
  • 有些系统必须带 BOM，有些系统带 BOM 就乱码

靠人工目测和经验每次去猜，已经不可持续。 所以我做了一个工具：不管来源如何都先接住，再按目标系统要求统一输出。

现场真正痛苦的，不是一次乱码

只坏一个文件，通常还能补救。 麻烦的是 10 个、100 个文件同时到来，而且来源各不相同。

更棘手的是，不同导入系统的“正确答案”不同。

  • 系统 A 只收 UTF-8（无 BOM）
  • 系统 B 用 UTF-8（有 BOM）更稳定
  • 系统 C 以 Shift_JIS 为前提，UTF-8 看起来能读但导入会失败

这时“统一成 UTF-8 就好”的泛泛建议没有价值。 真正需要的是按用途可复现、可回滚的安全流程。

我希望这个工具做到什么

核心只有三点：

  1. 接受任何来源
  2. 按目标导入规范转换
  3. 批量处理时不放大事故

这不是炫技工具，而是降低运维摩擦的工具。

我实际在用的流程

1. 先定“输出规格”

先定输出，不先猜输入。 固定以下三项：

  • 字符编码（UTF-8 / Shift_JIS 等）
  • 换行（LF / CRLF）
  • BOM（有 / 无）

这里不固定，换个人操作结果就会变。

2. 把转换对象拆小

不要一上来全量跑。 按系统、时间段、文件类型切分，先跑小批次。

理由很现实：失败时能回滚。 全量一次跑通固然快，失败就会很惨。

3. 固化条件后批量转换

在 字符编码转换工具 里按用途固定参数，不要中途改。 关键是每次都能用同一套条件重跑。

4. 不要靠“能打开”来判定成功

“文件能打开”常常是事故入口。 至少要核对：

  • 前后行数是否一致
  • CSV/TSV 列数是否保持
  • �（替换字符）是否增加
  • 关键列（ID/编码）的长度与字符类型是否保持

任一项不通过，就不要进入导入。

BOM 不是信仰问题，而是对端规格问题

现场里“要不要 BOM”的争论意义不大。 只看对端系统怎么吃文件。

  • 对端带 BOM 更稳，就输出带 BOM
  • 对端遇 BOM 会坏，就输出无 BOM

比起“理论上正确”，更重要的是“对端不炸”。 运维就是这样。

这个工具的价值，不在“会转换”本身

真正价值有两点：

  • 判断不再因人而异
  • 每次核对成本显著下降

编码事故无法绝对归零。 但可以停止重复同类事故。 这正是我做这个工具的目的：先接住，再按用途稳定地还回去。

结语

这个工具不是理想化产物。 它是为了解决现场反复出现的“烦人编码调整”。

接住不同来源文件，按导入规范统一编码、换行、BOM，再输出。 仅把这条流水线机械化，运维负担就会明显下降。

乱码处理不该靠意志力硬扛。 必须落到可复现流程上，让任何人都能得到同样结果。 做到这一点，才称得上“安全批量抢救”。