【问题标题】：Different return values in PHPPHP中的不同返回值
【发布时间】：2014-10-30 05:23:31
【问题描述】：

我正在调查与此问题相关的 another question。

我想知道为什么在使用 PHP >= 5.3.4 时使用 \p{L} 会导致 false 而在早期版本中使用 true？

print_r(preg_match("@^\d+\s+\p{L}+\s+\d+$@", "20 Août 2014"));

更新 #1

\p{L} 应该在 PCRE 8.30 到 8.34 中按预期工作，因为我可以在 RegexBuddy 等环境中进行测试：

所以从 PHP 5.4.14 (PCRE 8.30) 到 5.6 (PCRE 8.34) 应该实现相同的结果（因为我找不到对 PHP PCRE 包进行的任何自定义更改）：

根据@user1578653 answer，使用字母 Å 和 0xc5 十六进制代码会有不同的输出，但是 it won't (!) 但它 should match .

【问题讨论】：

可能是配置问题。我刚刚用 PHP 5.2.6、5.3.3.7 和 5.3.26 尝试过这个。他们都返回了false。
@squeamishossifrage 我不这么认为。它不应该返回0。对于最新的 PCRE 引擎来说，它确实是一个正确的令牌 regex101.com/r/iE3kS5/1
This 在 5.3.4 中已修复，但它似乎充其量只是切线相关。也许它修复了整体的 Unicode 处理？

【解决方案1】：

从 v 5.3.4 (http://php.net/ChangeLog-5.php) 的 PHP 更改日志看来，其中一项更改是它们“将捆绑的 PCRE 升级到版本 8.10。(Ilia)”。

PCRE v8.10 (http://www.pcre.org/changelog.txt) 的更新日志提到了有关 \p 修饰符的几件事，特别是第 12 点和第 15 点。也许这些与您的问题有关？

更新

我做了更多的测试，我认为这是造成差异的原因。 PCRE 变更日志中的第 15 点指出：

如果重复的 Unicode 属性匹配（例如 \p{Lu}*）与非 UTF-8 输入，如果字符有值，它可能会崩溃或给出错误的结果主题字符串中存在大于 0xc0 的值。（细节：假设处理这些项目时的 UTF-8 输入。）

如果您尝试用小于 unicode 0xc0 的任何字符替换您的 'û' 字符，您将在所有版本的 PHP 上得到相同的结果。如果您将该字符替换为等于或大于 0xc0 的任何字符，您将获得所看到的 PHP 版本之间的差异。所以肯定是这次PCRE库更新造成的！

【讨论】：