pcre在匹配utf8字符时效率有问题

lancelijade

hi,

在之前的一封邮件中，我误认为openresty导致了我的测试用例失败，但在agentzh和kindy的帮助下，我基本确认了问题是出在pcre匹配utf8字符时存在效率问题，测试方法如下。

    server
    {
        listen 80;
        server_name test;
        location /
        {
            content_by_lua '
              local key = string.rep ("张", 10000)
              local it, err = ngx.re.gmatch(key, ".", "soj")
              while true do
                local m, err = it()
                if not m then break end
              end
            ';
        }
    }

当匹配pattern用 soj ，张字重复 10000, 20000, 30000, 40000 次时，执行时间分别是
0.013s 0.023s 0.032s 0.042s
基本线性增长，符合预期；

但当pattern改为 usoj 时，同样重复 1万到4万次，执行时间分别为
0.784s 3.118s 7.001s 12.441s
居然变成了指数级增长？！太恐怖了，我也是导致我下午那封邮件内误以为openresty死循环的原因。

郁闷了，或者我更应该期待 agentzh 的新正则引擎？

Lance

agentzh

Hello!

2013/4/3 Lance:
> 当匹配pattern用 soj ，张字重复 10000, 20000, 30000, 40000 次时，执行时间分别是
> 0.013s 0.023s 0.032s 0.042s
> 基本线性增长，符合预期；
>
> 但当pattern改为 usoj 时，同样重复 1万到4万次，执行时间分别为
> 0.784s 3.118s 7.001s 12.441s
> 居然变成了指数级增长？！太恐怖了，我也是导致我下午那封邮件内误以为openresty死循环的原因。
>

PCRE 的 UTF-8 匹配模式本来就代价高昂，你可以把问题报告给 PCRE 官方，同时尝试换用 re2 正则库试试 :)

Best regards,
-agentzh

lancelijade

有在openresty里调用re2的解决方案吗？

Lance
On Apr 4, 2013 2:35 AM, "agentzh" <age...@gmail.com> wrote:
>
> Hello!
>
> 2013/4/3 Lance:
> > 当匹配pattern用 soj ，张字重复 10000, 20000, 30000, 40000 次时，执行时间分别是
> > 0.013s 0.023s 0.032s 0.042s
> > 基本线性增长，符合预期；
> >
> > 但当pattern改为 usoj 时，同样重复 1万到4万次，执行时间分别为
> > 0.784s 3.118s 7.001s 12.441s
> > 居然变成了指数级增长？！太恐怖了，我也是导致我下午那封邮件内误以为openresty死循环的原因。
> >
>
> PCRE 的 UTF-8 匹配模式本来就代价高昂，你可以把问题报告给 PCRE 官方，同时尝试换用 re2 正则库试试 :)
>
> Best regards,
> -agentzh
>
> --
>
>

lancelijade

另外，在编译openresty时如果想把pcre静态编译进来，并想送参数给pcre，比如 --enable-utf，好象没有办法，用 --with-pcre-opt=--enable-utf 效果不对

Lance

2013/4/4 Lance <lance...@gmail.com>

有在openresty里调用re2的解决方案吗？

Lance

On Apr 4, 2013 2:35 AM, "agentzh" <age...@gmail.com> wrote:
>
> Hello!
>
> 2013/4/3 Lance:
> > 当匹配pattern用 soj ，张字重复 10000, 20000, 30000, 40000 次时，执行时间分别是
> > 0.013s 0.023s 0.032s 0.042s
> > 基本线性增长，符合预期；
> >
> > 但当pattern改为 usoj 时，同样重复 1万到4万次，执行时间分别为
> > 0.784s 3.118s 7.001s 12.441s
> > 居然变成了指数级增长？！太恐怖了，我也是导致我下午那封邮件内误以为openresty死循环的原因。
> >
>
> PCRE 的 UTF-8 匹配模式本来就代价高昂，你可以把问题报告给 PCRE 官方，同时尝试换用 re2 正则库试试 :)
>
> Best regards,
> -agentzh
>
> --
>
>

agentzh

Hello!

