用记事本打开 CSV、日志或配置文件出现一堆乱码，几乎都不是文件坏了，而是编码识别错误。记事本按“当前系统 ANSI 代码页”去解释那些没有 BOM 的文件，中文 Windows 上就是 GBK；而文件本身可能是 UTF-8、Shift-JIS 或 UTF-16，读出来自然满屏问号。本文给出判断方法与六种可靠解法。

一、三步判断真实编码

1. 看能不能救回部分汉字：出现「日本語」这类“字母带变音符”的组合，是 UTF-8 被当 GBK/Latin-1 读的典型特征；出现「锟斤拷」则是 GBK 被当 UTF-8 反复转码的经典后遗症；出现「浣犲ソ」是 UTF-8 汉字被按 GBK 解释。
2. 记事本右下角状态栏：Win10/11 新版记事本在底部显示当前识别到的编码（UTF-8 / UTF-8 with BOM / ANSI / UTF-16 LE）。不显示编码时，可把窗口拉宽或升级记事本。
3. 用十六进制看前几个字节：EF BB BF = UTF-8 with BOM；FF FE = UTF-16 LE；FE FF = UTF-16 BE。什么都没有就是“无 BOM”，只能靠猜。

二、六种解法（从易到难）

2.1 记事本“另存为”时手动改编码

先用正确方式打开（见 2.2），再点 文件 → 另存为，底部“编码”选择 UTF-8 保存。这是转码的标准动作。

2.2 通过编码重新打开

Win11 新版记事本：文件 → 打开，或直接在打开对话框右下选择编码；也可先复制内容到浏览器控制台观察。更可靠的是用 VS Code：右下角点编码 → “通过编码重新打开（Reopen with Encoding）”，逐个试 GBK/UTF-8/Big5，中文文件用 GBK (GB 18030) 命中率最高。

2.3 命令行批量检测与转换

PowerShell 转换单个文件（把 GBK 转 UTF-8）：

$in  = 'D:\data\gbk.txt'
$out = 'D:\data\utf8.txt'
$gbk = [System.Text.Encoding]::GetEncoding('GB18030')
$txt = [System.IO.File]::ReadAllText($in, $gbk)
[System.IO.File]::WriteAllText($out, $txt, (New-Object System.Text.UTF8Encoding($false)))

注意 UTF8Encoding($false) 表示不写 BOM，很多脚本、Java、Go 工具读到 BOM 会报“非法字符”。

2.4 CSV 用 Excel 打开乱码

Excel 双击打开 CSV 时默认按 ANSI 解析，UTF-8 的中文就成乱码。三种办法：① 用带 BOM 的 UTF-8 保存（Excel 能识别）；② Excel 里“数据 → 从文本/CSV”导入并手动选 65001: UTF-8；③ 用 WPS 打开，它对无 BOM UTF-8 的探测更宽松。

2.5 程序读取日志乱码

Java/Python 读文件务必显式指定编码：open(p, encoding='utf-8', errors='replace')；不要依赖系统默认编码。写日志的组件与读日志的组件编码不一致，是“程序里乱码、记事本里正常”的主因。

2.6 网页与邮件正文乱码

网页乱码看响应头与 meta：Content-Type: text/html; charset=utf-8 与 <meta charset="utf-8"> 必须一致；数据库连接还要设 utf8mb4（表情符号必须 4 字节字符集，仅 utf8 会截断）。

三、预防：养成一套统一编码规范

• 项目内文本文件统一 UTF-8 无 BOM；跨 Windows 图形界面交换数据（Excel/记事本手工场景）可考虑 UTF-8 BOM。
• Git 仓库根加 .editorconfig：charset = utf-8，避免不同编辑器写进 GBK。
• 导出接口时设 Accept-Charset 与 charset，CSV 前加 BOM 让 Excel 正确识别。
• 数据库、表、连接串三处字符集都用 utf8mb4，并在连接参数加 charset=utf8mb4。

四、常见问题 FAQ

问：ANSI 到底是什么编码？
答：ANSI 不是一个固定编码，而是“当前系统非 Unicode 程序默认代码页”的代称。中文系统上是 GBK，日文系统是 Shift-JIS，同一个文件换台机器打开就可能乱码——这正是它危险的地方。

问：老文件里没有 BOM，怎么确认是 GBK 还是 Big5？
答：用 VS Code 切换编码打开比较，出现繁体合理字就是 Big5；也可用工具检测库（如 chardet）跑一遍。

问：能修复已经变成“锟斤拷”的文件吗？
答：不能。锟斤拷意味着原始字节在多次转码中已被替换字符覆盖，信息已丢失，只能从源头重新导出。

核心记忆：乱码 = 编码不匹配，不是文件损坏。判断顺序看特征串（æ—¥ / 浣犲 / 锟斤拷）→ 查 BOM 与状态栏 → 用“通过编码重新打开”验证 → 另存为 UTF-8（无 BOM）。日常统一到 UTF-8 无 BOM，并从源头显式指定读写编码，这类问题就基本消失了。

• 编码
• 记事本
• UTF-8