Go x/text/encoding/japanese ShiftJIS 怎样解码日文 CSV

收到日文系统导出的 ShiftJIS CSV 时，我会先把文件字节流解码为 UTF-8，再交给 Go 的 encoding/csv 处理引号、逗号和跨行字段。直接把原始字节转换为 string，并不会完成字符编码转换；csv.Reader 也不会替你识别日文编码。

本文用到的官方包入口：https://pkg.go.dev/golang.org/x/text/encoding/japanese。该包的 ShiftJIS 文档同时列出 Code Page 932、Windows-31J 名称。实际接入仍应以导出方给出的编码和字段约定为准。

把转码器接在 CSV Reader 前面

我会把导入拆成两件事：解码器负责“这些字节表示哪些字符”，CSV Reader 负责“这些字符怎样组成字段和记录”。这让分隔符和字段规则留在解析层，不必在编码层手工切割字符串。

japanese.ShiftJIS.NewDecoder() 创建一个用于当前流的解码器。transform.NewReader 包装底层 Reader，在读取时转换字节。把包装后的 Reader 传给 csv.NewReader，即可让 CSV 层读取 UTF-8。这里的流式连接避免先主动把整个文件读入一个大切片，但单条巨大记录仍可能占用较多内存。

这组职责来自 transform.Reader 文档与 encoding/csv 文档；不要把“流式”理解成无论输入多大都具有固定内存上限。

最小配方只需要两层 Reader

已有一个只包含 ShiftJIS CSV 内容的 src io.Reader 时，核心连接可以缩到下面几行。它是函数内部片段；完整的 import 和文件生命周期在末节给出。

// 先把 ShiftJIS 字节流解码为 UTF-8。
decoded := transform.NewReader(src, japanese.ShiftJIS.NewDecoder())
// 再由 CSV Reader 处理字段和引号。
reader := csv.NewReader(decoded)
// 示例约定每条记录有三列；包括表头。
reader.FieldsPerRecord = 3
record, err := reader.Read()
// 有错误时不要直接把 record 写入业务表。
if err != nil {
    return err
}
_ = record // 这里接入当前记录的字段处理。

我倾向于明确设置列数，而不是靠第一行决定结构。Reader 默认的 FieldsPerRecord=0 会采用第一条记录的字段数，后面要求一致；负数则允许变长记录。三列只是本文演示契约，导入真实文件时要替换成业务定义。

我会先固定编码和字段约定

文件扩展名 .csv 不包含字符集信息。UTF-8、ShiftJIS、EUC-JP 都可能装在相同扩展名里，我会先拿到导出设置和一份包含汉字、假名、符号的样本，再决定解码器。已经是 UTF-8 的文件应走对应输入路径，不要再套 ShiftJIS Decoder；来源不明时也不宜轮流尝试几个解码器，以“没有报错”作为自动识别结果。

字段包含逗号或者换行时，让 csv.Reader 按 CSV 引号规则读取完整记录，不要用 strings.Split 按逗号拆，也不要先用 Scanner 按物理行拼业务行。表头是否存在、列顺序、分隔符是否为逗号，都应由导出约定决定。制表符文件需要明确修改 reader.Comma，不应因为显示错位就随意开启 LazyQuotes。

对于小型内存输入，Decoder.Bytes 可以先解码再解析；对于文件或网络流，我更愿意维持 Reader 链。每次导入新建解码器，也让它的状态只服务当前输入。

把乱码、CSV 错误和业务拒绝分开

我最在意的是不要把三类失败混成“CSV 乱码”。底层读取失败和 CSV 结构失败由 Read 的错误分支处理；字段为空、代码格式不符等由业务规则处理；写入失败由处理函数向外返回。Read 返回错误时可能同时给出部分字段或字段数不符的记录，下面的实现选择停止，不提交该条记录。

还有一个容易误判的边界：Decoder 官方说明指出，不能转换的输入字节可以变成 UTF-8 的替换字符 U+FFFD，而不必返回解码错误。因此 err==nil 并不能证明原文件的编码正确、每个日文字符都保真。

如果字段出现“�”，我会保留原文件，让导出方确认编码，再按业务规则决定是否拒绝或人工处理。搜索 U+FFFD 可以作为告警线索，但不能独立证明原始数据一定损坏；严格无损导入需要另外设计源字节级规则与字符映射策略。不要给 UTF-8 输出套一次有效性判断，就宣称已经严格验证了 ShiftJIS 原始字节。

封装成逐条处理的文件导入函数

下面封装约定每条记录三列，调用方提供处理函数。函数负责打开、关闭文件及逐条读取，不默认跳过表头，也不输出原始字段到日志。它适合接入已有导入服务；它本身不提供整文件事务，先前已经处理成功的记录不会因为后续失败而自动回滚。

package importcsv

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

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

// ImportShiftJIS 逐条导入三列 CSV，表头策略由调用方决定。
func ImportShiftJIS(path string, consume func([]string) error) (retErr error) {
    if consume == nil {
        return fmt.Errorf("记录处理函数不能为空")
    }
    file, err := os.Open(path)
    if err != nil {
        return fmt.Errorf("打开导入文件: %w", err)
    }
    // 只有尚无主要错误时，才把关闭失败作为返回错误。
    defer func() {
        if closeErr := file.Close(); closeErr != nil && retErr == nil {
            retErr = fmt.Errorf("关闭导入文件: %w", closeErr)
        }
    }()

    // 每个文件使用独立解码器，输入必须由导出方确认为 ShiftJIS。
    decoded := transform.NewReader(file, japanese.ShiftJIS.NewDecoder())
    reader := csv.NewReader(decoded)
    reader.FieldsPerRecord = 3

    for number := 1; ; number++ {
        fields, readErr := reader.Read()
        if readErr == io.EOF {
            return nil // 已处理完全部记录。
        }
        if readErr != nil {
            return fmt.Errorf("读取第 %d 条记录: %w", number, readErr)
        }
        // 错误记录不会进入此分支；业务规则由处理函数落实。
        if consumeErr := consume(fields); consumeErr != nil {
            return fmt.Errorf("处理第 %d 条记录: %w", number, consumeErr)
        }
    }
}

依赖应通过项目的 go.mod 管理，采用团队批准且与当前 Go 工具链兼容的 x/text 版本。上面的代码为讲解实现，本文没有给出本地执行或生产验证结果。

接入时我会让处理函数显式识别并核对表头，约定字段规则，再决定是逐条提交，还是将记录放入有事务与去重策略的业务层。错误中的记录序号表示 CSV 逻辑记录顺序，不等于包含跨行引号字段时的物理行号。对已有稳定日文导出规范的任务，这条 Reader 链足够清晰；来源编码无法确认时，先解决输入契约才是关键。