2013/4/4 Lance:
> 有在openresty里调用re2的解决方案吗？
>

你可以使用 LuaJIT FFI 直接调用 C++ 符号：

http://lua-users.org/lists/lua-l/2011-07/msg00502.html

或者编写传统的 Lua C 模块粘合 re2 的 C++ API.

不过你应当首先确认一下 re2 的 UTF-8 匹配效率是否满足你的需求。

Regards,
-agentzh

agentzh

Hello!

2013/4/4 Lance:
> 另外，在编译openresty时如果想把pcre静态编译进来，并想送参数给pcre，比如 --enable-utf，好象没有办法，用
> --with-pcre-opt=--enable-utf 效果不对
>

Nginx 构建系统的 --with-pcre-opt 定义的不是 PCRE 的 ./configure 选项。这个受制于标准的 Nginx
构建系统，建议直接向 Nginx 官方提意见（比如通过 nginx-devel 邮件列表）。

-agentzh

lancelijade

在@姜大炮的帮助下，我修改了 ngx_http_lua_regex.c 文件中的

#define ngx_http_lua_regex_exec(re, e, s, start, captures, size)             \
    pcre_exec(re, e, (const char *) (s)->data, (s)->len, start, 0,           \
              captures, size)

一段，把0改成了 PCRE_NO_UTF8_CHECK

#define ngx_http_lua_regex_exec(re, e, s, start, captures, size)             \
    pcre_exec(re, e, (const char *) (s)->data, (s)->len, start, PCRE_NO_UTF8_CHECK,           \
              captures, size)

效率问题解决了，代价是送入的文本需要自己保证 utf8 序列正确，这个可以用 iconv 之类的东西来实现。

agentzh 考虑把这个选项直接暴露给前端API以达到更高灵活性的目的吗？

Lance

2013/4/5 agentzh <age...@gmail.com>

Hello!

2013/4/4 Lance:

> 另外，在编译openresty时如果想把pcre静态编译进来，并想送参数给pcre，比如 --enable-utf，好象没有办法，用
> --with-pcre-opt=--enable-utf 效果不对
>

Nginx 构建系统的 --with-pcre-opt 定义的不是 PCRE 的 ./configure 选项。这个受制于标准的 Nginx
构建系统，建议直接向 Nginx 官方提意见（比如通过 nginx-devel 邮件列表）。

-agentzh

--

linuxrootkits

不错

在 2013年4月7日上午11:26，Lance <lance...@gmail.com>写道：
>
> 在@姜大炮的帮助下，我修改了 ngx_http_lua_regex.c 文件中的
>
> #define ngx_http_lua_regex_exec(re, e, s, start, captures, size) \
> pcre_exec(re, e, (const char *) (s)->data, (s)->len, start, 0, \
> captures, size)
>
> 一段，把0改成了 PCRE_NO_UTF8_CHECK
>
> #define ngx_http_lua_regex_exec(re, e, s, start, captures, size) \
> pcre_exec(re, e, (const char *) (s)->data, (s)->len, start, PCRE_NO_UTF8_CHECK, \
> captures, size)
>
> 效率问题解决了，代价是送入的文本需要自己保证 utf8 序列正确，这个可以用 iconv 之类的东西来实现。
>
> agentzh 考虑把这个选项直接暴露给前端API以达到更高灵活性的目的吗？
>
>
>
> Lance
>
>
> 2013/4/5 agentzh <age...@gmail.com>
>>
>> Hello!
>>
>> 2013/4/4 Lance:
>> > 另外，在编译openresty时如果想把pcre静态编译进来，并想送参数给pcre，比如 --enable-utf，好象没有办法，用
>> > --with-pcre-opt=--enable-utf 效果不对
>> >
>>
>> Nginx 构建系统的 --with-pcre-opt 定义的不是 PCRE 的 ./configure 选项。这个受制于标准的 Nginx
>> 构建系统，建议直接向 Nginx 官方提意见（比如通过 nginx-devel 邮件列表）。
>>
>> -agentzh
>>
>> --
>>
>>
>
> --
> sp;
>

agentzh

Hello!

