Go x/text/encoding/korean EUCKR 怎样读取旧韩文文本

读取旧韩文文本时，最容易犯的错误是把文件字节直接转换成 Go 字符串。Go 字符串保存的是字节序列，只有当输入本来就是 UTF-8 时，直接转换才会得到预期文字；EUC-KR 或 CP949 文件需要先经过字符集解码。

这篇文章使用 golang.org/x/text/encoding/korean 的 korean.EUCKR，再用 transform.NewReader 把解码器接到普通的 io.Reader 上。官方资料显示，EUCKR 表示 EUC-KR，也称 Code Page 949。

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

最小可用写法是：打开旧文件，把它包装为 transform.NewReader(file, korean.EUCKR.NewDecoder())，然后读取包装后的 Reader。小文件可使用 io.ReadAll，大文件应直接把解码后的 Reader 流式复制到输出端。

EUCKR 解码器到底接在哪一层

korean.EUCKR 是一个编码对象，NewDecoder() 返回把 EUC-KR 字节转换为 Unicode 文本的转换器。它本身不是文件读取器，所以不能替代 os.Open；文件仍然由 *os.File 提供字节输入。

transform.NewReader 则负责把转换器接入读取链路。它包装一个 io.Reader，调用包装后的 Read 时，才会把读到的源字节转换为输出字节。这种组合让同一套解码逻辑既能服务文件，也能服务网络响应或内存缓冲区。

小文件用最小代码读成 UTF-8

配置文件、短消息和单份历史记录通常可以一次性读入内存。关键点有三个：把解码器挂在原始文件上、检查每一次可能失败的调用、关闭的是原始文件而不是包装 Reader。

package main

import (
    "fmt"
    "io"
    "os"

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

func readEUCKR(path string) (string, error) {
    // 文件只负责提供原始 EUC-KR 字节，关闭它可以释放操作系统文件描述符。
    file, err := os.Open(path)
    if err != nil {
        return "", fmt.Errorf("打开旧韩文文件: %w", err)
    }
    defer file.Close()

    // 解码器把 EUC-KR/CP949 字节转换成可供 Go 字符串使用的 UTF-8 字节。
    decoded := transform.NewReader(file, korean.EUCKR.NewDecoder())
    data, err := io.ReadAll(decoded)
    if err != nil {
        return "", fmt.Errorf("读取并解码 EUC-KR 文件: %w", err)
    }
    return string(data), nil
}

func main() {
    // 示例只展示调用方式，不把文件路径、内容或输出结果写死在函数内部。
    text, err := readEUCKR("legacy-korean.txt")
    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Print(text)
}

这里的 string(data) 发生在解码之后，因此得到的是 UTF-8 字节组成的 Go 字符串。若把它提前到 os.ReadFile 返回之后，得到的只是未经转换的原始字节，显示结果就可能出现乱码。

大文件改用流式复制

io.ReadAll 的优点是使用简单，代价是解码后的完整内容会同时留在内存中。面对几十 MB 甚至更大的归档文本，通常只需要把结果写入另一个文件、压缩流或 HTTP 响应，此时可以让解码后的 Reader 直接参与 io.Copy。

func convertEUCKR(srcPath, dstPath string) error {
    // 源文件提供 EUC-KR 字节，目标文件保存转换后的 UTF-8 字节。
    src, err := os.Open(srcPath)
    if err != nil {
        return fmt.Errorf("打开源文件: %w", err)
    }
    defer src.Close()

    dst, err := os.Create(dstPath)
    if err != nil {
        return fmt.Errorf("创建目标文件: %w", err)
    }
    defer dst.Close()

    // transform.Reader 按需解码，io.Copy 不要求先把完整文本装入内存。
    decoded := transform.NewReader(src, korean.EUCKR.NewDecoder())
    if _, err := io.Copy(dst, decoded); err != nil {
        return fmt.Errorf("转换并写出 UTF-8 文件: %w", err)
    }
    return nil
}

这个版本的内存占用主要由内部缓冲和 io.Copy 的复制缓冲决定，而不是由源文件总大小决定。目标文件创建成功后，如果中途转换失败，调用方还应根据业务决定是否删除不完整的目标文件；示例保留错误，让上层统一处理。

错误处理要分清三个位置

读取旧编码文件时，错误不只来自“文件有没有打开”。可以按下面三个位置判断：

还要注意，transform.Reader 是读取包装器，不等于一个新的文件句柄。真正需要关闭的是实现了 io.Closer 的源文件或目标文件。把 Close 写在原始文件变量上，资源归属会更清楚。

用指标决定整读还是流式

为了保持实现可维护，可以先记录三项指标：输入文件大小、峰值内存和处理耗时。小配置文件采用 io.ReadAll，代码短、后续解析方便；大文本采用 io.Copy 或逐块读取，峰值内存更稳定；需要按行处理时，再在解码后的 Reader 上接入扫描逻辑。

不要把“用了转换器”误认为“必然更慢”或“必然占用固定内存”。实际成本取决于读取块大小、输出端速度和后续解析方式。文章中的两张图只表达静态组件关系，不代表某次本机执行结果。

常见误区与边界

• 误区一：直接 string(raw)。这只改变 Go 对字节的承载方式，不会把 EUC-KR 转换成 UTF-8。
• 误区二：把 EUCKR 当作文件扩展名。编码由内容约定决定，文件名后缀不能代替编码判断。
• 误区三：每次读取都新建不必要的整份缓冲。可直接把解码 Reader 交给 io.Copy，把内存压力留在可控范围。
• 误区四：只检查最后一行输出。应保留打开、读取转换和关闭阶段的错误上下文，避免坏文件被当作成功结果。

如果输入实际上是 UTF-8，就不应套用 EUCKR 解码器；如果来源明确标注为另一种韩文编码，也应先确认对应的转换器，而不是仅凭“看起来像韩文”选择方案。

一张表记住选择

归根结底，Go 读取旧韩文文本的关键不是把某个字符串函数换成另一个字符串函数，而是把正确的编码转换器放在 Reader 链路中。先确认来源确实是 EUC-KR/CP949，再根据数据规模选择整读或流式处理，就能把乱码、内存和资源释放问题分开处理。

相关问题

EUCKR 和 UTF-8 可以直接互换吗？

不能直接互换。需要通过解码器把源字节转换成 Unicode 文本，再由 Go 字符串或输出端以 UTF-8 形式承载。

transform.NewReader 会自动关闭 os.File 吗？

不要把包装器当作文件所有者。应保留并关闭原始的 *os.File；这样资源归属更明确。

旧韩文文件很大时还能使用 io.ReadAll 吗？

可以，但要把完整解码结果纳入内存预算。若目标是转换、转发或落盘，优先把解码后的 Reader 交给 io.Copy。