Go x/text/encoding/unicode ExpectBOM 为什么拒绝没有签名的文本

如果一个 UTF-16 文件没有开头的 BOM，却使用 unicode.UTF16(..., unicode.ExpectBOM) 解码，返回 encoding: missing byte order mark 是预期行为，不是普通的字符乱码。ExpectBOM 把 BOM 当成输入协议的一部分：它既用 BOM 判断 UTF-16BE/UTF-16LE，也要求输入必须提供这个标记；缺少标记就返回 unicode.ErrMissingBOM。

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

先把 BOM、端序和文本内容分开

UTF-16 的一个代码单元通常占两个字节，但这两个字节的排列有大端和小端之分。BOM 是放在输入开头的一段特殊标记：FE FF 表示 UTF-16BE，FF FE 表示 UTF-16LE。它不是要显示给用户的正文字符，而是帮助解码器确定后续字节如何解释。

因此，ExpectBOM 检查的不是“文件是否为空”，而是“UTF-16 输入开头是否有可识别的 BOM”。文件可能有正文、长度也正常，只要开头没有 BOM，严格策略仍然会拒绝它。相反，使用 IgnoreBOM 时，解码器会按照传入的默认端序处理数据，不会让 BOM 改变端序。

三种 BOMPolicy 的差异不在名字，而在读写方向

BOMPolicy 同时影响解码和编码，不能只记住“有没有 BOM”。解码是 UTF-16 字节转 UTF-8；编码是 UTF-8 转 UTF-16 字节。下面的对照表把两个方向分开：

如果输入来自一个明确规定“必须带 BOM”的协议，ExpectBOM 能把格式错误尽早暴露出来。如果文件来源复杂、历史数据可能没有 BOM，则应该先确认默认端序，再考虑 UseBOM 或显式的兼容分支，而不是把所有输入都当成严格格式。

没有 BOM 时，为什么会得到 ErrMissingBOM

下面的例子构造一段没有 BOM 的 UTF-16LE 字节。ExpectBOM 不会猜测端序，也不会因为正文看起来像正常文本就放行；它在读取开头时就返回错误：

package main