2013/4/6 Lance <lance...@gmail.com>:
> 在@姜大炮 的帮助下，我修改了 ngx_http_lua_regex.c 文件中的
>
[...]
>
> 一段，把0改成了 PCRE_NO_UTF8_CHECK
>
[...]
>
> 效率问题解决了，代价是送入的文本需要自己保证 utf8 序列正确，这个可以用 iconv 之类的东西来实现。
>

哦，原来 UTF-8  检查的开销这么大 :)

> agentzh 考虑把这个选项直接暴露给前端API以达到更高灵活性的目的吗？
>

我有些犹豫是否应该提供这样的选项，因为首先这过于特定于 PCRE， 其次一旦提供的字符串里有非法序列，则 PCRE
可能会崩溃，粗心的用户可能并不知道要自己去检查非法的 UTF-8 序列。

或许我们可以提供一个 C 预处理期的宏选项来控制？

Regards,
-agentzh

lancelijade

按我的理解，真正开销大的不是检查本身，而是反复检查。

在 ngx_http_lua_ngx_re_match 和 ngx_http_lua_ngx_re_gmatch_iterator 里都是通过调用 ngx_http_lua_regex_exec 来进行实际匹配的，每次进行这个调用时，如果没有设置 PCRE_NO_UTF8_CHECK， pcre 会检查 offset 之前部分是否 utf8 合法，这在反复匹配中复杂度就成了指数级。

如果不把这个参数暴露给用户，或者可以考虑在一个字符串第一次需要 utf8 匹配时使用某种方式来预处理，并记下成功标记，之后再次匹配时就可以直接使用 PCRE_NO_UTF8_CHECK 了。

Lance

2013/4/8 agentzh <age...@gmail.com>

Hello!

2013/4/6 Lance <lance...@gmail.com>:

> 在@姜大炮的帮助下，我修改了 ngx_http_lua_regex.c 文件中的
>

[...]
>
> 一段，把0改成了 PCRE_NO_UTF8_CHECK
>
[...]

>
> 效率问题解决了，代价是送入的文本需要自己保证 utf8 序列正确，这个可以用 iconv 之类的东西来实现。
>

哦，原来 UTF-8 检查的开销这么大 :)

> agentzh 考虑把这个选项直接暴露给前端API以达到更高灵活性的目的吗？
>

我有些犹豫是否应该提供这样的选项，因为首先这过于特定于 PCRE，其次一旦提供的字符串里有非法序列，则 PCRE
可能会崩溃，粗心的用户可能并不知道要自己去检查非法的 UTF-8 序列。

或许我们可以提供一个 C 预处理期的宏选项来控制？

Regards,

-agentzh

--

agentzh

Hello!

2013/4/7 Lance:
> 按我的理解，真正开销大的不是检查本身，而是反复检查。
>
> 在 ngx_http_lua_ngx_re_match 和 ngx_http_lua_ngx_re_gmatch_iterator 里都是通过调用
> ngx_http_lua_regex_exec 来进行实际匹配的，每次进行这个调用时，如果没有设置 PCRE_NO_UTF8_CHECK， pcre
> 会检查 offset 之前部分是否 utf8 合法，这在反复匹配中复杂度就成了指数级。
>

嗯，PCRE 貌似并不像我的 sregex 库那样原生支持这种增量式的全局匹配，各次 exec
之间它本质上是无状态的，所以它每次都需要重新验证和处理 offset 位置之前的相关状态。

> 如果不把这个参数暴露给用户，或者可以考虑在一个字符串第一次需要 utf8 匹配时使用某种方式来预处理，并记下成功标记，之后再次匹配时就可以直接使用
> PCRE_NO_UTF8_CHECK 了。
>

这个貌似需要修改 PCRE 本身，即让 PCRE 自己在多次 exec
调用之间记录和保持上下文状态。在正则引擎外部做貌似很难的样子（或许还有我不知道的专门的 PCRE API？）。

Best regards,
-agentzh

lancelijade

他自己不支持就在外面处理呢？比如在lua里给这个串记个状态什么呢？

Lance

2013/4/8 agentzh <age...@gmail.com>

Hello!

2013/4/7 Lance:

