我一直在尝试使用正则表达式解析宗地数字并遇到一些问题。我从这开始：
r'(?<=[":#][\s\n])(\d{2}[-:\s]*\d{2}[-:\s]*\d{3}[-:\s]*\d{3}(?:\-{1}\d{4})?)'
以后面的方式来确保我没有意外地返回10或14位长的电话号码或内部文件号码。然后事实证明，一个列表可能包含由任意数量的字符（空格，和/，＆amp;等）分隔的几个地块编号（最多40+）。那么我就切断了背后的外观来处理这个问题：
r'\d{2}[-:\s]*\d{2}[-:\s]*\d{3}[-:\s]*\d{3}(?:[-:\s]*\d{4}$)?'
但接着是一个包含以下内容的例子：
＃22-33-155-003 NKA 22-33-155-009 ...... H / W＃41877 1021690 UPAXLP
返回了：
['22-33-155-009', '22-33-155-003', '1877 102169']
我尝试将^添加到开头，$添加到结尾以防止最后一位（41877 1021690 UPAXLP）返回'1877 102169'，但之后它不会返回任何内容。
每个列表来自不同的来源，其具有用于显示宗地号码的不同格式，唯一可靠的消防方式是识别具有可能的字符（ - ，/，SPACE等）的10个数字模式，分离并使用后面的外观/提前确保它实际上是一个包裹号码。
我的问题是：
1）如何在考虑几个可能的字符分隔的几个包裹的可能性的同时保持前瞻/后视？
2）如果使用分隔字符，如何在整个过程中使用它，我该如何强制执行？所以12-34-567-890或12 34 567 890而非1234 567890或12-34:567 890会阻止上面显示的最后一个示例。
3）有更好的方法吗？
答案 0 :(得分：1)
您可以使用lookbehind强制执行相同的分隔字符：
r"""
\d{2}(?P<separator>[-:\s]?)
\d{2}(?P=separator)
\d{3}(?P=separator)
\d{3}(?:(?P=separator)\d{4})?"""
我认为这个正则表达式与你描述的模式相符。我使用了你自己的正则表达式，添加了分隔符功能，并删除了'$'。我认为'$'正在玷污作品......