转换流中非法字符处理取决于编码合法性与目标集支持性，主流策略包括忽略、替换、异常中断及自定义回调，需结合源头校验与工具文档综合应对。
在转换流（如 UTF-8 ↔ GBK、UTF-8 ↔ ISO-8859-1 等编码间转换）过程中，遇到非法或无法识别的字符序列时，核心是明确“如何处理不可映射字节/码点”——这取决于你使用的编程语言和具体 API，但策略逻辑相通。
理解非法字符的两种常见来源
• 字节序列本身不合法：例如在 UTF-8 中出现孤立的 continuation byte（如 0x80 单独出现），或超长编码（如用 4 字节编码一个本可用 2 字节表示的字符）。这类输入违反编码规范，解析器通常直接报错。
• 字节合法但目标编码不支持该字符：例如将含中文“你好”的 UTF-8 数据转为 ASCII，或把生僻汉字从 UTF-8 转 GBK（GBK 字符集未收录该字）。这时问题不在语法，而在语义映射缺失。
主流处理策略与代码示例
多数语言提供以下几种预设行为，可通过参数显式指定：
-
忽略（ignore）：跳过无法转换的字符/字节，不报错也不替换。适合对数据完整性要求不高、侧重流程稳定的场景。Python 示例：
bytes.decode('gbk', errors='ignore') -
替换（replace）：用占位符（如 、? 或 ）替代非法内容。平衡可读性与健壮性，调试友好。Java 示例：
new String(bytes, Charset.forName("GBK").newDecoder().onMalformedInput(CodingErrorAction.REPLACE).onUnmappableCharacter(CodingErrorAction.REPLACE)) - 异常中断（strict）：默认行为，遇到任何问题立即抛出异常。适合开发调试或强一致性要求场景，便于定位源头问题。
-
自定义回调（如 Python 的 'xmlcharrefreplace' 或自定义 error handler）：将不可映射字符转为 XML 实体（如
你）或调用函数动态处理，适合需保留语义线索的导出场景。
实用建议：避免问题比处理问题更重要
• 源头确认编码标识是否真实准确——很多“非法字符”实为错误声明编码所致（如把 GBK 文件当 UTF-8 读）；
• 对用户输入或外部文件，优先使用带 BOM 的 UTF-8 或显式声明 charset（HTTP header / HTML meta）；
• 批量转换前先抽样检测编码（如用 chardet 或 uchardet），比硬转更可靠；
• 日志中记录被替换/忽略的原始字节和位置（尤其在 replace/ignore 模式下），方便后续溯源。
注意跨平台与库差异
不同库对同一错误的判定粒度可能不同：例如 Node.js 的 Buffer.toString('utf8') 遇到非法 UTF-8 会返回包含 的字符串，而某些 C 库可能直接截断；Go 的 strings.ToValidUTF8() 只处理 Unicode 码点有效性，不解决编码转换映射问题。务必查阅所用工具的具体文档，而非假设行为一致。
