我想你猜对了。实际上，UTF-8中有一些空格字符，它们不是US-ASCII的一部分。给你一个这样的空间的例子：

• Unicode字符’NO-BREAK SPACE’（U + 00A0）：UTF-8中的2个字节：0xC2 0xA0（c2a0）

也许也是如此：

• Unicode字符’NEXT LINE（NEL）’（U + 0085）：UTF-8中的2个字节：0xC2 0x85（c285）
• Unicode字符’LINE SEPARATOR’（U + 2028）：UTF-8中的3个字节：0xE2 0x80 0xA8（e280a8）
• Unicode字符’PARAGRAPH SEPARATOR’（U + 2029）：UTF-8中的3个字节：0xE2 0x80 0xA8（e280a8）

无论如何，第一个-‘NO-BREAK SPACE’（U + 00A0）-是一个很好的例子，因为它也是Latin-
X字符集的一部分。并且PHP手册已经提供了一个提示，该提示str_word_count 将 取决于语言环境。

如果要对此进行测试，可以将语言环境设置为UTF-8，传入包含\xA0序列的无效字符串，并且如果该字符串仍视为断字字符，则该函数显然不是UTF-8安全的，因此不是多字节安全的（根据问题未定义相同）：

<?php
/**
 * is PHP str_word_count() multibyte safe?
 * @link https://stackoverflow.com/q/8290537/367456
 */

echo 'New Locale: ', setlocale(LC_ALL, 'en_US.utf8'), "\n\n";

$test   = "aword\xA0bword aword";
$result = str_word_count($test, 2);

var_dump($result);

输出：

New Locale: en_US.utf8

array(3) {
  [0]=>
  string(5) "aword"
  [6]=>
  string(5) "bword"
  [12]=>
  string(5) "aword"
}

如本演示所示，该功能完全无法在手册页上给出的语言环境中保证（我不奇怪也不会抱怨，通常情况下，如果您读到某个函数是PHP特定于语言环境的，就可以终身运行并找到一个（不是），我在这里利用它来证明它绝不对UTF-8字符编码做任何事情。

PCRE特别对PHP中的Unicode和UTF-8有很好的了解。如果您精心制作正则表达式模式，也可能会很快。