Go 怎么把 GBK 或 Latin-1 CSV 转成 UTF-8 后读取

我处理历史 CSV 时最容易踩的坑，不是逗号写错，而是文件还没进入 encoding/csv，字符串就已经乱码了。Go 的 csv.Reader 接收的是 io.Reader，它并不负责猜测 GBK 或 Latin-1；正确做法是在它前面放一个解码器，把原始字节转换成 UTF-8，再交给 CSV 解析器。

先把字符集转换放在 csv.Reader 前面

golang.org/x/text/encoding 提供从其他字符集到 UTF-8 的解码接口；simplifiedchinese.GBK 明确表示 GBK，charmap.ISO8859_1 表示 ISO-8859-1。它们的 Decoder 都能包装成新的 Reader，所以 CSV 解析器不需要知道原始文件是什么编码。

package main

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

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

// readCSV 只负责把指定编码接到 csv.Reader 前面，不猜测文件编码。
func readCSV(r io.Reader, enc encoding.Encoding) error {
	decoded := enc.NewDecoder().Reader(r)
	reader := csv.NewReader(decoded)
	reader.FieldsPerRecord = -1 // 先允许字段数变化，业务可在读到记录后自行检查。

	for {
		record, err := reader.Read()
		if err == io.EOF {
			return nil // 正常读完文件。
		}
		if err != nil {
			return fmt.Errorf("读取 CSV 失败: %w", err) // 这里可能是解码错误或 CSV 解析错误。
		}
		fmt.Println(record)
	}
}

func main() {
	f, err := os.Open("orders-gbk.csv")
	if err != nil {
		log.Fatal(err)
	}
	defer f.Close() // 文件句柄由调用方负责关闭。

	if err := readCSV(f, simplifiedchinese.GBK); err != nil {
		log.Fatal(err)
	}

	_ = charmap.ISO8859_1 // Latin-1 文件可把这里替换成 ISO8859_1。
}

这里最关键的不是 FieldsPerRecord，而是 csv.NewReader 收到的对象已经是解码后的 Reader。encoding/csv 仍然负责引号、换行和字段拆分；字符集转换只负责把字节变成 UTF-8。

GBK 与 Latin-1 怎么选，别靠乱码反推

如果来源明确写着“简体中文旧系统导出”，优先使用 GBK；如果来源是只包含西欧单字节字符的 ISO-8859-1 文件，使用 Latin-1。两者不能只看文件扩展名判断。尤其要留意 Windows-1252：它和 ISO-8859-1 接近，但并不是完全相同的字符映射，来源若明确是 Windows 应选择 charmap.Windows1252。

一个实用判断是：不要把“能读出几行”当成编码正确。错误编码可能仍然产生合法字符串，只是中文或重音字符悄悄变了。应在小样本里放入来源实际会出现的关键字符，再和原系统导出的值比对。

把解码错误和 CSV 错误分层排查

这条链路中有三类错误。第一类是 Decoder 读到非法字节，通常说明编码选错或输入被截断；第二类是 csv.Reader 返回 ErrFieldCount，说明记录字段数与当前规则不一致；第三类是引号、换行等语法问题，属于 CSV 结构错误，不应通过更换 GBK/Latin-1 来修复。

record, err := reader.Read()
if err != nil {
	if err == io.EOF {
		return nil // 文件正常结束，不算失败。
	}
	var parseErr *csv.ParseError
	if errors.As(err, &parseErr) {
		return fmt.Errorf("第 %d 行 CSV 结构错误: %w", parseErr.Line, err)
	}
	return fmt.Errorf("字符集解码或输入读取错误: %w", err)

如果业务要求每行固定列数，可以把 FieldsPerRecord 设为预期值；如果文件确实允许可选列，保持默认推断或设为 -1，再在业务层做明确校验。不要为了绕过一条字段数错误，把编码器换成另一个编码。

用小样本做最后确认

发布到批处理前，我会先拿几十行样本确认四件事：第一行表头的中文或重音字符正确；带逗号的引号字段没有被拆开；跨行字段仍能完整返回；文件尾部截断时能收到错误而不是静默得到半条记录。大文件则继续使用 Reader 流式读取，只有确实需要全量内存数据时才调用 ReadAll。

相关问题

Go 的 csv.Reader 能自动识别 GBK 吗？

不能。它读取的是 io.Reader，不会替你探测字符集；应在前面显式放置正确的 Decoder。

Latin-1 和 Windows-1252 可以互换吗？

不能默认互换。两者有相近部分，但特殊标点和控制区映射存在差异，优先按来源声明选择。

为什么解码成功后仍然报 CSV 错误？

字符集转换只解决字节到 UTF-8 的问题；字段数量、引号闭合和跨行字段仍由 CSV 语法决定，需要按解析错误继续排查。