> 按我的理解，真正开销大的不是检查本身，而是反复检查。
>
> 在 ngx_http_lua_ngx_re_match 和 ngx_http_lua_ngx_re_gmatch_iterator 里都是通过调用
> ngx_http_lua_regex_exec 来进行实际匹配的，每次进行这个调用时，如果没有设置 PCRE_NO_UTF8_CHECK， pcre
> 会检查 offset 之前部分是否 utf8 合法，这在反复匹配中复杂度就成了指数级。
>

嗯，PCRE 貌似并不像我的 sregex 库那样原生支持这种增量式的全局匹配，各次 exec
之间它本质上是无状态的，所以它每次都需要重新验证和处理 offset 位置之前的相关状态。

> 如果不把这个参数暴露给用户，或者可以考虑在一个字符串第一次需要 utf8 匹配时使用某种方式来预处理，并记下成功标记，之后再次匹配时就可以直接使用
> PCRE_NO_UTF8_CHECK 了。
>

这个貌似需要修改 PCRE 本身，即让 PCRE 自己在多次 exec
调用之间记录和保持上下文状态。在正则引擎外部做貌似很难的样子（或许还有我不知道的专门的 PCRE API？）。

Best regards,

-agentzh

--

agentzh

Hello!

2013/4/7 Lance:
> 他自己不支持就在外面处理呢？比如在lua里给这个串记个状态什么呢？
>

对不起，我不明白你这里的意思 :)

在 Lua 里给字符串记状态如何影响 PCRE 的行为？这里的难点在于，让 PCRE 对 offset 之前的部分不进行 UTF-8
合法性检查，而对 offset 以后的部分仍进行合法性检查。这如何在 PCRE 的外部来做？请注意，ngx_lua 喂给 PCRE
的总是那个完整的大字符串，尝试匹配的起始位置是通过 offset 参数来控制的。

Regards,
-agentzh

lancelijade

我的意思是，假如整体字符串是 abcdef，在第一次送入pcre 进行 u 匹配之前，用ngx_lua 自己的方式（比如你说的c宏），对它进行utf8合法性检测，如果整个字符串没问题，在ngx_lua里以某种方式记录（这里我不确定是什么方法，md5太重了？），这样不管是本次匹配，还是再次被送进来时，不管偏移是什么，都可以直接用 pcre_exec( ...... PCRE_NO_UTF8_CHECK... ) 方式调用 pcre。即把 pcre 做的 utf8 合法性检测改由 ngx_lua 完成并缓存住。

Lance

2013/4/8 agentzh <age...@gmail.com>

Hello!

2013/4/7 Lance:
> 他自己不支持就在外面处理呢？比如在lua里给这个串记个状态什么呢？
>

对不起，我不明白你这里的意思 :)

在 Lua 里给字符串记状态如何影响 PCRE 的行为？这里的难点在于，让 PCRE 对 offset 之前的部分不进行 UTF-8
合法性检查，而对 offset 以后的部分仍进行合法性检查。这如何在 PCRE 的外部来做？请注意，ngx_lua 喂给 PCRE
的总是那个完整的大字符串，尝试匹配的起始位置是通过 offset 参数来控制的。

Regards,
-agentzh

--

lancelijade

http://www.pcre.org/pcre.txt

         PCRE_NO_UTF8_CHECK

       When PCRE_UTF8 is set, the validity of the pattern as a UTF-8 string is
       automatically  checked.  There  is  a  discussion about the validity of
       UTF-8 strings in the pcreunicode page. If an invalid UTF-8 sequence  is
       found,  pcre_compile()  returns an error. If you already know that your
       pattern is valid, and you want to skip this check for performance  rea-
       sons,  you  can set the PCRE_NO_UTF8_CHECK option.  When it is set, the
       effect of passing an invalid UTF-8 string as a pattern is undefined. It
       may  cause  your  program  to  crash. Note that this option can also be
       passed to pcre_exec() and pcre_dfa_exec(),  to  suppress  the  validity
       checking  of  subject strings only. If the same string is being matched
       many times, the option can be safely set for the second and  subsequent
       matchings to improve performance.

