Go 怎么把带 BOM 的 UTF16 文件转成 UTF8

Go 标准库没有直接把 UTF-16 文件转换为 UTF-8 的高层函数。处理带 BOM 的 UTF-16 文件时，可以使用 golang.org/x/text/encoding/unicode 识别 UTF-16LE/BE，再通过 transform.Reader 流式写出 UTF-8。关键不是手动猜两个字节，而是让 BOM 决定字节序，并把输出先写到临时文件。

最小可靠方案是：用 unicode.BOMOverride 识别 BOM，用 io.Copy 边读边转码；复制、关闭都成功后，再用同目录临时文件替换正式 UTF-8 文件。

先让 BOM 决定 UTF-16 的字节序

UTF-16 的一个字符通常由两个字节单元组成，LE 和 BE 的排列不同。带 BOM 的文件已经把这个信息放在开头，因此解码器不应该固定写成“大端”或“小端”后直接读取。unicode.UTF16 接收默认字节序与 BOM 策略；BOMOverride 再把文件开头的 BOM 作为更优先的判断依据。

用 transform.Reader 流式转成 UTF-8

先引入依赖：go get golang.org/x/text。下面的函数默认“没有 BOM 时按 UTF-16LE 回退”，适合来源协议明确或历史文件基本都是小端的场景；如果来源必须有 BOM，把回退策略换成 ExpectBOM 并单独处理 unicode.ErrMissingBOM。

package convert

import (
    "fmt"
    "io"
    "os"
    "path/filepath"

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

func UTF16ToUTF8(srcPath, dstPath string) error {
    src, err := os.Open(srcPath)
    if err != nil {
        return fmt.Errorf("open UTF-16 source: %w", err)
    }
    defer src.Close() // 源文件只负责读取，函数结束时释放文件描述符。

    // 同目录创建临时文件，成功后再替换正式输出，避免半成品可见。
    tmp, err := os.CreateTemp(filepath.Dir(dstPath), ".utf8-*.tmp")
    if err != nil {
        return fmt.Errorf("create UTF-8 temp file: %w", err)
    }
    tmpPath := tmp.Name()
    defer os.Remove(tmpPath) // 任一步失败都清理临时文件。

    // BOM 优先识别 UTF-16LE/BE；无 BOM 时回退到小端解码。
    fallback := unicode.UTF16(unicode.LittleEndian, unicode.IgnoreBOM).NewDecoder()
    decoder := unicode.BOMOverride(fallback)
    reader := transform.NewReader(src, decoder)

    // 流式转换，适合不应一次性读入内存的文件。
    if _, err := io.Copy(tmp, reader); err != nil {
        _ = tmp.Close()
        return fmt.Errorf("convert UTF-16 to UTF-8: %w", err)
    }
    if err := tmp.Close(); err != nil {
        return fmt.Errorf("close UTF-8 temp file: %w", err)
    }
    if err := os.Rename(tmpPath, dstPath); err != nil {
        return fmt.Errorf("replace UTF-8 output: %w", err)
    }
    return nil
}

transform.NewReader 返回一个包装后的读取器，调用 io.Copy 时才持续消耗并转换输入。这样既不用自己切分 UTF-16 字节，也不会因为一次 os.ReadFile 把大文件整体搬进内存。

为什么要先写临时文件再替换

如果直接用 os.Create(dstPath)，程序在转换到一半退出，旧文件可能已经被截断。把临时文件放在目标文件同一目录，再在关闭成功后调用 os.Rename，可以把“完整输出可见”推迟到最后一步。目标目录必须提前存在；多个 goroutine 同时处理同一个目标时，还要在调用方按路径加锁。

如果目标文件原本不存在，重命名就是首次创建；如果目标文件已存在，则应结合系统平台、权限和业务并发策略确认替换语义。文章中的方法解决的是单次转换的文件完整性，不等于替代多进程锁或事务协调。

缺少 BOM 或出现乱码时怎么判断

严格输入可以改用：

// 来源协议要求 BOM 时，缺少 BOM 就让调用方知道输入不合约。
decoder := unicode.UTF16(unicode.LittleEndian, unicode.ExpectBOM).NewDecoder()

ExpectBOM 没看到开头 BOM 会返回 ErrMissingBOM；IgnoreBOM 则不会让 BOM 改变字节序。若文件没有 BOM，且你也不知道它是 LE 还是 BE，程序无法从普通字节可靠推断编码，应回到文件来源、协议字段或人工确认，而不是不断切换大小端直到“看起来像中文”。

出现乱码时优先检查三件事：BOM 是否被误当作正文、默认字节序是否和无 BOM 文件的实际字节序一致、源文件是否在中间被截断。转换器输出的是 UTF-8 字节，写出后再由下游按 UTF-8 打开，不要在后面重复做一次“UTF-8 转 UTF-8”。

常见问题

Go 能不能只用标准库转换 UTF-16？

标准库提供 UTF-8 字符串与字节处理，但没有同等高层的 UTF-16 文件解码器。通常使用 golang.org/x/text/encoding/unicode 与 transform。

为什么不用手动删除前两个字节？

删除 BOM 只能去掉标记，不能解决 UTF-16LE/BE 的字节序，也不能处理代理项和流式边界。应让 Unicode 解码器完成转换。

没有 BOM 的 UTF-16 文件能自动判断吗？

不能保证。没有 BOM 时必须依赖来源协议或明确的外部元数据；代码只能选择约定好的回退字节序，并对不符合约定的输入报错。

转换失败会不会破坏旧文件？

按本文的同目录临时文件方案，复制或关闭失败时只会删除临时文件，正式目标不会在最后替换前被覆盖。

相关资料：unicode 包文档、transform 包文档。