Go x/text/encoding/unicode/utf32 ExpectBOM 与 IgnoreBOM 为什么结果不同

这两个策略的差异不在名字，而在输入契约：ExpectBOM 把起始 BOM 当成必需的协议标记，IgnoreBOM 则认为字节序已经由调用方确定。前者遇到无 BOM 数据会返回 utf32.ErrMissingBOM，后者不会因为缺少 BOM 报错；如果输入实际带 BOM，后者还可能把它保留成字符串开头的 U+FEFF。

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

先分清两种 BOM 策略的输入契约

UTF32(e, b) 的第一个参数是默认字节序，第二个参数是 BOM 策略。LittleEndian 表示没有 BOM 时按 UTF-32LE 解释，BigEndian 则表示 UTF-32BE。这里没有“跟随本机 CPU”的 native endian 选项，协议必须自己说明数据如何排列。

用解码路径判断为什么输出不同

假设输入是 UTF-32LE，开头四个字节为 FF FE 00 00，后面是字符 A。使用 utf32.UTF32(utf32.LittleEndian, utf32.ExpectBOM) 时，解码器先消费这四个 BOM 字节，再输出 A；如果改成 IgnoreBOM，它不会把这四个字节当成控制标记，而会按小端解出 U+FEFF，结果相当于 \uFEFFA。

反过来，输入没有 BOM 时，IgnoreBOM 能按已知的 LittleEndian 继续解码，而 ExpectBOM 会在转换早期返回 ErrMissingBOM。这就是“同一段字节结果不同”的根因：一个策略把 BOM 当协议元数据，另一个策略把它视为数据内容。

用 Go 代码处理有 BOM 与无 BOM 数据

实际读取流时，可以把编码器交给 transform.NewReader，并单独处理缺失 BOM。下面的示例只展示解码边界；输入字节是人为构造的 UTF-32LE 数据，不代表运行截图。

package main

import (
    "bytes"
    "errors"
    "fmt"
    "io"

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

func decode(label string, enc encoding.Encoding, data []byte) {
    // 每次读取一条独立数据流，创建新的 Reader，避免复用转换状态。
    reader := transform.NewReader(bytes.NewReader(data), enc.NewDecoder())
    text, err := io.ReadAll(reader)
    if errors.Is(err, utf32.ErrMissingBOM) {
        // 协议要求 BOM 但数据缺失时，转成可识别的业务错误。
        fmt.Printf("%s: missing BOM\\n", label)
        return
    }
    if err != nil {
        fmt.Printf("%s: decode error: %v\\n", label, err)
        return
    }
    fmt.Printf("%s: %q\\n", label, string(text))
}

func main() {
    // 这里用显式字节构造 UTF-32LE 的 BOM、A；注释说明每四字节一个码元。
    withBOM := []byte{0xff, 0xfe, 0x00, 0x00, 0x41, 0x00, 0x00, 0x00}
    withoutBOM := withBOM[4:]
    expect := utf32.UTF32(utf32.LittleEndian, utf32.ExpectBOM)
    ignore := utf32.UTF32(utf32.LittleEndian, utf32.IgnoreBOM)
    decode("ExpectBOM + BOM", expect, withBOM)
    decode("IgnoreBOM + BOM", ignore, withBOM)
    decode("ExpectBOM - BOM", expect, withoutBOM)
    decode("IgnoreBOM - BOM", ignore, withoutBOM)
}

示例中需要补充 bytes 导入；它的作用只是把内存字节接成 io.Reader。在文件场景中可直接把 os.File 传给 transform.NewReader，不要为了“兼容两种模式”先手动删除 BOM，否则 ExpectBOM 的协议检查就失去意义。

按生产协议选择并检查编码方向

如果上下游协议明确写着“必须以 BOM 开头”，编码端和解码端都使用 ExpectBOM，这样缺失标记会尽早失败；它还能根据 BOM 在 UTF-32BE 与 UTF-32LE 之间选择实际字节序。若文件格式已经固定为 UTF-32LE 或 UTF-32BE，且 BOM 不属于内容格式，就使用对应默认字节序配合 IgnoreBOM。

不要把 IgnoreBOM 当成“自动识别 BOM”。它既不会用 BOM 改变大小端，也不会自动删掉开头的 U+FEFF。需要同时兼容“有 BOM 和无 BOM”的不稳定上游时，先在协议层决定容错策略，再明确记录实际字节序；否则同一文件在不同调用方之间会出现隐形首字符或乱码。

相关问题

ExpectBOM 能否解码没有 BOM 的 UTF-32 文件？

不能。它会返回 utf32.ErrMissingBOM；如果业务允许无 BOM 文件，应选用已知字节序的 IgnoreBOM，或在协议层先补齐明确规则。

IgnoreBOM 为什么结果开头多了不可见字符？

带 BOM 的输入被按普通 UTF-32 码元解码成 U+FEFF，它在 UTF-8 字符串中通常不可见，但会影响长度、比较和首字段解析。

编码时两种策略有什么差异？

ExpectBOM 会在输出开头写入 BOM，IgnoreBOM 不写入；UTF-8 输入本身不需要先带 BOM。