Lance

2013/4/8 Lance <lance...@gmail.com>

我的意思是，假如整体字符串是 abcdef，在第一次送入pcre 进行 u 匹配之前，用ngx_lua 自己的方式（比如你说的c宏），对它进行utf8合法性检测，如果整个字符串没问题，在ngx_lua里以某种方式记录（这里我不确定是什么方法，md5太重了？），这样不管是本次匹配，还是再次被送进来时，不管偏移是什么，都可以直接用 pcre_exec( ...... PCRE_NO_UTF8_CHECK... ) 方式调用 pcre。即把 pcre 做的 utf8 合法性检测改由 ngx_lua 完成并缓存住。

Lance

2013/4/8 agentzh <age...@gmail.com>
Hello!

2013/4/7 Lance:
> 他自己不支持就在外面处理呢？比如在lua里给这个串记个状态什么呢？
>

对不起，我不明白你这里的意思 :)

在 Lua 里给字符串记状态如何影响 PCRE 的行为？这里的难点在于，让 PCRE 对 offset 之前的部分不进行 UTF-8
合法性检查，而对 offset 以后的部分仍进行合法性检查。这如何在 PCRE 的外部来做？请注意，ngx_lua 喂给 PCRE
的总是那个完整的大字符串，尝试匹配的起始位置是通过 offset 参数来控制的。

Regards,
-agentzh

--

agentzh

Hello!

2013/4/7 Lance:
> 我的意思是，假如整体字符串是 abcdef，在第一次送入pcre 进行 u 匹配之前，用ngx_lua
> 自己的方式（比如你说的c宏），对它进行utf8合法性检测，如果整个字符串没问题，在ngx_lua里以某种方式记录（这里我不确定是什么方法，md5太重了？），这样不管是本次匹配，还是再次被送进来时，不管偏移是什么，都可以直接用
> pcre_exec( ...... PCRE_NO_UTF8_CHECK... ) 方式调用 pcre。即把 pcre 做的 utf8 合法性检测改由
> ngx_lua 完成并缓存住。
>

呃。。。原来你是想让 ngx_lua 自己来进行 UTF-8 合法性检查并让 ngx_lua 来做 memo……我不太确定把 UTF-8
合法性检查代码内置进 ngx_lua 核心是一个好主意，同时 memo 的生命期管理对 ngx_lua
来说也是一个较大的负担（特别是，这里还有 lua GC 需要协同）。我仍然觉得这种优化应当内置于正则引擎内部。

Regards,
-agentzh

lancelijade

ok，首先，我们确认现在碰到的是一个问题，需要解决，具体解决的位置，可以分成 pcre, ngx_lua 和 lua 三个不同的层次。

1. pcre 内部。因为能够确认是pcre反复进行合法性检测所导致的问题，所以直接关掉这个检测看起来是最直接的办法，比如添加一个 PCRE_NO_UTF8_BACKWARD_CHECK 选项，但因为 pcre 没有任何办法知道外部送入的文本是否合法，所以对 pcre_exec 来说，安全的默认选项只能是 0，需要把这个选项交给上层调用者来使用；

2. ngx_lua 层。在 ngx_lua 层，需要区别对待 re.gmatch 和 re.match 两个不同的调用的行为区别。

(1) 对 re.gmatch 来说，因为 iterator 的反复调用是可以预期的，所以使用 PCRE_NO_UTF8_BACKWARD_CHECK 参数调用 pcre_exec 是不错的选择，但出于安全性考虑，ngx_lua 只应该对已经调用过 pcre_exec 一次后再次调用的字符串使用此选择，故需要在内部对字符串加标记，姑且认为是 ctx->utf8_check=true；对 re.gmatch 来说，另外一个可行的办法是在 ngx_lua 内部进行一次性全字符串的utf8合法性检测，并记录标记比如 ctx->utf8_check_all=true，然后直接调用带 PCRE_NO_UTF8_CHECK 参数的 pcre_exec，这两个方法应该效率上没有本质区别。

