我刚刚回顾了之前发布的帖子,注意到有许多人建议我不要使用正则表达式来解析XML。在那种情况下,XML相对简单,使用正则表达式也没有问题。但是我还要解析其他一些代码格式,为了统一起见,使用正则表达式是有意义的。但我很好奇它在其他情况下可能会产生什么问题。这只是一种“不要重复造轮子”的问题吗?
我刚刚回顾了之前发布的帖子,注意到有许多人建议我不要使用正则表达式来解析XML。在那种情况下,XML相对简单,使用正则表达式也没有问题。但是我还要解析其他一些代码格式,为了统一起见,使用正则表达式是有意义的。但我很好奇它在其他情况下可能会产生什么问题。这只是一种“不要重复造轮子”的问题吗?
真正的麻烦在于嵌套标签。嵌套标签很难用正则表达式处理。虽然使用平衡匹配可能是可行的,但这只适用于.NET和其他几个版本。但即使使用平衡匹配的强大功能,一个放置不当的注释也可能扰乱正则表达式。
例如,这是一个棘手的解析示例...
<div>
<div id="parse-this">
<!-- oops</div> -->
try to get this value with regex
</div>
</div>
你可能需要花费数小时来使用正则表达式解决这样的边缘情况,也许能找到一个解决方案。但实际上,当有专门处理XML、XHTML和HTML的解析器可以更可靠和高效地完成工作时,这是没有意义的。
XML不是一种正则语言(这是一个技术术语),因此您永远无法使用正则表达式正确解析它。您可能成功99%的时间,但随后会有人发现编写XML的方法使您失效。
如果您正在编写某种屏幕抓取程序,则99%的成功率可能足够。但对于大多数应用程序来说,这是不够的。
r'[\s \t,]*("[^"]+"|\'[^\']+\'|[^ \t,]+)[ \t,]*'
和r'[\s \t]*([+-]?"[^"]+"|\'[^\']+\'|[^ \t]+)[ \t]*'
。想到我写了这些可怕的生成器,我就有点反胃。; ^P 而且这仍然(极其)容易受到引号平衡的影响! - amcgregor