Go x/text/encoding/unicode/utf32 四字节 UTF32 单元为什么仍可能无效

UTF-32 的一个编码单元虽然占四字节，但有效值只能是 Unicode 标量值：不得超过 0x10FFFF，也不得落在代理项区间 0xD800–0xDFFF。四字节可以表示远大于这个范围的整数，因此“长度完整”不能证明“编码有效”。另外，使用错误字节序也可能把正常字节解释成无效值。

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

四字节只保证单元长度，不保证数值有效

考虑一个历史数据导入任务：文件长度恰好是 4 的倍数，导入后却出现替换字符。若只检查长度，这个现象很难解释。问题在于长度检查只排除了尾部缺字节，没有判断每个 32 位整数能否对应 Unicode 标量值。

Unicode 为 UTF-32 定义的是一个标量值对应一个同数值的无符号 32 位单元。它不是“任意 uint32 都能直接转成字符”的约定。我会把单元完整性和标量范围分开记录，这样报错才能说明数据到底坏在哪一层。

区分字节序错误与非法标量值

这些是字节与数值的规则示例，不是运行输出。第四行说明：发现非法数值后，既要保留错误位置，也要核对输入协议声明的字节序，不能直接断定某个 Unicode 字符没有被支持。

反过来，错误字节序有时也可能得到落在有效范围内的另一个数值。所以“所有单元都合法”不能证明字节序一定选对；编码来源、协议约定和 BOM 策略仍是独立信息。

严格导入应在解码前检查原始单元

如果业务要求原始数据无损且必须拒绝非法单元，可以在转换前逐单元检查。下面只处理协议已经明确为小端的完整数据，不自动猜字节序。保留 uint32 值进行范围检查，可以避免先转换为有符号 rune 后丢失对原始数值的清楚描述。

package stricttext

import (
    "encoding/binary"
    "fmt"

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

// DecodeStrictLE 接受已明确为小端的完整 UTF-32 数据，BOM 不改变字节序。
func DecodeStrictLE(src []byte) (string, error) {
    if len(src)%4 != 0 {
        return "", fmt.Errorf("UTF-32 字节数 %d 不是 4 的倍数", len(src))
    }
    for offset := 0; offset  0x10FFFF || (value >= 0xD800 && value 

项目需要依赖 golang.org/x/text 模块，版本按项目约束确定。这个函数的错误位置是源字节偏移，不是第几个可见字符。它先检查完整输入，再解码，因此不会把遇到非法单元之前的部分文本当成成功结果返回。

示例使用 IgnoreBOM，意味着固定小端，并将 U+FEFF 作为内容保留。若协议要求起始 BOM 决定字节序，就应先按协议处理 BOM、确定有效字节序，再用同一解释规则检查后续单元；不能检查时固定小端，解码时却启用会改变字节序的策略。本文示例未运行，没有附带实际导入结果。

不要用替换字符反推原始数据

x/text 的 Decoder 会把不能按编码转换的数据替换为 U+FFFD，非法源数据本身不一定引发 error。因此只看 decoder.Bytes 返回错误是否为空，并不足以证明原始 UTF-32 严格有效。错误处理和数据合法性要求应在业务入口明确。

但反过来，输出出现 U+FFFD 也不能证明原文一定非法：U+FFFD 自身就是有效 Unicode 标量值，原始数据可以合法地包含它。解码后再扫描替换字符，无法总是区分“原文就有这个字符”和“解码器为非法输入补入这个字符”。

这里也不应把“未分配码点”“非字符”和“代理项”统称为非法 UTF-32。Unicode 标量值包含未分配码点与非字符；业务可以另有限制，但应单独说明，不能把更严格的业务白名单冒充编码本身的要求。

按输入协议保留失败位置

对于要求可靠导入的任务，我会保存输入来源、声明的字节序、BOM 策略、失败单元的字节偏移和数值。它们足以帮助定位“字节序选错”“尾部截断”“非法标量值”等问题，不必把整份文件内容写入日志。

流式读取还要区分当前缓冲区与最终输入。一次读取只拿到一到三个尾部字节，可能只是下一次读取尚未到达，不能立刻按文件截断处理。示例的长度检查仅适用于已经取得完整输入的函数入口。

严格编码检查也不等于业务内容一定安全或正确。控制字符、空字符、组合序列等可以是合法标量值；是否允许它们，应由文本用途决定。这里解决的是 UTF-32 单元合法性，不承诺任何通用的文本安全过滤效果。

常见问题：四字节长度完整为什么还无效？数值可能是代理项或超过上限。能把两个 UTF-16 代理项各自存进四字节吗？不能，它们在 UTF-32 中仍不合法，应先得到对应标量值。err 为 nil 是否证明输入合法？不证明默认替换策略没有发生。输出 U+FFFD 一定是坏数据吗？不一定，它可能来自原文。

参考：Unicode 核心规范第三章 UTF-32 定义；UTF-32 字节序与 BOM 策略；Decoder 的替换行为。