(2) 对 re.match 来说，反复调用不是可预期的行为，所以一次性 utf8 安全检查显得比较重了，只能在调用一次 pcre_exec 后做 ctx->utf8_check 标记，大多数时候此标记是不会被再次使用的，在调用 pcre_exec 方面，没有标记时只能使用默认参数调用；这里存在一个潜在的问题，当用户使用 anchor 模式调用 re.match 并手工指定 ctx->pos 时，假如该字符串已经不是被第一次 match，ctx->utf8_check 标记已经被设置为 true，但 ctx->pos 被用户因为某种原因手工修改，比如从10改成了100，这样假如ngx_lua 根据 ctx->utf8_check标记的指示以 PCRE_NO_UTF8_BACKWARD_CHECK 方式调用 pcre_exec，字符串第 10 到第 99 字节是没有被检测过的，潜在的存在风险，导致 pcre_exec 行为不可预期；

3. lua 层。假如 ngx_lua 把送给 pcre 的这个选项交给用户选择，并把默认值设为 0 时。当用户明确的知道自己的数据是 utf8 安全的，可以直接使用 PCRE_NO_UTF8_CHECK 选项来安全关掉此检查；反过来，当用户不明确知道数据安全性时，可以有两个选择，一是通过 iconv 之类的工具确定数据安全性，或者使用默认选项来调用 re.match/gmatch，后一种选择应该是绝大多数情况，只有当用户明确需要考虑效率问题时，选择 iconv 再按照安全 utf8 调用 PCRE_NO_UTF8_CHECK 的 re.match/gmatch 效率是最高的。不管在哪种情况下，PCRE_NO_UTF8_BACKWARD_CHECK基本可以认为是多余的。

综上所述，采用方式3把选择交给用户是我认为最好的选择，需要做的调整就是在现有的 re.match/gmatch 函数中添加可以最终传递给 pcre_exec 的 PCRE_NO_UTF8_CHECK 选项，而 pcre 的修改并不需要。

谢谢观赏，累死我了。

Lance

2013/4/9 agentzh <age...@gmail.com>

Hello!

2013/4/7 Lance:

> 我的意思是，假如整体字符串是 abcdef，在第一次送入pcre 进行 u 匹配之前，用ngx_lua
> 自己的方式（比如你说的c宏），对它进行utf8合法性检测，如果整个字符串没问题，在ngx_lua里以某种方式记录（这里我不确定是什么方法，md5太重了？），这样不管是本次匹配，还是再次被送进来时，不管偏移是什么，都可以直接用
> pcre_exec( ...... PCRE_NO_UTF8_CHECK... ) 方式调用 pcre。即把 pcre 做的 utf8 合法性检测改由
> ngx_lua 完成并缓存住。
>

呃。。。原来你是想让 ngx_lua 自己来进行 UTF-8 合法性检查并让 ngx_lua 来做 memo……我不太确定把 UTF-8
合法性检查代码内置进 ngx_lua 核心是一个好主意，同时 memo 的生命期管理对 ngx_lua
来说也是一个较大的负担（特别是，这里还有 lua GC 需要协同）。我仍然觉得这种优化应当内置于正则引擎内部。

Regards,
-agentzh

--

agentzh

Hello!

2013/4/8 Lance:
> ok，首先，我们确认现在碰到的是一个问题，需要解决，具体解决的位置，可以分成 pcre, ngx_lua 和 lua 三个不同的层次。
>
[...]
>
> 3. lua 层。假如 ngx_lua 把送给 pcre 的这个选项交给用户选择，并把默认值设为 0 时。当用户明确的知道自己的数据是 utf8
> 安全的，可以直接使用 PCRE_NO_UTF8_CHECK 选项来安全关掉此检查；反过来，当用户不明确知道数据安全性时，可以有两个选择，一是通过
> iconv 之类的工具确定数据安全性，或者使用默认选项来调用
> re.match/gmatch，后一种选择应该是绝大多数情况，只有当用户明确需要考虑效率问题时，选择 iconv 再按照安全 utf8 调用
> PCRE_NO_UTF8_CHECK 的 re.match/gmatch
> 效率是最高的。不管在哪种情况下，PCRE_NO_UTF8_BACKWARD_CHECK基本可以认为是多余的。
>
> 综上所述，采用方式3把选择交给用户是我认为最好的选择，需要做的调整就是在现有的 re.match/gmatch 函数中添加可以最终传递给
> pcre_exec 的 PCRE_NO_UTF8_CHECK 选项，而 pcre 的修改并不需要。
>

