报表文本清洗总误匹配：用 re 固定提取规则、命中位置和未命中清单 #
文档明确的机制 #
Python 标准库 re 提供类似 Perl 的正则表达式匹配操作。模式和待搜索字符串既可以是 Unicode 字符串（str），也可以是 8 位字符串（bytes），但二者不能混用：不能用 bytes 模式匹配 Unicode 字符串，也不能反过来；替换字符串也必须与模式、搜索字符串类型一致。
正则中的反斜杠用于表示特殊形式或转义特殊字符，这与 Python 普通字符串字面量的反斜杠规则重叠。文档建议通常使用 raw string 编写模式，因为 r"\n" 是包含反斜杠和字母 n 的两个字符，而 "\n" 是包含换行符的一个字符。
re.compile() 可把表达式编译为正则对象；多数操作既有模块级函数，也有编译后对象的方法。提取字段时，文档中的 search() 用于查找第一个匹配，finditer() 可遍历匹配对象；匹配对象通过 group() 取得内容，命名分组写作 (?P<name>...)，随后可用 m.group('quote') 这样的形式按名称取回。普通括号会形成捕获组，(?:...) 则是非捕获组。
量词的边界也要按文档理解：* 匹配 0 次或多次，+ 匹配 1 次或多次，? 匹配 0 或 1 次；{m} 要求恰好 m 次，{m,n} 表示 m 到 n 次。*、+、? 默认贪婪，会尽可能多匹配；在后面加 ?，如 *?、+?、??，变为非贪婪或最小匹配。例如文档说明 <.*> 匹配 <a> b <c> 时会覆盖整串，而 <.*?> 只匹配 <a>。
位置控制可使用锚点：^ 匹配字符串开头，在 MULTILINE 模式下也会匹配每个换行之后；$ 匹配字符串末尾或末尾换行之前，在 MULTILINE 下也可匹配换行之前。. 默认匹配除换行外的任意字符；指定 DOTALL 后，. 也匹配换行。也就是说，多行日志、跨行备注是否让点号穿过换行，应由是否使用该标志明确决定。
团队自行约定的接手建议 #
以下是团队接手文本清洗任务时的约定，不是 re 文档额外承诺的产品能力。
第一，先固定“字段格式”，再写提取器。编号、日期、金额分别使用独立命名分组，例如把订单备注中的编号、金额写成一个编译规则：pattern = re.compile(r"订单[：:]\s*(?P<order_no>[A-Za-z0-9_-]+).*?金额[：:]\s*(?P<amount>\d+(?:\.\d+)?)", re.S)。这里用 raw string 降低反斜杠歧义，用 re.compile 固化规则；跨行文本才考虑 re.S，逐行处理行首字段时才考虑 re.M。不要把 DOTALL 和 MULTILINE 当作所有报表的默认开关。
第二，输出不要只保留解析后的值，还应保留原始命中片段和位置。使用 finditer() 遍历每条命中，并记录匹配对象的起止位置；单字段规则可先 search()，但同一文本允许重复出现编号或金额时，应把所有命中列出。group() 可读取完整命中和命名字段，便于追查“这个金额到底从哪句话来的”。
第三，把未命中、多命中作为正式结果，而不是丢弃。团队可约定每条输入返回四部分：结构化字段、命中的原始片段、位置区间、异常清单。0 个命中进入 misses，同一字段出现 2 个及以上候选进入 multiple_matches。这样可以避免清洗脚本静默吞掉备注，也能让人工只复核异常项。
第四，控制贪婪范围。字段之间有明确结束符时，优先使用字符集或非贪婪量词，避免 .* 从一个编号吞到下一条记录。但非贪婪不是“最短正确答案”的保证，仍要用真实订单备注、日志行、文件名样本复核。锚点应服务于已知格式：行首标签可配合 ^ 与 MULTILINE，整串必须完全符合格式时再使用字符串起始、结束锚点。
第五，复杂格式提取后要接字段校验。正则可以抽出形似日期、金额、编号的文本，但文档只说明正则匹配机制，并未声称它能验证复杂业务语义。金额是否超出账期规则、日期是否为有效日历日期、编号是否属于当前系统，都应由后续校验处理。
边界与总结 #
re 能做的是按表达式寻找、捕获和拆分文本形态；它不负责证明字段在业务上真实有效。Unicode str 与 bytes 不能混用，读取文件、日志或文件名后应先统一文本类型。遇到复杂嵌套、强语义校验或多格式混杂的报表，应把正则限制在“候选片段提取”层，再交给独立的字段验证和人工异常清单。
可靠的清洗结果应让接手者同时看到规则、值、原文片段、位置和异常；命中可追溯，未命中不静默，多命中不擅自选一个。这样，正则承担文本形态匹配，后续校验承担业务判断，误匹配才更容易定位和修正。
相关工具 #
AI 工作流 ROI 诊断器 · 查看工具的输入要求、输出说明与适用范围。