Go 读取 Shift_JIS CSV 时怎样把字符正确转成 UTF-8

Go 的 encoding/csv 负责识别逗号、引号和换行，它不会替你判断输入字节是不是 Shift_JIS。处理旧系统导出的日文 CSV 时，正确的顺序是：先把原始字节流交给 Shift_JIS 解码器，再把得到的 UTF-8 文本流交给 csv.Reader。

官方资料：https://pkg.go.dev/golang.org/x/text/encoding/japanese

最小可靠写法是 japanese.ShiftJIS.NewDecoder() 配合 transform.NewReader，把解码层放在 csv.NewReader 前面。不要先把错误编码的字节转换成字符串，也不要把 Shift_JIS 当作 UTF-8 直接读取。

先看清楚数据经过了哪一层

CSV 的“格式”与“字符编码”是两件事。逗号、双引号、换行属于记录格式；Shift_JIS、UTF-8 属于字节如何映射为字符。只把 csv.NewReader(file) 直接套在 Shift_JIS 文件上，ASCII 字段可能看起来正常，但日文字段会出现乱码或替换字符。

本文的边界也很明确：只解决“进入 csv.Reader 前的字符集转换”，不展开字段数不一致、表头映射和业务校验。

准备依赖并选择 Shift_JIS 解码器

golang.org/x/text/encoding 定义了字符编码接口，具体的日文编码实现位于 golang.org/x/text/encoding/japanese。其中的 ShiftJIS 可以创建解码器；transform 则提供把转换器包装成 io.Reader 的能力。

# 在模块目录执行，安装字符集转换依赖
go get golang.org/x/text@latest

如果项目需要可复现构建，应在团队约定的依赖升级流程中固定版本，而不是把文章里的版本号当成必须使用的版本。

最小配方：解码层放在 csv.Reader 前

下面的函数接收一个普通 io.Reader，因此文件、HTTP 响应体和内存缓冲区都能复用同一套读取逻辑。关键点是 transform.NewReader 返回的仍然是流，csv.Reader 看到的是已经解码的 UTF-8 字节。

package main

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

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

func readShiftJISCSV(src io.Reader) error {
	// 解码器必须位于 CSV 解析器之前，让字段内容先变成 UTF-8。
	decoded := transform.NewReader(src, japanese.ShiftJIS.NewDecoder())
	reader := csv.NewReader(decoded)

	for {
		// Read 会持续读取记录；正常结束由 io.EOF 表示，而不是失败。
		record, err := reader.Read()
		if err == io.EOF {
			return nil
		}
		if err != nil {
			// 这里统一返回解码层或 CSV 层暴露的错误，交给上层记录来源。
			return fmt.Errorf("读取 Shift_JIS CSV: %w", err)
		}
		fmt.Println(record)
	}
}

func main() {
	file, err := os.Open("input-shiftjis.csv")
	if err != nil {
		fmt.Println(err)
		return
	}
	defer file.Close() // 文件句柄由打开它的这一层负责关闭。

	if err := readShiftJISCSV(file); err != nil {
		fmt.Println(err)
	}
}

这段代码没有把整个文件读进内存，也没有调用 string(rawBytes) 做未经声明的转换。解码器会随着读取推进处理字节，CSV 解析器再按记录返回字段。

流式读取时，为什么不能在每次 Read 后手动拼字符串

多字节字符可能被拆在相邻的底层读取之间。把每次 Read 得到的字节片段立即转换成字符串，容易在字符边界处做出错误判断。transform.Reader 持有转换器状态，适合把不完整的字节片段留到下一次读取继续处理。

因此，推荐把“原始输入到解码 Reader”的连接建立一次，后面只使用这个 Reader。不要在循环内部反复创建解码器，否则状态边界会被人为切断。

文件、HTTP Body 和内存字节的三种变体

函数只依赖 io.Reader 是最小配方的价值所在。不同来源只负责提供输入，并不改变解码顺序。

// 文件输入：打开后把文件 Reader 交给同一个解析函数。
file, err := os.Open("legacy.csv")
if err != nil {
	return err
}
defer file.Close()
if err := readShiftJISCSV(file); err != nil {
	return err
}

// HTTP 输入：响应体本身就是流，读取完成后必须关闭。
resp, err := http.Get(endpoint)
if err != nil {
	return err
}
defer resp.Body.Close()
if err := readShiftJISCSV(resp.Body); err != nil {
	return err
}

// 内存输入：适合测试或已经拿到完整字节的场景。
if err := readShiftJISCSV(bytes.NewReader(raw)); err != nil {
	return err
}

上面的片段展示的是接入方式；真实 HTTP 代码还应按业务需要检查状态码、超时和响应大小。它们属于输入层责任，不应和字符集转换混在一起。

常见误区：把乱码修复写成 CSV 解析问题

尤其不要用 strings.ToValidUTF8 或替换字符来掩盖未知编码。那只能让程序继续运行，却可能静默改变商品名、客户名等业务字段。

一个简洁的排查顺序

1. 先确认原始文件或接口声明的字符编码，必要时保留一份原始字节样本。
2. 把解码器放在 csv.NewReader 之前，不要先把字节强转成字符串。
3. 保持解码 Reader 的生命周期覆盖整个 CSV 读取循环。
4. 用 errors.Is(err, io.EOF) 或直接判断 io.EOF 结束循环，其余错误原样包装并返回。
5. 确认字符正常后，再单独讨论列数、表头和业务字段校验。

总结

Go 读取 Shift_JIS CSV 的关键不是给 csv.Reader 增加一个“编码参数”，而是在它前面插入一个有状态的转换 Reader：原始字节流 → ShiftJIS Decoder → transform.Reader → csv.Reader。这样既能复用同一套文件、HTTP 和内存输入代码，也能避免在多字节字符跨读取边界时自行拼接造成的乱码。

相关问题

已经是 UTF-8 的 CSV 还需要这个解码器吗？

不需要。UTF-8 输入直接交给 csv.NewReader 即可；只有确认输入不是 UTF-8 时才添加对应的解码层。

Shift_JIS 和 EUC-JP 可以混用同一个解码器吗？

不能。它们是不同编码，应该根据输入来源选择 japanese.ShiftJIS 或 japanese.EUCJP，不要用“看起来能读”来判断。