用正则验证编号之前，先想清楚全角字符怎么办

本文使用合成样本演示处理方法。代码已通过隔离环境中的示例检查；这不代表对所有真实文件或产品效果的保证。处理重要文件前，请保留原件，并按文中的边界与验收项复核。 编号 AB-1234 看起来很简单，真正的输入却可能带前缀、尾部换行或全角字符。只写一个正则，然后见到“匹配成功”就放行，容易把子串命中误当成整个字段符合协议。 长度与模式分开约束 JSON Schema 的 pattern 通常表示正则能在字符串中找到匹配，不隐含整串匹配。本文要求两个大写拉丁字母、短横线和四位 ASCII 数字，总长度七个字符。同时设置长度与模式，可以把这个特定协议的范围说清楚。 不同语言的正则实现存在差异，尤其是锚点、Unicode 字符类和转义。不要把某个语言专有的表达式直接宣称为所有 JSON Schema 实现都支持。 用看起来接近的反例检验 from jsonschema import Draft202012Validator schema = {"type": "string", "minLength": 7, "maxLength": 7, "pattern": "[A-Z]{2}-[0-9]{4}"} validator = Draft202012Validator(schema) valid = lambda x: not list(validator.iter_errors(x)) assert valid("AB-1234") assert not valid("prefix-AB-1234") assert not valid("AB-1234\n") assert not valid("ＡＢ-1234") assert not valid("AB-１２３４") assert not valid("ab-1234") 这个规则选择拒绝全角字符，而不是自动归一化。另一个系统可以选择归一化后验证，但应同时保留原始值与转换记录。二者都是明确策略，比在不同模块里各自做一半更好排查。 不符合格式不代表可以随便修 输入 本例结果 后续可选动作 AB-1234 通过 再检查业务是否存在此编号 带尾部换行 拒绝 按明确输入协议决定是否去除 全角字母数字 拒绝 归一化策略应单独定义 大小写不符 拒绝 不在未知规则下自动大写 格式正确只是第一道检查 正则不能证明编号真实存在，也不能证明它属于当前客户或对应当前文档。OCR 把 O 识成 0 后，字符串甚至仍可能满足某种宽泛模式。高风险字段需要来源位置和业务核对，不能把格式检查结果直接显示成“提取正确”。 翻译时把标识符当作受保护内容 在文档翻译工作流中，编号通常需要原样保留。评估 OmniDoc（产品入口） 输出时，可用这类契约检查标识符是否发生全角化、大小写改变或字符缺失，再回到原文确认。本文检查规则属于你的交付协议，不是平台内部实现说明。 参考： JSON Schema 字符串模式 。 - 1 -