為什么\\ w匹配Mac OS X PHP環境中的非英文字符？

Question

我發現“\\ w”可以匹配我的Mac OS X PHP環境中的中文字符。 但是相同的代碼在Linux上不起作用。

php -r "echo preg_match('/^\w+$/','人1234', \$m).chr(10); var_dump(\$m);"

Mac OS X 11.11.3，PHP 5.6.18（cli），PHP 5.4.45（cli）結果

1
array(1) {
  [0] =>
  string(7) "人1234"
}

Cent OS 6，PHP 5.6.18（cli），PHP 5.2.17p1（cli）結果

0
array(0) {
}

PHP手冊說

字母和數字的定義由PCRE的字符表控制，如果發生特定於語言環境的匹配，則可能會有所不同。 例如，在“fr”（法語）語言環境中，一些大於128的字符代碼用於重音字母，並且這些字符代碼由\\ w匹配。“

我想有些東西鏈接到PCRE庫。 誰有人解釋原因？

Answer 1

是的，這完全是關於如何與PHP一起編譯PCRE：

pcre *pcre_compile(const char *pattern,
      int options,
      const char **errptr,
      int *erroffset,
      const unsigned char *tableptr); 

在這個函數中，負責將RegExes編譯成它們的內部形式， options參數是一個包含PCRE_UCP （UCP = Unicode字符屬性）的位列表，它允許\\w ， \\d和其他標記使用unicode屬性，而且它似乎是PHP的PCRE您的Mac OS X計算機上編譯此標志。

還有一個特殊的修飾符(*UCP)可以即時使用，即使你的PCRE沒有設置PCRE_UCP標志編譯，你也可以在運行時啟用這樣的選項。

例如/(*UCP)\\w+/匹配unicode字符。 （ 在線查看 ）

來自PCRE網站 ：

PCRE處理無外殼匹配，並通過引用由字符代碼點索引的一組表來確定字符是字母，數字還是其他。

在UTF-8模式或16位或32位庫中運行時，這僅適用於代碼點小於256的字符。默認情況下，較高值的代碼點永遠不會匹配轉義符，例如\\w或\\d 。

但是，如果PCRE是使用Unicode屬性支持構建的，則可以使用\\ p和\\ P測試所有字符，或者，可以在編譯模式時設置PCRE_UCP選項; 這會導致\\w和朋友使用Unicode屬性支持而不是內置表 。

不鼓勵使用帶有Unicode的語言環境。 如果要處理代碼點大於128的字符，則應使用Unicode支持，或使用區域設置，但不要嘗試將兩者混合使用。