多语言输入先留原文：Unicode规范化不是语义消毒

原创于 2026-10-26 22:35:54 发布 · 423 阅读

4 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

智能应用安全边界

博客探讨Unicode规范化（特别是NFKC）在多语言输入处理中的局限性，强调规范化不等于语义等价或安全判定。提出原文、规范化副本、摘要三者分离的实践方案，确保可审计性与证据保全；指出零宽字符删除、强制翻译等操作可能破坏语义或排版，并警示不可用关键词匹配替代权限检查。内容涵盖Python unicodedata实现、SHA-256摘要用途及兼容性测试要求。

多语言输入先留原文：Unicode规范化不是语义消毒

看起来相同的字符可能有不同编码，但把字符归一化也可能改变合法内容。客服和安全日志需要一份便于比较的副本，更需要一份能够回到原始证据的记录。

原文、规范化与翻译分开

NFKC会折叠部分兼容字符，适合某些匹配任务，却不等于理解语言。删除零宽字符可能破坏排版或语言表达；强制翻译还会引入另一套模型误差。不能把规范化后的“没有命中关键词”当成合规判定。

做法是保存原始摘要、转换名称和规范化副本；规则只作用于副本，展示争议和人工复核时能够回看原文。结构化业务参数采用自己的类型和枚举约束，不从清洗后的自然语言直接生成权限。

10月5日Google Research对上下文安全的讨论，也适用于这里：文字怎么写和动作是否合适，是不同层面的判断。跨语言表达更不能省去对象权限检查。

多语言输入先留原文：Unicode规范化不是语义消毒的边界与处理流程

图中的原始记录保持只读，转换产物另存，不覆盖原始证据。

给规范化副本附上原始摘要

以下是可离线运行的最小示例，使用Python标准库。输入均为教学构造，不连接业务系统。

import hashlib
import unicodedata

def evidence(text):
    raw = text.encode("utf-8")
    return {
        "raw": text,
        "raw_sha256": hashlib.sha256(raw).hexdigest(),
        "normalizer": "NFKC",
        "normalized": unicodedata.normalize("NFKC", text),
    }

a, b = evidence("ＡＢＣ"), evidence("ABC")
assert a["normalized"] == b["normalized"]
assert a["raw"] != b["raw"]
assert a["raw_sha256"] != b["raw_sha256"]
assert evidence("")["normalized"] == ""
print("original evidence preserved across normalization")

摘要用于关联内容，不证明上传者身份，也不识别恶意意图。这个例子没有翻译或语言模型，只验证了原始差异能被保留下来。