好吧，那我们就添加一个 U 正则选项，表示不进行 UTF-8 合法性检查的 UTF-8 模式，与现有的 u 选项相对。你看如何？

欢迎贡献补丁 :)

Best regards,
-agentzh

lancelijade

方案不错，补丁我试试

Lance

2013/4/10 agentzh <age...@gmail.com>

Hello!

2013/4/8 Lance:

> ok，首先，我们确认现在碰到的是一个问题，需要解决，具体解决的位置，可以分成 pcre, ngx_lua 和 lua 三个不同的层次。
>

[...]

>
> 3. lua 层。假如 ngx_lua 把送给 pcre 的这个选项交给用户选择，并把默认值设为 0 时。当用户明确的知道自己的数据是 utf8
> 安全的，可以直接使用 PCRE_NO_UTF8_CHECK 选项来安全关掉此检查；反过来，当用户不明确知道数据安全性时，可以有两个选择，一是通过
> iconv 之类的工具确定数据安全性，或者使用默认选项来调用
> re.match/gmatch，后一种选择应该是绝大多数情况，只有当用户明确需要考虑效率问题时，选择 iconv 再按照安全 utf8 调用
> PCRE_NO_UTF8_CHECK 的 re.match/gmatch
> 效率是最高的。不管在哪种情况下，PCRE_NO_UTF8_BACKWARD_CHECK基本可以认为是多余的。
>
> 综上所述，采用方式3把选择交给用户是我认为最好的选择，需要做的调整就是在现有的 re.match/gmatch 函数中添加可以最终传递给
> pcre_exec 的 PCRE_NO_UTF8_CHECK 选项，而 pcre 的修改并不需要。
>

好吧，那我们就添加一个 U 正则选项，表示不进行 UTF-8 合法性检查的 UTF-8 模式，与现有的 u 选项相对。你看如何？

欢迎贡献补丁 :)

Best regards,

-agentzh

--

lancelijade

https://github.com/lancelijade/lua-nginx-module/commit/187c55503de8160a00745140ecc00c3347b96bcf

提交了pull request

Lance

2013/4/10 Lance <lance...@gmail.com>

方案不错，补丁我试试

Lance

2013/4/10 agentzh <age...@gmail.com>
Hello!

2013/4/8 Lance:

> ok，首先，我们确认现在碰到的是一个问题，需要解决，具体解决的位置，可以分成 pcre, ngx_lua 和 lua 三个不同的层次。
>

[...]

>
> 3. lua 层。假如 ngx_lua 把送给 pcre 的这个选项交给用户选择，并把默认值设为 0 时。当用户明确的知道自己的数据是 utf8
> 安全的，可以直接使用 PCRE_NO_UTF8_CHECK 选项来安全关掉此检查；反过来，当用户不明确知道数据安全性时，可以有两个选择，一是通过
> iconv 之类的工具确定数据安全性，或者使用默认选项来调用
> re.match/gmatch，后一种选择应该是绝大多数情况，只有当用户明确需要考虑效率问题时，选择 iconv 再按照安全 utf8 调用
> PCRE_NO_UTF8_CHECK 的 re.match/gmatch
> 效率是最高的。不管在哪种情况下，PCRE_NO_UTF8_BACKWARD_CHECK基本可以认为是多余的。
>
> 综上所述，采用方式3把选择交给用户是我认为最好的选择，需要做的调整就是在现有的 re.match/gmatch 函数中添加可以最终传递给
> pcre_exec 的 PCRE_NO_UTF8_CHECK 选项，而 pcre 的修改并不需要。
>

好吧，那我们就添加一个 U 正则选项，表示不进行 UTF-8 合法性检查的 UTF-8 模式，与现有的 u 选项相对。你看如何？

欢迎贡献补丁 :)

Best regards,

-agentzh

--