Go x/text/runes ReplaceIllFormed 为什么修改无效 UTF8

runes.ReplaceIllFormed() 的目的就是把不属于有效 UTF-8 序列的输入字节替换成 utf8.RuneError，即 U+FFFD。所以输出字节发生变化是预期行为，不是无损解码。若希望拒绝坏数据，应在原始输入上检查有效性；若希望恢复 GBK、Shift JIS 等其他编码，应先依据已知编码解码，不能用这个函数猜测原文。

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

先用最小写法区分原始字节与显示文本

下面的封装保留独立的原始字节副本，同时生成用于显示的字符串。它还记录原始输入是否有效、输出字节是否发生变化，让调用方自行决定接受、拒绝或提示用户。

package displaytext

import (
    "bytes"
    "unicode/utf8"

    "golang.org/x/text/runes"
)

type Prepared struct {
    Raw           []byte
    Display       string
    OriginalValid bool
    Changed       bool
}

// Prepare 完整接收一条数据后，保留原始副本并生成可显示文本。
func Prepare(input []byte) Prepared {
    raw := append([]byte(nil), input...)
    // ReplaceIllFormed 替换非法字节，不负责猜测输入的其他字符编码。
    output := runes.ReplaceIllFormed().Bytes(raw)
    return Prepared{
        Raw: raw,
        Display: string(output),
        OriginalValid: utf8.Valid(raw),
        // 比较字节是否变化，不以显示文本中是否含 U+FFFD 来推断。
        Changed: !bytes.Equal(raw, output),
    }
}

项目需要依赖 golang.org/x/text 模块。示例只处理已完整取得的一条数据，不修改调用方的 input，也不向磁盘写入内容。这里的 Display 是派生值，Raw 才是保留的输入字节；两者不能因为界面看起来相似，就被当作同一份无损数据。

例如字节 4B FF 4C 中的 FF 不能单独构成有效 UTF-8，按规则输出会在 K 和 L 中间放入 U+FFFD，其 UTF-8 字节为 EF BF BD。这是编码规则推导，不是执行日志。例子也说明输出长度可能增加，不能假设替换后字节数保持不变。

修改发生在不属于有效 UTF-8 的字节

ReplaceIllFormed 处理的是 UTF-8 编码合法性。普通 ASCII、正确编码的中文或表情、以及本来就合法编码的 U+FFFD，不会仅因为“非英文”或“看起来特殊”而被当作非法字节。

合法 UTF-8 的空字符、控制字符等也不等于业务上可以任意接受的内容。这个转换器不负责去除它们，不完成大小写统一、宽度折叠或 Unicode 规范化。若日志里显示出不易阅读的字符，要先区分编码问题与业务显示规则，不能把所有现象都归入“UTF-8 修复”。

替换字符不能还原原来的编码

多个不同的非法字节都可能变成同一种替换字符。变换后只剩下 U+FFFD，就不能再从显示字符串恢复原来的 FF、FE 或其他无效字节。替换适合表达“这里无法解释”，不适合承担原始证据保存的职责。

同样，统计输出里有几个 U+FFFD，不能可靠地等同于原始错误数。合法原文可能本来包含 U+FFFD；而原始异常的位置和字节数量需要在输入侧记录。示例用 utf8.Valid 判断原始有效性，用 bytes.Equal 判断本次是否发生字节变化，两者都发生在还持有原始数据时。

若上游已经进行过替换，当前输入可能完全有效，OriginalValid 也可能为 true。这只能说明本函数收到的数据有效，不能证明整条采集链路从未丢失过原文。需要追溯时，应在最接近数据来源的地方保存相关元信息。

批量处理应区分接收与修复策略

数据量较少时，直接替换后显示可能已经满足需求；进入批量导入、索引或日志聚合后，若所有入口都静默覆盖原文，问题来源会越来越难定位。改进点不一定是增加更多转换，而是明确每类字段的接收策略。

展示摘要可允许派生修复值；要求原文精确的导入字段可以直接拒绝非法 UTF-8；协议明确使用其他编码的来源则先走对应解码器。三者解决不同需求，不能在一个“自动修复”开关下混用。

保留原始副本也有存储和内存成本。示例为了清楚表达所有权而复制输入；实际批量服务可以按保留期限、数据用途和访问权限设计原始数据保存方式，但不能把“没有保留”包装成“可以随时还原”。没有实际测量，本文不承诺这种封装能减少资源消耗或提高吞吐量。

流式输入需要保留跨块字符

一个多字节 UTF-8 字符可能跨越两次网络读取。若把每一块都当作完整输入调用 Bytes，块尾的不完整前缀可能被提前替换，下一块的续接字节也失去原来的组合条件。完整记录的边界不等于任意 Read 返回的边界。

流式处理应使用支持持续输入的转换方式，正确区分是否到达输入结尾，并处理短源数据等状态；或者在协议层先聚合完整记录，再采用本文封装。不要把对完整输入的修复函数直接套到每个网络块上。

常见问题：ReplaceIllFormed 为什么没有返回 error？它的常用 Bytes 方法直接返回转换结果，非法 UTF-8 正是它要替换的对象。它会原地覆盖输入吗？该方法返回新的字节切片。能用它修复所有乱码吗？不能，它不猜编码。修复后能还原原字节吗？不能依赖显示文本还原，应另行保留原始数据。

参考：ReplaceIllFormed 与 Bytes 定义；原始 UTF-8 有效性判断；字符变换实现。