Go x/text/encoding/korean NewEncoder 怎样生成韩文编码输出

我第一次把 Go 服务里的韩文数据交给旧系统时，最容易犯的错是把“编码输出”和“解码输入”混在一起。golang.org/x/text/encoding/korean 的 EUCKR.NewEncoder() 负责的方向很明确：接收 Go 字符串通常承载的 UTF-8，生成 EUC-KR 字节。需要转换回 Go 文本时才使用 NewDecoder()。

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

NewEncoder 的方向先弄清：UTF-8 进，EUC-KR 出

这个 API 的关键不是“创建一个韩文字符串”，而是给已有的 UTF-8 内容选择输出字符集。korean.EUCKR 实现了通用的 encoding.Encoding 接口，调用 NewEncoder 得到编码器；编码结果应当被当作字节流交给文件、Socket 或旧协议。

用 String 或 Bytes 生成一次性韩文编码输出

如果输入是 Go 的 string，优先从 String 开始。它返回一个字符串类型的结果，但其中的内容应当按目标编码的字节解释，而不是继续当作 UTF-8 文本处理。落盘或发送时转换成 []byte 即可。

package main

import (
    "fmt"
    "log"

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

func main() {
    source := "안녕하세요"

    // NewEncoder 的输入是 UTF-8，输出是 EUC-KR 字节。
    encoded, err := korean.EUCKR.NewEncoder().String(source)
    if err != nil {
        // 不支持的字符不能静默写入，交给调用方决定是否降级。
        log.Fatal(err)
    }

    // 用十六进制观察字节，避免把 EUC-KR 误当成 UTF-8 打印。
    fmt.Printf("% x\n", []byte(encoded))
}

输入本来就是 []byte 时使用 Bytes，但这些字节必须先确认是合法 UTF-8。编码器遇到不能转换的字符会返回错误，并且不会把完整结果当作成功值交给你；这比生成一份看似完整、实际已经丢字的文件更容易排查。

不支持字符与 Writer 复用是两个边界

EUC-KR 的字符集合不是全部 Unicode。韩文业务字段里混入 emoji、特殊符号或其他语言字符时，String 与 Bytes 应保留错误分支。确实要兼容某个旧表单时，可以了解 encoding.HTMLEscapeUnsupported 或 ReplaceUnsupported，但官方文档明确提醒后者主要用于兼容旧场景；如果协议允许，UTF-8 通常更稳妥。

需要连续写入时，可把编码器绑定到目标 io.Writer：

package main

import (
    "io"
    "os"

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

func writeLegacyText(w io.Writer, text string) error {
    // Writer 会把后续 UTF-8 写入转换成 EUC-KR 后交给 w。
    encoder := korean.EUCKR.NewEncoder()
    encodedWriter := encoder.Writer(w)

    // 这里示范一次写入；真实项目仍要检查写入错误。
    _, err := encodedWriter.Write([]byte(text))
    return err
}

func main() {
    // 示例只展示调用关系，生产代码应按文件生命周期处理关闭与落盘错误。
    _ = writeLegacyText(os.Stdout, "안녕하세요")
}

同一个 Encoder 在返回的 Writer 仍然使用时不要再调用 String 或 Bytes。我更倾向于按一次输出任务创建一个编码器，这样对象状态与下游 Writer 的生命周期清晰，排查“偶尔乱码”时也少一层共享状态。

落地前的 EUC-KR 输出检查清单

1. 确认接收端要求的是 EUC-KR，而不是 UTF-8、CP949 的其他兼容约定。
2. 确认输入来自 UTF-8 字符串或合法 UTF-8 字节，不把已经编码过的字节再次编码。
3. 所有 String、Bytes、Write 都保留错误检查，并记录具体业务字段。
4. 用接收端真实解析器抽查韩文、ASCII、标点和不支持字符四种数据。

这样使用 NewEncoder 的重点就落在接口契约上：方向正确、错误可见、Writer 生命周期不交叉。旧系统必须用 EUC-KR 时它很实用；新接口若没有兼容压力，直接统一 UTF-8 会少一次转换。

相关问题

korean.EUCKR.NewEncoder 可以把 EUC-KR 字节转回字符串吗？

不能。它是 UTF-8 到 EUC-KR 的编码器；要把旧字节读成 Go 文本，应使用 korean.EUCKR.NewDecoder()。

遇到 emoji 时可以自动替换吗？

默认应先处理错误。只有下游协议明确允许替换或 HTML 转义时，才考虑对应包装器，并接受信息可能损失的代价。

为什么输出结果在终端看起来是乱码？

终端通常按 UTF-8 解读字节。先用十六进制或让明确支持 EUC-KR 的接收端读取，不能把终端显示异常直接判断为编码失败。