Hello!
2013/3/10 duan yuxuan:
> 关于匹配中是否重置上下文,我觉得您可以提供一个开关,因为在实际中,很多时候会出现串包含的现象,
> 比如“.*ab”,“.*abc”,目前匹配了前面一个串就没法匹配后面的串了,有时一些特殊需求的情况下,sregex
> 就不能满足。(您是基于什么思想,在命中后要reset上下文?)
>
在流式匹配的上下文中,寻找 /re1|re2|re3/ 的可重叠的所有可能匹配的开销过大,所以多正则匹配的语义是类似
tokenizer,或者说词法分析器。一个这样的例子是 lex. 我们在匹配时总是只选出 left-most,
highest-priority 的正则(或者正则 alternative 分支),而优先级在这里是由先后次序决定的(在 lex
中则不同,是 longest-token match 语义)。这也符合 Perl 5 正则的 m/re/g 全局匹配操作的语义。
> 今天给你mail主要是另外一个问题:
> 我发现如:
> ./sregex-cli -n 2 ".*abc" ".*def" "123defabc"
>
> 结果会匹配第一个串,而第二个却匹配不了,我觉得应该是要匹配以一个才符合逻辑的,
在你这个例子中,这两个正则表达式的匹配起始位置都是
0(即输入字符串的开头),于是决定谁匹配的是二者的相对优先级,而第一个正则的优先级总是高于第二个正则,所以第一个正则先匹配,然后正则引擎会接着从前一个匹配(即
/.*abc/ 匹配的 123defabc
子串)的结束位置继续向下匹配这两个正则。显然,此时当前处理指针已到达输入串的末尾,找不到更多的匹配了。
> 我看了sre_vm_pike_exec,您的实现应该是:
>
> 对于输入的字符x,确定状态机中每个模式串的下一个状态。
>
> 但从匹配结果来看,好像是:
>
> for(patterns)
> {
> 对于给定的数据,这个串是否命中。
> }
>
这个解释也是错误的。可以考虑下面这个例子:
./sregex-cli -n 2 "abc" "def" "123defabc"
此时首先匹配的是第二个正则,因为第二个正则的匹配起始位置在第一个正则匹配起始位置的左边,即 left-most
胜出。只有当二者起始位置相同时,才会按优先级决出胜负。
对于 sregex 正则引擎的多用户正则模式,所有参与匹配的用户正则在语义(以及实现上)都是直接用 | 运算符按序拼接成一个大正则进行匹配的。
再次抄送给 openresty 中文邮件列表:https://groups.google.com/group/openresty 建议你加入
openresty 中文邮件列表并在那里讨论 sregex 相关的细节问题。谢谢合作。
Best regards,
-agentzh