【发布时间】:2011-05-29 10:00:45
【问题描述】:
我有一个 PHP 库,它使用许多正则表达式,其中包含用于多字节字符串的 \P 表达式,例如
((((?:\P{M}\p{M}*)+?)|(\'[^\']*\')|(\"[^\"]*\"))!)?\$?([a-z]{1,3})\$?(\d+)
虽然这适用于大多数构建,但我有一些关于正则表达式返回错误的报告。
根据操作平台,来自 PCRE 的错误消息是:
编译失败:PCRE 在偏移 n 处不支持 \L、\l、\N、\P、\p、\U、\u 或 \X
或
编译失败:在偏移 n 处未编译对 \P、\p 和 \X 的支持
我知道我可以在我的代码开头测试一个使用\P 的正则表达式,并捕获返回的错误,然后使用该响应来设置兼容性标志并提供降级(非 UTF-8)基于该兼容性标志的代码主体中没有\P 的正则表达式。
我想知道是否有任何更简单的方法来确定 PCRE 是否在没有 --enable-unicode-properties 或 --enable-utf8 配置开关的情况下构建。 PHP 提供对PCRE_VERSION 常量的访问,但这无助于确定是否启用了\P 支持。
【问题讨论】:
-
我想知道如果您没有使用 utf8 支持进行编译,是否会定义
PREG_BAD_UTF8_OFFSET。检查未编译的平台上是否存在该常量(defined('PREG_BAD_UTF8_OFFSET');)。如果没有,请检查。如果是这样,您总是可以解析phpinfo(),但这并不便宜... -
phpinfo() 实际上并没有提供该信息...我已经检查过了。我将在我的一个测试服务器上进行新的 PCRE 构建,并针对它重建 PHP,以查看是否定义了 PREG_BAD_UTF8_OFFSET,如果我能够简单地测试定义的常量,这将为我的后备提供更简洁的替代方案。
-
好吧,既然PCRE是PHP自己编译的,不应该是PHP的配置选项吗? (意思是,它不应该出现在 Phpinfo 的
configure行中吗)?不过我可能错了…… -
@ircmaxell 你能把这个变成答案吗?
-
@ircmaxell,该常量称为 PREG_BAD_UTF8_OFFSET_ERROR(还有一个 PREG_BAD_UTF8_ERROR)而不是 PREG_BAD_UTF8_OFFSET