修复 CSV 中文乱码，先确认编码

中文姓名变成符号，或者显示成 中文 一类文字时，通常不是内容被“翻译”了，而是软件用错了字符编码。稳妥的处理方法是保留源文件，确认 UTF-8 或 GB18030，再另存一份经过验证的副本。

乱码是怎样产生的

CSV 本质上是一串字节，字符编码负责把字节解释成文字。UTF-8 可以表示 Unicode 字符；GB18030 常见于中国大陆的 Windows 软件和较早的业务系统导出。两者都能保存中文，但同一组字节按照不同编码读取，结果会完全不同。

改文件名、换后缀或者更换字体，都不会转换文件里的字节。反复试着打开并保存，也可能把本来还能恢复的内容变成新的错误数据。

先判断，再转换

先检查文件开头是否有 UTF-8 BOM。没有 BOM 的文件仍可能是 UTF-8。如果严格 UTF-8 解码失败，而且文件来自中文 Windows 软件，可以把 GB18030 作为候选继续验证。

检测工具只能提供线索，不能判断客户姓名或地址是否正确。应挑选几条已知记录，检查常用汉字、生僻字、中文标点和中英文混排内容。软件没有报错，只能说明字节可以解码；样本内容可读且符合预期，证据才更充分。

只解码一次，再编码一次

转换分成两步：按照已确认的源编码读取，再按照目标编码写入新文件。下面的 Python 示例会在遇到无法解码的内容时停止，不会静默替换字符：

from pathlib import Path

source = Path("export-original.csv")
target = Path("export-utf8-bom.csv")

text = source.read_text(encoding="gb18030", errors="strict")
target.write_text(text, encoding="utf-8-sig", errors="strict")

如果源文件已经确认是 UTF-8，就把读取编码改为 utf-8。目标编码 utf-8-sig 会写入带 BOM 的 UTF-8，许多 Windows 版 Excel 工作流更容易正确识别。这个例子只处理字符编码，不检查列数、重复行、带引号换行或公式风险。

前导零要按文本保留

编码正确，不代表 Excel 不会改动数据。表格软件仍可能把 001234 显示成 1234，把长编号转成科学计数法，或者把某些值猜成日期。客户编号、邮政编码、电话号码、发票号和商品编码，通常应按文本导入，除非业务规则明确要求数值类型。

可以通过 Excel 的导入功能选择 UTF-8，并把编号列指定为文本。若文件最终交给其他系统，也要用那个系统实际导入一次。文本编辑器里显示正常，并不能证明下游软件不会重新解释字段。

转换后检查表格结构

不要用“按行拆分、按逗号拆分”的简单方法验证 CSV。带引号字段可以包含逗号、双引号和换行。至少检查以下内容：

• 表头和预期列数没有变化；
• 源文件与输出文件的记录数一致；
• 中文姓名、地址和标点可读；
• 带引号的逗号仍留在原字段中；
• 带前导零的编号没有丢失；
• 没有意外出现替换字符 �；
• 原文件的哈希和修改时间保持不变。

抽样时可包含首行、末行、生僻字、带逗号的地址和前导零编号。记录源编码、目标编码、输入输出行数和额外清理规则，后续复核会更容易。

什么时候使用 UTF-8 BOM

BOM 不是 UTF-8 的必需部分。它在不少 Windows 表格工作流中能减少错误猜测，但有些导入系统明确要求不带 BOM。最终选择应以接收软件的规范和实际测试为准。

BOM 也不能证明 CSV 结构正确。它只说明文件希望按照 UTF-8 读取，与分隔符、引号、记录数和业务规则无关。

私密文件适合留在本机处理

客户导出文件可能包含个人信息或商业数据。上传到陌生转换网站，会产生新的数据副本。CSV Desk 在 Microsoft Edge 中本地运行，支持 UTF-8 和 GB18030 输入，另存带 BOM 的 UTF-8 CSV，并生成 JSON 变更报告。原文件不会被覆盖。

说明：本指南和所链接的软件由 AI 辅助制作，并经过浏览器验证。编码选择仍需结合来源系统和代表性记录核对。