Go CSV 解析中文文件为什么出现乱码

Go 用 encoding/csv 读取中文文件时出现“乱码”，通常不是逗号、引号或换行解析错了，而是文件保存时使用了 GBK/GB18030，程序却把原始字节直接交给了按 UTF-8 处理的后续逻辑。修正思路很明确：先确认源文件编码，再在 csv.Reader 之前完成字符集转换。

CSV 是数据格式，GBK、GB18030 和 UTF-8 是字符编码。encoding/csv 只负责把输入拆成记录和字段，不会替你猜测或转换中文文件的编码。

先把乱码归因到字符集边界

同一个 CSV 文件可以同时包含“格式”和“编码”两个独立问题。字段数量忽多忽少、引号没有闭合，通常是 CSV 结构问题；中文变成不可读字符，但字段边界仍然正确，优先检查字符集。

排查时不要把“能看到中文”当作编码判断依据。确认导出系统或编辑器的保存设置，或者从文件来源约定中确认它是 UTF-8、GBK 还是 GB18030。必要时可以先用 utf8.ValidString 对已经读出的字符串做诊断，但它只能说明字节是否是合法 UTF-8，不能反推出原文件一定是什么编码。

encoding/csv 只解决记录和字段解析

官方文档把 encoding/csv 定义为读写逗号分隔值的标准库包，csv.NewReader 接受的是 io.Reader。这意味着它看到什么字节，就把这些字节按 CSV 语法拆分；它没有一个“自动识别中文编码”的 Reader 选项。

因此，下面的最小写法只适用于文件本来就是 UTF-8 的情况：

package main

import (
	"encoding/csv"
	"fmt"
	"os"
	"unicode/utf8"
)

func readUTF8CSV(path string) error {
	// 打开文件后由当前函数负责关闭，避免批量读取时泄漏描述符。
	file, err := os.Open(path)
	if err != nil {
		return fmt.Errorf("打开 CSV: %w", err)
	}
	defer file.Close()

	// 只有源文件已经是 UTF-8 时，才直接把文件交给 csv.Reader。
	records, err := csv.NewReader(file).ReadAll()
	if err != nil {
		return fmt.Errorf("解析 CSV: %w", err)
	}
	for rowIndex, record := range records {
		for fieldIndex, field := range record {
			// 这是诊断信息，不是把 GBK 自动转换成 UTF-8 的方法。
			if !utf8.ValidString(field) {
				return fmt.Errorf("第 %d 行第 %d 列不是合法 UTF-8", rowIndex+1, fieldIndex+1)
			}
		}
	}
	fmt.Printf("读取 %d 条记录\\n", len(records))
	return nil
}

如果文件实际是 GBK，直接调用这段代码可能得到乱码或非法 UTF-8 字节。此时继续调整 Comma、LazyQuotes 等 CSV 选项没有帮助，因为问题发生在 CSV 语法解析之前。

把解码器放在 csv.Reader 之前

golang.org/x/text/encoding 提供字符编码到 UTF-8 的转换接口，simplifiedchinese 则提供 GBK、GB18030 等简体中文编码。用 transform.NewReader 包住文件后，csv.Reader 读到的就是解码后的 UTF-8 字节流。

package main

import (
	"encoding/csv"
	"fmt"
	"os"

	"golang.org/x/text/encoding/simplifiedchinese"
	"golang.org/x/text/transform"
)

func readGBKCSV(path string) error {
	// 文件只负责提供原始字节，字符集转换交给上游 Reader。
	file, err := os.Open(path)
	if err != nil {
		return fmt.Errorf("打开 CSV: %w", err)
	}
	defer file.Close()

	// GBK 解码器把输入转换为 UTF-8；如果来源明确是 GB18030，改用 GB18030。
	decoded := transform.NewReader(file, simplifiedchinese.GBK.NewDecoder())
	reader := csv.NewReader(decoded)
	records, err := reader.ReadAll()
	if err != nil {
		return fmt.Errorf("解码或解析 CSV: %w", err)
	}
	for _, record := range records {
		fmt.Println(record)
	}
	return nil
}

依赖使用前先在模块中添加：

# 在 Go module 中加入字符集转换依赖。
go get golang.org/x/text/encoding/simplifiedchinese golang.org/x/text/transform

GBK、GB18030 和 UTF-8 的兼容注意

不要把“中文文件”直接等同于 GBK。Windows 导出、旧业务系统和 Excel 工作流可能使用不同编码；如果来源明确是 GB18030，应选择 simplifiedchinese.GB18030.NewDecoder()。解码器选错时，代码仍然能运行，但个别字符可能转换失败或显示不符合预期。

另外，utf8.ValidString 适合发现“结果不是合法 UTF-8”的情况，不适合在多个中文编码之间自动猜测。工程上更可靠的做法是让上传协议、文件命名约定或导出配置明确记录编码；当来源不可控时，把编码选择作为显式配置，而不是写死一个“中文默认 GBK”。

采用建议：先定编码，再选 Reader

可以按下面的顺序处理：

1. 确认字段边界是否正常，排除逗号、引号和换行问题。
2. 从生产者或导出设置确认 UTF-8、GBK 或 GB18030，不要只凭肉眼判断。
3. UTF-8 文件直接使用 csv.NewReader(file)；旧中文编码先用对应解码器包装文件。
4. 把打开、解码、解析和关闭错误分别保留，避免把编码错误伪装成空数据。

记住一条边界：csv.Reader 解决“怎么分列”，解码器解决“字节代表什么字符”。把两层职责分开，中文 CSV 的乱码问题通常就能稳定定位。

常见问题

为什么调整 Reader.Comma 不能修复中文乱码？

Comma 只决定字段分隔符，乱码发生在字符字节转换层，应该先处理编码再解析。

能不能用 utf8.ValidString 自动把 GBK 转成 UTF-8？

不能。它只做合法性判断；转换需要明确的源编码和对应 decoder。

GBK 和 GB18030 应该选哪个？

以文件生产方的真实设置为准。已知是 GB18030 就使用 GB18030 decoder，不要因为文件含中文就默认 GBK。