补充3：
这里把直接面对问题的积极回答，从补充2里单独提出来。
对于这个匹配问题本身，我的建议是：
如果A和B是配对的，那最好能够观察是否存在断行、父标签等，能用来区分每个组的明确依据。例如有这样的数据源那是最好：
如果没有，那就只好想其他办法了。中心思想仍然是“尽量别被坑”。
主要坑人的地方在于：可能会出现连续的或。例如ABABAAABAB，那么中间的3个A中前两个最好是丢弃。
所以稳妥起见，最好不要一次到位的(?P.*).*(?P.*)。
我推荐的用法是：(?:a)>(?P.*))|(?:b)>(?P.*))，一次把所有的标签不论是A或B全部拿到。
然后扫描一遍，只把相邻的A和B看作一组有效数据。
注意以上代码全部空手写的，没做测试甚至没详细看，仅供表意参考。
补充2：
XML不标准是一个合理的理由。应对这一实际情况，我的建议是：
尽量选用支持混合/容忍模式的XML解释器。容忍一些XML的毛病其实是很多HTML分析器的底层基础。
不做一步到位的事情。先把每条记录断开，再在每条记录的范围内，去分析各个字段的详情。这样至少可以把所有的问题控制在1条记录之内，免于“牵一发而动全身”。(参考这个答案)
永远把Regex作为最后选择。
另外我必须非常严肃的批评楼主：你又是一个XY PROBLEM的反面教材。
最开始只拿出一个非常简单和规范的XML片段，结果两次Update才把最后“XML可能不规范”这么重要的内情说出口。
你这是故意留着什么王牌，用于被批评的时候维护你脆弱的自尊吗？！
你还能不能再脆弱点！！！
补充1：
不能同意问题正文的Update 2。
用正则匹配正则XML，就意味着只要在XML的规则之内挖几个小坑，偷懒的程序员就会掉进去。
Regex解析XML我认为就是“绝对不适合实际应用”，不该是有什么疑问的事情。如果硬要做，那就意味着实际做出的程序只能适应一些特定情况。并且如果数据源有丝毫的改动(例：程序员把少量标签临时注释掉了)也可能需要人类做hotfix。结果就是把摩天大楼盖在散沙之上，程序员辛苦写出的程序不久就不能用了。这将是一场永无止境的循环。
“只要是事情，就都没有绝对”，这个判断本身难道不是“绝对”的？我认为原则就是原则，部分问题有明确的是非之分，有些浑水是不能搅的。如果在原则问题上这里可以退后一点，那里可以放过一些，那这样写出的程序，恐怕只能陷入一种神出鬼没、不可捉摸的结局。
SOF上有其他说法太正常了，难道见到了就非得认可？！
唯一能肯定的就是如果用XML当作学习正则的例子，倒是做做无妨。
我宁愿把这个问题彻底掀翻。
怎么总有人喜欢用正则表达式解析XML/HTML啊？！
啥时候用Parser还是Regex解析XML居然能够“各有所长”，还成了个能够商量、可以讨论的问题了啊？？！！
这是需要讨论的问题吗？？？！！！
永远不要用正则取代XML解释器
铁的原则！
一步不退！
再简单的XML也不行！
因为你不能用一个简单的正则表达式，覆盖XML所有的复杂结构。XML的情况之多，什么地方虽然怪异但正确，什么地方只是可以容忍，什么地方应该干脆报错，这不是正则覆盖的了的。
例如以下几种情况，扪心自问：如果用正则来做，会条条都考虑到吗？
注释：
无解析文本段：“CDATA Section” should be ignored too ]]>
对实体的转义：content of A < B is A < B instead of A < B
自封闭标签： is an equivalent to , shouldn't be ignored
一个元素有多个属性值时，属性的顺序可能是随意的
所以正则和XML解释器是完全不同复杂度的两个东西。混用的结果就是：代价一定会在某一天连本带利还给你。不要因为“这样做能达到目的”，就放弃写坚固的代码。这是用身体上看似的“勤快”，去掩盖思想上绝对的懒惰。
参加过中学信息学奥赛，或大学ACM/ICPC的玩家们都明白一个浅显的道理：
样例数据能通过，和整道题能够Accepted是两个完全不同的概念。
实际的编程也是如此。对于这个需求，考虑到XML是一个标准，所以涉及XML的代码必须要“保证”他对于符合标准的XML都能工作，而不是不断的折腾让代码“看起来”适用于你设定的片面的“样例数据”。
看看这篇文章《Linux 2.6.39-rc3的一个插曲》，记住Linus Torvalds的教导：
This kind of “I broke things, so now I will jiggle things randomly until they unbreak” is not acceptable.
这种“我把事搞砸了，就随意地调整直到事情又工作”的方式是不可接受的。
4526
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