import (
    "errors"
    "fmt"

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

func main() {
    // 这段数据是 UTF-16LE 的“Go”，故意省略 FF FE 起始 BOM。
    rawWithoutBOM := []byte{0x47, 0x00, 0x6f, 0x00}

    // ExpectBOM 要求输入先给出 BOM，缺失时应把它视为格式错误。
    decoder := unicode.UTF16(unicode.LittleEndian, unicode.ExpectBOM).NewDecoder()
    text, err := decoder.Bytes(rawWithoutBOM)
    fmt.Printf("text=%q err=%v\n", string(text), err)

    // 用 errors.Is 识别包提供的哨兵错误，避免只比较易变的错误文本。
    fmt.Println("missing BOM:", errors.Is(err, unicode.ErrMissingBOM))
}

这里的重点不是把错误文本打印出来，而是保留 ErrMissingBOM 这个可识别的错误语义。上层可以据此区分“输入格式不符合严格协议”和“其他读取或转换失败”，决定是拒绝、补充来源信息，还是进入兼容策略。

带 BOM 的输入会如何选择大小端

同样的正文，如果在开头分别放入 FF FE 或 FE FF，UseBOM 和 ExpectBOM 都会让 BOM 覆盖传入的默认端序，并且不会把 BOM 输出成正文字符。下面用一段带 UTF-16LE BOM 的数据演示正常路径：

package main

import (
    "fmt"

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

func main() {
    // FF FE 表示 UTF-16LE；后面的两个代码单元组成“Go”。
    rawWithBOM := []byte{0xff, 0xfe, 0x47, 0x00, 0x6f, 0x00}

    // 默认端序即使写成 BigEndian，也会被输入中的 BOM 覆盖。
    decoder := unicode.UTF16(unicode.BigEndian, unicode.ExpectBOM).NewDecoder()
    text, err := decoder.String(string(rawWithBOM))
    if err != nil {
        // 转换失败时保留原始错误，避免把格式问题伪装成空字符串。
        panic(err)
    }
    fmt.Printf("%q\n", text)
}

这个例子说明了两个边界：默认端序不是最终决定，BOM 才是带 BOM 输入的权威信息；但如果 BOM 完全不存在，ExpectBOM 仍不会替你猜测。

把 Decoder 接到文件或网络流

数据已经完整放在内存中时，可以使用 Bytes 或 String。文件、HTTP 响应和管道通常是流，此时应该把 NewDecoder 交给 transform.NewReader，让读取过程持续输出 UTF-8：

package main

import (
    "bytes"
    "fmt"
    "io"

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

func decodeUTF16(r io.Reader) (string, error) {
    // 严格协议使用 ExpectBOM：没有签名时让调用方看到 ErrMissingBOM。
    decoder := unicode.UTF16(unicode.LittleEndian, unicode.ExpectBOM).NewDecoder()
    // Reader 负责分块读取和转换，调用方只接收 UTF-8 字节。
    converted := transform.NewReader(r, decoder)
    data, err := io.ReadAll(converted)
    if err != nil {
        // 保留转换错误，便于上层区分格式失败与业务失败。
        return "", err
    }
    return string(data), nil
}

func main() {
    // 真实场景中这里可以换成 os.File 或 HTTP 响应体。
    raw := []byte{0xff, 0xfe, 0x47, 0x00, 0x6f, 0x00}
    text, err := decodeUTF16(bytes.NewReader(raw))
    if err != nil {
        panic(err)
    }
    fmt.Println(text)
}

transform.NewReader 不负责替你选择编码，它只负责把已经选好的 Decoder 接到 io.Reader。如果业务允许无 BOM 的历史文件，可以把策略换成 UseBOM，但还要确认 LittleEndian 或 BigEndian 的默认值确实符合来源协议。

编码方向也要记住：ExpectBOM 会写出 BOM

很多人只在读取时报错时关注 ExpectBOM，却忽略了它在编码方向也属于“写 BOM”的策略。UTF-8 文本经过 NewEncoder 转成 UTF-16 时，UseBOM 和 ExpectBOM 都会在输出开头插入 BOM；IgnoreBOM 则不会插入。

package main

import (
    "fmt"

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

func main() {
    // 编码器接收 UTF-8 文本，返回带 UTF-16 字节序的字符串容器。
    encoder := unicode.UTF16(unicode.LittleEndian, unicode.ExpectBOM).NewEncoder()
    encoded, err := encoder.String("Go")
    if err != nil {
        // 目标编码无法表示字符时，必须把错误交给调用方处理。
        panic(err)
    }
    fmt.Printf("% x\n", []byte(encoded))
}

编码与解码的“严格”含义不同：解码时 ExpectBOM 检查输入，编码时它保证输出带 BOM。要不要在输出中写 BOM，应由目标协议决定，而不是因为输入文件曾经带过 BOM 就机械复制。

实际项目里的判断顺序

1. 先看来源协议：确认数据是否规定 BOM，以及没有 BOM 时默认端序是什么。
2. 再选策略：协议强制 BOM 用 ExpectBOM；BOM 可选用 UseBOM；端序完全由外部约定时再考虑 IgnoreBOM。
3. 保留错误语义：用 errors.Is(err, unicode.ErrMissingBOM) 区分签名缺失，不要只依赖错误字符串。
4. 统一应用内部编码：尽早把输入转成 UTF-8，把原始 UTF-16 的端序和 BOM 处理限制在适配层。
5. 检查输出协议：编码时明确目标系统是否需要 BOM，避免让下游把 BOM 当成正文字符。

常见问题

ExpectBOM 只能用于 UTF-16 吗？

这里讨论的是 unicode.UTF16 返回的 UTF-16 编码对象及其 BOMPolicy。不要把这个策略名理解成对任意字符集都通用的输入探测器。

没有 BOM 时能不能自动猜端序？

ExpectBOM 不会猜。若业务允许无 BOM 输入，必须依据文件格式或来源协议明确默认端序，再使用 UseBOM 或 IgnoreBOM。

UseBOM 和 ExpectBOM 的最大区别是什么？

解码时，UseBOM 没有 BOM 也会按默认端序继续，ExpectBOM 没有 BOM 则返回 ErrMissingBOM；编码时两者都会写 BOM。

为什么不直接把原始字节转成 string？

Go 的 string 可以承载任意字节，但这不会完成 UTF-16 到 UTF-8 的字符转换。要得到可用的 UTF-8 文本，仍需先选择正确的 Encoding 和 Decoder。