我想你猜对了。实际上，UTF-8中有一些空格字符，它们不是US-ASCII的一部分。给你一个这样的空间的例子：
- Unipre字符’NO-BREAK SPACE’（U + 00A0）：UTF-8中的2个字节：0xC2 0xA0（c2a0）
也许也是如此：
- Unipre字符’NEXT LINE（NEL）’（U + 0085）：UTF-8中的2个字节：0xC2 0x85（c285）
- Unipre字符’LINE SEPARATOR’（U + 2028）：UTF-8中的3个字节：0xE2 0x80 0xA8（e280a8）
- Unipre字符’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安全的，因此不是多字节安全的（根据问题未定义相同）：
<?phpecho 'New Locale: ', setlocale(LC_ALL, 'en_US.utf8'), "nn";$test = "awordxA0bword aword";$result = str_word_count($test, 2);var_dump($result);
输出：
New Locale: en_US.utf8array(3) { [0]=> string(5) "aword" [6]=> string(5) "bword" [12]=> string(5) "aword"}如本演示所示，该功能完全无法在手册页上给出的语言环境中保证（我不奇怪也不会抱怨，通常情况下，如果您读到某个函数是PHP特定于语言环境的，就可以终身运行并找到一个（不是），我在这里利用它来证明它绝不对UTF-8字符编码做任何事情。
PCRE特别对PHP中的Unipre和UTF-8有很好的了解。如果您精心制作正则表达式模式，也可能会很快。
