Go x/text/encoding/japanese EUCJP 怎样转换日文历史文件

Go 可以用 japanese.EUCJP.NewDecoder() 将 EUC-JP 字节解码为 UTF-8。转换历史文件时，将解码器交给 transform.NewReader，再用 io.Copy 写入一个独立输出文件即可。我会保留原文件，并拒绝覆盖已有目标，避免把一次编码选择错误变成不可逆的原文损失。

官方包入口：https://pkg.go.dev/golang.org/x/text/encoding/japanese。本文针对编码已明确的日文文本文件，不把 EUC-JP 解码器当成自动识别所有日文历史数据的工具。

把旧编码限制在文件接入边界

这种做法可以看成文件接入层的编码适配：源文件保留原始 EUC-JP 字节，解码边界负责生成 UTF-8 副本，下游文本消费者只接触新格式。我的取舍是多占一份存储空间，换取原文可追溯和重新转换的机会。

图中的源文件、编码约定、EUCJP Decoder、transform.Reader、UTF-8 副本、文本消费者六个对象分别承担输入、配置、转换和使用职责。Reader 包装让转换随读取发生，不需要应用主动把整份文件放进一个大切片；输出大小与速度仍由实际文本和设备决定。

先确认文件确实采用 EUC-JP

“日文文件”和“EUC-JP 文件”不是同一个条件。历史导出也可能使用 Shift JIS、ISO-2022-JP 或 UTF-8。扩展名 .txt、能显示部分 ASCII 字符、某个解码器没有报错，都不足以单独确认编码。

我会先查导出系统配置、历史接口约定和文件随附说明，再选择 EUCJP。若同一文件拼接了多种来源，应先解决来源和分段约定；反复更换解码器直到文字看着顺眼，并不能提供可靠的迁移依据。

japanese 包文档提供 EUCJP 编码对象。NewDecoder 用于旧编码到 UTF-8；NewEncoder 是相反方向，不能用它处理待解码的原始字节。

流式转换为独立 UTF-8 文件

下面函数要求目标路径尚不存在，采用只创建新文件的方式写入。调用期间文件可能已经可见，因此这是独立副本方案，并没有承诺下游只能看见完整结果。需要发布时原子可见的系统，应另行采用临时文件与受控提交方案。

package legacytext

import (
    "errors"
    "fmt"
    "io"
    "os"

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

// ConvertEUCJP 新建 UTF-8 副本；示例使用 Go 1.20+ 的 errors.Join。
func ConvertEUCJP(source, target string) (retErr error) {
    input, err := os.Open(source)
    if err != nil {
        return fmt.Errorf("打开源文件: %w", err)
    }
    // 源文件只读，关闭错误仍交给调用方。
    defer func() {
        retErr = errors.Join(retErr, input.Close())
    }()

    output, err := os.OpenFile(target, os.O_WRONLY|os.O_CREATE|os.O_EXCL, 0600)
    if err != nil {
        return fmt.Errorf("新建目标文件: %w", err)
    }
    // 写入或关闭失败时清理本次创建的副本，不修改源文件。
    defer func() {
        retErr = errors.Join(retErr, output.Close())
        if retErr != nil {
            retErr = errors.Join(retErr, os.Remove(target))
        }
    }()

    // 每个文件单独创建解码器，避免把多个输入的状态混用。
    reader := transform.NewReader(input, japanese.EUCJP.NewDecoder())
    if _, err := io.Copy(output, reader); err != nil {
        return fmt.Errorf("转换 EUC-JP 文件: %w", err)
    }
    return nil
}

O_EXCL 与 O_CREATE 组合使已有目标不会被截断；0600 是新文件申请的权限，适用于先由当前账户处理的副本。调用方还应选择受自己控制的目录，避免转换过程中有其他任务替换目标路径。清理失败也会被合并到返回错误，不能因为调用失败就默认残留文件已经消失。

defer 按后注册先执行，示例先关闭并按需清理输出，再关闭输入。如果只有最后的源文件关闭失败，副本会保留而函数返回错误；恢复逻辑应区分这种情况与写入失败。函数未执行，依赖应固定为与项目工具链兼容的 x/text 版本。

转换无报错也不等于文字无损

Decoder 的官方约定说明，不能转换的字节可以被表示为 UTF-8 的替换字符 U+FFFD，而不必返回错误。因此 io.Copy 正常结束只说明这条读取与写入链没有报告错误，不能证明编码选择正确，也不证明每个字符都保真。

图中的原始字节、来源说明、转换副本、异常记录、业务导入、迁移记录构成归档关系。迁移记录关联原始字节、来源说明和转换副本；异常记录引用来源说明；业务导入使用转换副本。这些记录是应用层建议，不是解码器自动生成的报告。

出现“�”时，应回到原文与来源确认字符，不能无条件删除该符号。检测到 U+FFFD 可以作为排查线索，但合法原文也可能包含这个字符；严格无损归档需要更明确的源字节规则、映射范围与异常处置机制。

哪些文件需要额外的迁移约定

转换后需要再执行 string(raw) 吗？若已经得到 UTF-8 字节，可以转成 Go 字符串供文本逻辑使用；这一步只是字节与字符串的表示转换，真正的字符集解码发生在 Decoder。

输出可以直接覆盖源文件吗？本文方案刻意保留源文件，目标已存在就报错。编码不明或历史资料只有一份时，尤其需要先保留可恢复的来源。

所有错误都应删掉副本吗？本例清理转换或输出关闭失败产生的副本；若业务需要保留失败材料，应写到专门的隔离位置并记录状态，不让它进入正常消费目录。

对编码已确认的历史日文文本，我倾向于用独立副本把迁移影响控制在接入层；对来源混杂、要求逐字节无损或需要沿用旧字节索引的文件，则先补齐迁移约定，再执行转换。