XML 1.0 不支持 Emoji 等 4 字节 UTF-8 字符（U+10000–U+10FFFF），导致解析报错；解决需统一升级至 XML 1.1、改用支持库（如 lxml/ StAX）、确保数据库用 utf8mb4，并全程校验 UTF-8 字节流。
XML解析报错 Invalid byte 2 of 3-byte UTF-8 sequence 或 Character reference "😂" is an invalid XML character
这是典型的 4 字节 UTF-8（即 Unicode 补充平面字符，如大部分 Emoji）在 XML 解析时被拒绝导致的错误。XML 1.0 规范默认只允许 #x9、#xA、#xD 和 #x20–#xD7FF、#xE000–#xFFFD 范围内的字符，而常见 Emoji（如 ?、?、?）落在 #x10000–#x10FFFF，属于 XML 1.0 **非法字符**。
实操建议：
- 确认你用的是 XML 1.0 还是 XML 1.1：Java 的
DocumentBuilder、Python 的xml.etree.ElementTree、.NET 的XmlReader默认都按 XML 1.0 解析，直接拒掉 Emoji - 如果必须保留 Emoji，优先升级到 XML 1.1 —— 它明确允许
#x10000–#x10FFFF，但要注意：不是所有库都默认支持，需显式声明版本 - 检查 XML 声明是否写成
<?xml version="1.1" encoding="UTF-8"?>；仅改 version 不够，解析器还必须启用 XML 1.1 模式（例如 Java 的DocumentBuilderFactory.setFeature("http://apache.org/xml/features/dom/allow-java-encoding", true)不起作用，得换解析器或预处理）
Python 用 xml.etree.ElementTree 读含 Emoji 的 XML 直接崩溃
这个模块底层依赖 expat，而 expat 在 XML 1.0 模式下遇到 4 字节 UTF-8 序列会立刻抛 xml.etree.ElementTree.ParseError，不给你留修复机会。
实操建议：
- 不要硬刚——先用
codecs.open(..., encoding="utf-8")读成字符串，用正则或字符串操作把非法字符替换成占位符（如）或移除：re.sub(r"[\U00010000-\U0010FFFF]", "", xml_str) - 更稳妥的做法是改用支持 XML 1.1 的库，比如
lxml：它可通过parser = etree.XMLParser(strip_cdata=False, resolve_entities=False, recover=False)配合etree.fromstring(xml_bytes, parser)处理（但仍需确保输入字节流本身合法，且声明为 1.1） - 注意：即使用了
lxml，若 XML 声明仍是version="1.0"，它仍按 1.0 规则校验——必须同步改声明，或传入parser=etree.XMLParser(no_network=True, resolve_entities=False)并手动忽略字符检查（不推荐）
Java DocumentBuilder 解析失败，日志出现 Invalid byte 2 of 3-byte UTF-8 sequence
这个错误其实有误导性：它常出现在 XML 声明编码与实际字节不匹配时，但更多时候是因 Emoji 导致的“超范围字符”被底层 SAX 解析器误报为编码错误。
实操建议：
- 别信错误信息字面意思——先用十六进制查看器（如
xxd）确认文件确实是 UTF-8 编码，且 Emoji 是标准 4 字节序列（如 ? 是f0 9f 98 82） -
DocumentBuilder无法优雅跳过非法字符。可行路径只有两条：一是在加载前用InputStreamReader+BufferedReader预处理，把高代理对（surrogate pairs）范围外的字符过滤掉；二是换javax.xml.stream.XMLInputFactory（StAX），它支持设置factory.setProperty("javax.xml.stream.isNamespaceAware", false)并配合自定义StreamReader拦截异常事件 - Spring 的
SimpleXmlMessageConverter同样踩坑，若用于 HTTP 接口，建议在 Controller 层用@RequestBody String raw接收，自己清洗后再交给 XML 工具
Emoji 存进数据库再读出写回 XML，结果变成乱码或空格
这不是 XML 解析问题，而是中间环节的字符集断裂：MySQL 默认 utf8 只支持 3 字节（即 BMP 字符），utf8mb4 才支持 4 字节；PostgreSQL 虽默认支持，但 JDBC URL 若没加 ?charset=utf8mb4，驱动仍可能降级处理。
实操建议：
- 检查数据库字段编码：MySQL 必须是
CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci，且连接池配置里指定useUnicode=true&characterEncoding=utf8mb4 - 验证数据是否真存进去了：用 MySQL 命令行执行
SELECT HEX(content) FROM table WHERE id=1;，看 Emoji 对应位置是不是F09F9882这类 4 字节值；如果是3F（即?的 ASCII 码），说明入库时已被截断或替换 - 从 DB 读出后生成 XML 前，用
String.getBytes(StandardCharsets.UTF_8)打印长度，对比原始字符串.length()——若前者远大于后者，说明含 4 字节字符；此时若用旧版 DOM 写 XML，Element.setTextContent()可能静默丢弃，要用createCDATASection()包裹或改用Transformer输出时指定OutputKeys.ENCODING为"UTF-8"并关闭缩进
真正麻烦的从来不是“怎么让 Emoji 显示出来”，而是整条链路里任意一个环节（编辑器保存、HTTP 传输、DB 存储、XML 解析、HTTP 响应）只要有一个按老规矩办事，它就悄无声息地消失或变质。盯住字节，别信字符串长度。
