Go x/text/encoding/transform.NewReader 怎样转换旧编码文本

转换已知旧编码文本时，把原始字节读取器和对应编码的 Decoder 交给 transform.NewReader，再从返回的 Reader 读取 UTF-8 内容即可。先澄清包路径：NewReader 位于 golang.org/x/text/transform；GBK 解码器位于 golang.org/x/text/encoding/simplifiedchinese，不存在需要导入的 golang.org/x/text/encoding/transform。

官方文档地址：https://pkg.go.dev/golang.org/x/text/transform。下面以接收一份已明确标注为 GBK 的历史目录文件为例，说明怎样控制输入量、处理读取错误，并保护原始内容。示例为原创写法，未在本文环境运行。

先确认编码来源与需要保护的数据

需要保护的资产有三项：原始字节、转换后的业务字段和处理程序的内存。编码选错时，程序可能得到看似合法的文字，却已经改变原意；无限制读取大文件，则可能耗尽内存。本文针对正常导入任务处理这些边界，不涉及自动猜测编码。

编码应由上游导出约定、文件元数据或明确的用户选择决定。文件扩展名不能证明编码是 GBK；“中文文件”也不能作为选择 GBK 的依据。若来源未知，应先补齐编码约定，避免对同一份内容轮流尝试解码器并随意接受其中一个结果。

输入若本来是 UTF-8，就不应再套用 GBK Decoder。转换失败也不应触发覆盖源文件。保留原始上传或原文件，可以在上游更正编码后重新处理。

把字节源与解码器组合起来

simplifiedchinese.GBK.NewDecoder() 提供 GBK 到 UTF-8 的转换器。transform.NewReader 用它包装一个 io.Reader；创建包装器不等于整个文件已经转换完毕，真正的读取与转换发生在下游消费时。

Reader 内部需要保存转换状态，以处理输入分块和跨块字符。NewReader 会重置传入的转换器，因此每条独立输入流都应创建自己的 Decoder。不要把同一个 Decoder 同时交给多个 Reader 使用，也不要在仍在读取时把它重置。

Reader 包装器没有替你接管底层文件的关闭责任。直接包装文件时，仍应由打开文件的代码关闭它。下面为了让输入上限与输出上限都清晰，先有界读取源文件，再用 bytes.Reader 展示转换。

用有界读取转换一份GBK文件

示例把原始输入上限设为 4 MiB、解码输出上限设为 12 MiB。这两个数字只是本例业务策略，不是 GBK 或库本身的固定要求。读取时多取一个字节，用来区分“恰好达到上限”和“超过上限”；超限数据整体拒绝，不截断后继续当作完整文件。

package main

import (
    "bytes"
    "fmt"
    "io"
    "os"

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

func readGBKFile(path string) ([]byte, error) {
    const inputLimit int64 = 4  inputLimit {
        return nil, fmt.Errorf("原始文件超过输入上限")
    }

    // 每个输入创建独立解码器，输出统一为 UTF-8。
    reader := transform.NewReader(bytes.NewReader(raw),
        simplifiedchinese.GBK.NewDecoder())
    decoded, err := io.ReadAll(io.LimitReader(reader, outputLimit+1))
    if err != nil {
        // 本例选择整份失败，不把部分结果交给业务层。
        return nil, fmt.Errorf("转换GBK文本: %w", err)
    }
    if int64(len(decoded)) > outputLimit {
        return nil, fmt.Errorf("解码文本超过输出上限")
    }
    return decoded, nil
}

func main() {
    if len(os.Args) != 2 {
        fmt.Fprintln(os.Stderr, "请提供一个GBK文本文件")
        os.Exit(2)
    }
    text, err := readGBKFile(os.Args[1])
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
    // 不打印文件正文，避免把敏感字段写入日志。
    fmt.Printf("转换完成，UTF-8字节数: %d\n", len(text))
}

代码依赖 golang.org/x/text 模块。应在已有 Go module 中，按项目 Go 工具链与依赖管理规则选择兼容版本并锁定，不必为了这个示例盲目升级全部依赖。自行准备确认为 GBK 的测试文件后，将文件路径作为程序参数传入即可。

这份写法会同时持有原始字节和转换后的字节，所以它适合有明确大小上限的导入任务。面对大文件，可以让 transform.Reader 直接连接流式解析器或受控写入目标，但仍需设计字节总量、字段长度与任务取消规则，不能把“分块读取”误认为“所有资源消耗都有界”。

把转换成功与内容可信分开判断

解码器对部分无法解码的输入可能采用 Unicode 替换字符，因此不能把没有返回错误理解为“每一个原始字节都严格合法”，也不能据此证明选中了正确编码。若业务要求严格拒绝非法输入，需要明确所用编码与解码器的处理规则，再设计相应策略。

转换后的 UTF-8 文本仍属于外部输入。目录编号、金额、日期或资源路径要交给相应业务解析器处理；展示到 HTML 时仍需要正确转义。编码转换不会清除脚本、修复错误业务字段，也不会授予内容任何可信身份。

保留必要记录并处理常见问题

生产导入记录可包含任务标识、声明编码、输入字节数、输出字节数、成功状态与错误类别。尽量避免把完整正文、个人信息或本机绝对路径写进共享日志。失败任务保留原始来源与编码说明，能够帮助复现问题，也避免在错误编码上反复覆盖数据。

NewReader 会自动识别 GBK 和 GB18030 吗？

不会。它使用调用者传入的 Transformer。GBK 与 GB18030 是包中不同的编码对象，应依据真实来源选择；不能仅凭两者都支持中文就随意互换。

每次读取的字节块会不会把一个汉字切开？

底层读取可能在字符中间分块，transform.Reader 的职责之一就是协调转换器与输入缓冲。使用 Reader 接口即可，不要自己把任意字节块当成完整文本分别创建 Decoder。

string(raw) 能代替解码吗？

不能。将字节切片转换成 Go 字符串只是取得相同字节内容的字符串表示，不会把 GBK 字节变为对应的 UTF-8 字节。字符解释仍需正确的 Decoder。

转换后可以直接覆盖原文件吗？

本文示例只读取并返回新内容。需要持久化时，应明确目标编码、写入失败处理和替换策略，在新内容完整生成之前保留原件。单纯使用 NewReader 不会改写源文件。

相关官方接口还可查阅 encoding 解码器文档与 简体中文编码文档。