CSV 打开是乱码怎么解决：Excel 中文变问号的几种原因

先别急着删文件

从系统导出一个 CSV，双击用 Excel 打开，满屏问号或者一堆莫名其妙的汉字。第一反应通常是文件坏了、导出错了，然后重新导一次，还是乱码。

其实文件大概率是好的。这类问题的根源不在数据，在于"用什么规则去读这些字节"。同一串字节，按不同编码去解，出来的文字完全不同。解错了就是乱码。

乱码长什么样，对应什么问题

先看症状，能判断是哪种情况，也决定了还能不能救回来。

现象	含义	能否恢复
中文变成 ???	转换时字符被替换掉了，原始信息已丢失	较难，需要从源头重导
显示成方块 □□	字体缺字，或编码解释错误	能，换编码或换字体
出现「涓枃」「鏂囦欢」这类怪汉字	UTF-8 被当成 GBK 读了	能，换回 UTF-8 即正常
一个汉字变成几个乱码符号	两字节编码被当成单字节读了	多数能，换编码尝试

重点看第三行。如果你看到的是"涓枃""鏂囦欢"这种看着像汉字、但组合起来读不通的东西，那基本可以确定是 UTF-8 的文件被按 GBK 解释了，这种情况换对编码立刻就好，一个字都不会丢。

但如果是实打实的问号，说明字符在转换过程中已经被替换掉了，字节层面已经丢了信息，这种情况下再怎么调编码也变不回来，只能回到导出那一步重新来。

为什么会错：三种编码在打架

中文环境下的 CSV 乱码，几乎都是这三个东西没对上。

UTF-8 是现在的通用标准，一个中文字符占三个字节。它的兼容性最好，跨平台、跨语言都认。GBK 是中文 Windows 的传统编码，一个汉字占两个字节，早期国内软件大量使用。还有一个不算编码的东西叫 BOM，是一段藏在文件开头的三个字节，本身的唯一作用是告诉读文件的程序"我是 UTF-8，按 UTF-8 读我"。

问题就出在这里：Excel 双击打开 CSV 时，倾向于按系统本地编码来读。简体中文 Windows 上就是 GBK。如果文件是无 BOM 的 UTF-8，Excel 就按 GBK 去解，中文自然全乱。而新版记事本会主动探测编码，所以同一个文件用记事本打开是好的，用 Excel 打开就乱，这不是谁坏了，是两者的判断策略不同。

# 用十六进制看开头三个字节，判断有没有 BOM
# EF BB BF 开头 = UTF-8 带 BOM
# 无标记     = 无 BOM 的 UTF-8 或 GBK

# 文件内容：中文
# UTF-8 编码（6 字节）: E4 B8 AD E6 96 87
# GBK  编码（4 字节）: D6 D0 CE C4

# 同一个「中」字，两种编码字节数不同
# 这也是判断编码的线索之一

不改文件的打开方式（推荐）

最省事、也最不容易出错的办法：别双击，走数据导入。

打开 Excel，切到"数据"选项卡，找到"从文本/CSV"（不同版本叫法略有差别），选中那个文件。接下来会弹出预览窗口，让你选编码。

关键就在这一步。默认通常是"简体中文(GBK)"或者"936"，把它改成 UTF-8，看预览里的中文是否正常。正常了就点加载。整个过程中原文件一个字节都没动，只是这次读取用了正确的规则。

1. Excel 里点「数据」→「从文本/CSV」
2. 选择乱码的 CSV 文件
3. 在编码下拉里切换到 UTF-8，观察预览是否正常
4. 正常则点「加载」，数据进入表格

顺带说，那个预览窗口还能处理分隔符问题。有些 CSV 用了分号或制表符而不是逗号，导入时一并指定，省得后面再分列。

要改文件的话，怎么改

如果目的就是让双击也能正常打开，那就得动文件本身，给无 BOM 的 UTF-8 加上 BOM。

用记事本另存为是一种办法：打开文件，另存为的时候把编码选成"UTF-8 带 BOM"。不加 BOM 的 UTF-8 存出来，Excel 还是认不出来。

命令行也能做，而且适合批处理：

# PowerShell：把无 BOM 的 UTF-8 转成带 BOM
$content = Get-Content input.csv -Raw -Encoding UTF8
[IO.File]::WriteAllText('output.csv', $content, (New-Object System.Text.UTF8Encoding($true)))

# 反过来，去掉 BOM（给 Linux 或程序处理时更干净）
$content = Get-Content input.csv -Raw -Encoding UTF8
[IO.File]::WriteAllText('output.csv', $content, (New-Object System.Text.UTF8Encoding($false)))

要注意别反复转换。转一次就够了，来回折腾反而容易在中间某一步搞丢字符。

导出的时候怎么避免

与其事后修，不如在生成端就选对。

你要把 CSV 给别人，且对方多半用 Excel 打开，那就导出成"UTF-8 带 BOM"。这一个动作能省掉对方所有的折腾。

如果导入方是程序、数据库、或者 Linux 环境，那就用无 BOM 的 UTF-8。BOM 在某些解析器里会被当成数据的一部分，反而造成字段错位，比如第一列的表头变成「中文」，前面多了一个看不见的字符。这就是为什么同样的文件，有时 Excel 打开正常，程序读却报错。

还有一个更彻底的选择：直接给 xlsx。它内部自带编码信息，不存在这个猜谜过程。代价是体积大一些，且不是纯文本，不方便用脚本处理。

排查顺序建议

遇到乱码，按这个顺序走，通常几步就定位了。

先确认现象类型：问号还是怪汉字。怪汉字说明能救，问号说明要找源头重导。然后用十六进制工具看开头有没有 BOM，确定文件的实际编码。接着用导入方式换编码试读，这一步能验证你的判断。最后再决定是否需要改文件本身。

别一上来就删文件重导。导出的数据源如果还是同样的编码设置，重导多少次都是同一个结果。

常见问题 FAQ