Go x/text/encoding/unicode/utf32 UTF32 怎样解码小端字节流

Go 解码已知为 UTF-32LE 的字节流，可以使用 utf32.UTF32(utf32.LittleEndian, utf32.IgnoreBOM).NewDecoder()，再用 transform.NewReader 包装输入，得到 UTF-8 Reader。如果允许文件开头的 BOM 决定字节序，应改用 UseBOM；这时 LittleEndian 只是没有 BOM 时的默认值。

官方文档入口：https://pkg.go.dev/golang.org/x/text/encoding/unicode/utf32。我会把 UTF-32 放在旧文件或设备数据的接入边界，内部文本仍使用 UTF-8，避免把外部格式传递到所有业务模块。

小端约定应落在解码边界

处理大文件时，原始字节、转换结果、业务缓冲区同时驻留内存，是我会首先避免的结构。直接执行 string(raw) 也不能完成转码：Go 字符串可以装任意字节，并不会因为变量是 string 就把四字节编码解释成字符。

我的选择是让“输入契约”持有小端与 BOM 约定，让“解码边界”创建当前流专用的 Decoder，让“业务消费者”只依赖 UTF-8 Reader。这种拆分把编码知识集中在一个地方，但并不自动带来性能提升；本文没有压测或上线结果。

图中包含输入契约、小端参数、BOM 策略、UTF32 配置、Decoder、业务消费者六个对象。小端参数与 BOM 策略共同决定 UTF32 配置，配置提供 Decoder；业务消费者通过解码边界获得 UTF-8，而不接触原始编码规则。

先把 BOM 策略选清楚

最容易踩坑的是把 IgnoreBOM 理解成“剥掉 BOM”。官方文档的实际语义是：BOM 不改变解码字节序，解码出的 U+FEFF 仍可以出现在 UTF-8 输出中。需要消费开头 BOM 的行为，应根据协议选择 UseBOM 或 ExpectBOM。

因此，协议明确规定“小端且不使用 BOM”时，我会用 IgnoreBOM；协议允许带 BOM 的文件时，可以选 UseBOM；协议强制 BOM 时，用 ExpectBOM。UseBOM 和 ExpectBOM 都可能接受开头标记的大端输入，不能把它们称为“严格只接受小端”。如果业务要求遇到大端 BOM 必须拒绝，需要在接入层额外落实这一契约。

这些参数含义来自 UTF32 函数说明。后续位置出现的 BOM 不会重新切换字节序；不要把拼接的多个独立文件当成一个可自动切换编码的流。

用 Reader 组合解码大输入

下面的函数接受输入 Reader、UTF-8 输出 Writer 和 BOM 策略。它只负责转码，输入与输出资源由调用方拥有；调用方打开文件后仍需关闭文件，使用带缓冲的 Writer 时仍需 Flush。

package textinput

import (
    "fmt"
    "io"

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

// DecodeLE 把默认小端的 UTF-32 输入转为 UTF-8 输出。
// policy 决定是否允许开头 BOM 覆盖小端约定。
func DecodeLE(dst io.Writer, src io.Reader, policy utf32.BOMPolicy) error {
    // 每个独立输入创建新解码器，避免共享流状态。
    decoder := utf32.UTF32(utf32.LittleEndian, policy).NewDecoder()
    decoded := transform.NewReader(src, decoder)
    // io.Copy 持续读取转换后的字节；失败时 dst 可能已有部分输出。
    if _, err := io.Copy(dst, decoded); err != nil {
        return fmt.Errorf("解码 UTF-32 字节流: %w", err)
    }
    return nil
}

调用时，固定无 BOM 的小端输入传 utf32.IgnoreBOM；允许可选 BOM 则传 utf32.UseBOM。不要根据 CPU 是什么架构选择参数，文档明确没有“本机字节序”这一默认约定。依赖版本由项目 go.mod 固定到与工具链兼容的版本。

Reader 包装可以处理底层 Read 把一个四字节编码单元分成多次返回的情况，无需调用方按每次 Read 的长度自行切四字节。这是使用流式转换器的理由；如果输入在文件结尾真的缺少字节，它与正常的分块读取是不同的问题。

我会怎样处理失败和部分输出

这张图把输入 Reader、输出 Writer、Decoder、transform.Reader、io.Copy、部分输出六个节点分到“调用方资源”和“转换组件”两组。transform.Reader 包装输入并持有解码器，io.Copy 依赖转换 Reader 与输出 Writer，输出 Writer 可能包含部分输出。

io.Copy 返回错误不代表目标一定为空。若文件必须全部成功后才能被下游看见，我会先写临时目标，再由业务层在成功关闭、完成必要提交条件后替换正式文件；数据库写入则使用相应事务。这个代价是多一层提交与清理逻辑，不能只在错误分支打印一句日志就视为原子导入。

另外，Decoder 文档说明不符合编码的输入可以被替换成 U+FFFD，而不一定报错。没有错误不等于字符完全保真。对需要严格无损的导入，还要单独定义无效码点、截断输入与源字节保留策略；不要仅检查输出是否为有效 UTF-8 就宣布源 UTF-32 合法。

接入前还要问清哪些问题

没有 BOM 就不能解码吗？可以，只要外部协议已规定小端，IgnoreBOM 或 UseBOM 都可按默认小端继续。ExpectBOM 专用于要求开头标记的契约。

为什么输出开头还有不可见字符？先看是否使用 IgnoreBOM，它不会替你消费开头 U+FEFF。修改策略前要确定该字符是编码标记还是业务数据，不能对所有文本无条件删除。

流式方式就不会占用大量内存吗？Reader 组合避免了函数主动读取整个输入，但输出若是 bytes.Buffer，或业务消费者仍做 ReadAll，整体仍可能累积全量内容。资源限制需要结合实际消费者设置。

我会优先把这套做法用于输入编码明确的遗留文件接入。官方包也提示 UTF-32 较少见且效率不高；新文本接口没有兼容约束时，应先考虑 UTF-8。这里提供的是实现示例与设计取舍，没有声称已在本地运行。