О «шаблонном ответе» - я не получаю требование «работать быстрее».Мы не говорим о длинных или многократных подсчетах, поэтому кого это волнует, если это займет несколько миллисекунд или нет?
Однако str_word_count работает с мягким дефисом:
function my_word_count($str) {
return str_word_count(str_replace("\xC2\xAD",'', $str));
}
функция, которая соответствует утверждениям (но, вероятно, не быстрее, чем str_word_count):
function my_word_count($str) {
$mystr = str_replace("\xC2\xAD",'', $str); // soft hyphen encoded in UTF-8
return preg_match_all('~[\p{L}\'\-]+~u', $mystr); // regex expecting UTF-8
}
Функция preg по сути та же самая, что уже предложена, за исключением того, что а) она уже возвращает счетчик, так что нет необходимостипоставьте совпадения, которые должны сделать это быстрее и б) действительно не должно быть аварийного восстановления iconv, IMO.
Об комментарии:
Я вижу, что ваш PCRE функционируетwrost (производительность), чем мой preg_word_count (), потому что нужен str_replace, который вам не нужен: '~ [^ \ p {L} \' - \ xC2 \ xAD] + ~ u 'отлично работает (!).
Я считал, что другая вещь , замена строки удалит только многобайтовый символ, но ваше регулярное выражение будет иметь дело с \\xC2 и \\xAD в любом порядке, в котором они могут появиться, чтонеправильно.Рассмотрим зарегистрированный знак , который является \ xC2 \ xAE.
Однако теперь, когда я думаю об этом из-за того, как работает действующий UTF-8, это не будет иметь большого значения, поэтомуэто должно быть использовано одинаково хорошо.Таким образом, мы можем просто иметь функцию
function my_word_count($str) {
return preg_match_all('~[\p{L}\'\-\xC2\xAD]+~u', $str); // regex expecting UTF-8
}
без необходимости совпадений или других замен.
О str_word_count (str_replace ("\ xC2 \ xAD", '', $str)) ;, если стабильно с UTF8, это хорошо, но кажется не .
Если вы прочитаете эту ветку , вы будете знать,str_replace безопасен, если вы придерживаетесь правильных строк UTF-8.Я не видел никаких доказательств в вашей ссылке об обратном.