Mb strlen utf 8

Программисты работающие на языке php наверняка сталкивались с проблемой не корректной работы функции strlen предназначенной для подсчёта количества символов в строке. Иногда она даёт точное количество символов в строке, а иногда ошибается. Проблема здесь заключается в том, что функция strlen не всегда корректно обрабатывает кириллические символы, в то время как раскладку английского языка она всегда отрабатывает абсолютно точно.

Для того что бы разобраться, что на самом деле происходит, давайте рассмотрим работу функции strlen на очень простом примере:

Присвоим переменной $str два значения в первом случае это будет строка привет на русском языке, а во втором случае это будет строка privet на английском языке.

= ‘привет’ ;
echo strlen ( $str ); // Ответ должен быть: 6

echo ‘
‘ ;

$str = ‘privet’ ;
echo strlen ( $str ); // Ответ должен быть: 6
?>

На первый взгляд, совершенно очевидно, что как в первом, так и во втором случае при отработке данного кода, мы увидим на экране ответ, что в обеих строках число символов равно 6-ти. Но на самом деле — это не так! После обработки функцией strlen(); строки на русском языке, мы увидим число 12-ть (хотя там может быть и иное число), а вот после обработки функцией strlen(); строки на английском языке, мы действительно увидим число 6-ть.

Что бы избавиться от подобной неопределённости, следует использовать функцию mb_strlen(); которая так же вычисляет длину строки, но использует два параметра. Первый параметр – это переменная содержащая строку, длину которой следует определить, а второй – это кодировка той самой строки.

Давайте рассмотрим приведённый выше пример, но на этот раз в качестве функции, вычисляющей длину строки будем использовать mb_strlen(); :

= ‘привет’ ;
echo mb_strlen ( $str , ‘utf-8’ ); // Ответ должен быть: 6

echo ‘
‘ ;

$str = ‘privet’ ;
echo mb_strlen ( $str , ‘utf-8’ ); // Ответ должен быть: 6
?>

В данном случае, мы так же определяем количество символов в обеих строках, но помимо переменной $str в качестве параметра передаём ещё и кодировку utf-8 . Теперь при вычислении количества символов обеих строк мы получим число 6-ть. Что соответствует действительности. Так что при определении количества символов в строке, написанной на кириллице следует использовать функцию mb_strlen() , а не strlen() .

Читайте также:  Php json decode online

(PHP 4 >= 4.0.6, PHP 5, PHP 7)

mb_strlen — Получает длину строки

Описание

Получает длину строки ( string ).

Список параметров

Строка ( string ), для которой измеряется длина.

Параметр encoding представляет собой символьную кодировку. Если он опущен, вместо него будет использовано значение внутренней кодировки.

Возвращаемые значения

Возвращает количество символов в строке ( string ) str , имеющих кодировку символов encoding . Многобайтовый символ вычисляется как 1.

Ошибки

Если кодировка неизвестна, генерируется ошибка уровня E_WARNING .

Смотрите также

  • mb_internal_encoding() — Установка/получение внутренней кодировки скрипта
  • grapheme_strlen() — Get string length in grapheme units
  • iconv_strlen() — Возвращает количество символов в строке
  • strlen() — Возвращает длину строки

User Contributed Notes 7 notes

If you are unsure about what $encoding can be set to, here’s a full list of all the encodings supported by this extension:

Speed of mb_strlen varies a lot according to specified character set.

If you need length of string in bytes (strlen cannot be trusted anymore because of mbstring.func_overload) you should use ( $string , ‘8bit’ ); ?> .
It’s the fastest way (still a way slower than strlen, though) to determine byte length of string. Other single byte character sets (ASCII, ISO-8859-1, . ) are several times slower than 8bit.

Just did a little benchmarking (1.000.000 times with lorem ipsum text) on the mbs functions

especially mb_strtolower and mb_strtoupper are really slow (up to 100 times slower compared to normal functions). Other functions are alike-ish, but sometimes up to 5 times slower.

just be cautious when using mb_ functions in high frequented scripts.

# test runs: 1000000
# benchmarking strlen vs. mb_strlen
# normal strlen: 3.6795361042023 ms, average: 3.6795361042023E-6 ms
# mb_strlen: 5.5934538841248 ms, average: 5.5934538841248E-6 ms
ok 1 — mb_strlen is slower than strlen
# mb_strlen is 1.52 slower than strlen
#
#
# benchmarking strpos vs. mb_strpos
# normal strpos: 5.5523281097412 ms, average: 5.5523281097412E-6 ms
# mb_strlen: 31.180974960327 ms, average: 3.1180974960327E-5 ms
ok 2 — mb_strlen is slower than strlen
# mb_strpos is 5.62 slower than strpos
#
#
# benchmarking substr vs. mb_substr
# normal substr: 3.4437320232391 ms, average: 3.4437320232391E-6 ms
# mb_strlen: 3.5374181270599 ms, average: 3.5374181270599E-6 ms
ok 3 — mb_strlen is slower than strlen
# mb_substr is 1.03 slower than substr
#
#
# benchmarking strtolower vs. mb_strtolower
# normal strtolower: 4.446839094162 ms, average: 4.446839094162E-6 ms
# mb_strlen: 193.44901108742 ms, average: 0.00019344901108742 ms
ok 4 — mb_strlen is slower than strlen
# mb_strtolower is 43.5 slower than strtolower
#
#
# benchmarking strtoupper vs. mb_strtoupper
# normal strtoupper: 3.0210740566254 ms, average: 3.0210740566254E-6 ms
# mb_strlen: 340.71775603294 ms, average: 0.00034071775603294 ms
ok 5 — mb_strlen is slower than strlen
# mb_strtoupper is 112.78 slower than strtoupper

Читайте также:  Транспортная задача метод потенциалов калькулятор

It may not be clear whether PHP actually supports utf-8, which is the current de facto standard character encoding for Web documents, which supports most human languages. The good news is: it does.

I wrote a test program which successfully reads in a utf-8 file (without BOM) and manipulates the characters using mb_substr, mb_strlen, and mb_strpos (mb_substr should normally be avoided, as it must always start its search at character position 0).

The results with a variety of Unicode test characters in utf-8 encoding, up to four bytes in length, were mostly correct, except that accent marks were always mistakenly treated as separate characters instead of being combined with the previous character; this problem can be worked around by programming, when necessary.

If you find yourself without the mb string functions and can’t easily change it, a quick hack replacement for mb_strlen for utf8 characters is to use a a PCRE regex with utf8 turned on.

This is basically an ugly hack which counts all single character matches, and I’d expect it to be painfully slow on large strings.

Thank you Peter Albertsson for presenting that!

After spending more than eight hours tracking down two specific bugs in my mbstring-func_overloaded environment I have learned a very important lesson:

Many developers rely on strlen to give the amount of bytes in a string. While mb-overloading has very many advantages, the most hard-spotted pitfall must be this issue.

Two examples (from the two bugs found earlier):

1. Writing a string to a file:

= "string with utf-8 chars åèä — doo-bee doo-bee dooh" ;
$fp = fopen ( $this -> _file , "wb" );
if ( $fp ) <
$len = strlen ( $str );
fwrite ( $fp , $str , $len );
>
?>

PS This is found i the PEAR::Cache_Lite package (Lite.php) — Reported

2. Iterating through a string’s characters:

= "string with utf-8 chars åèö — doo-bee doo-bee dooh" ;
$newStr = "" ;
for ( $i = 0 ; $i strlen ( $str ); $i ++) <
$newStr .= $str [ $i ];
>
?>

Читайте также:  Как освободить место linux

Both of these situations will fail to save / store the last characters in $str. This can be very hard to spot and can be especially fatal for say serialized strings, xml etc.

So, try to avoid these situations to support overloaded environments, and remeber Peter Albertssons remark if you find problems under such an environment.

I have been working with some funny html characters lately and due to the nightmare in manipulating them between mysql and php, I got the database column set to utf8, then store characters with html enity "ọ" as ọ in the database and set the encoding on php as "utf8".

This is where mb_strlen became more useful than strlen. While strlen(‘ọ’) gives result as 3, mb_strlen(‘ọ’,’UTF-8′) gives 1 as expected.

But left(column1,1) in mysql still gives wrong char for a multibyte string. In the example above, I had to do left(column1,3) to get the correct string from mysql. I am now about to investigate multibyte manipulation in mysql.

Блог про веб-разработку, администрирование, дизайн

понедельник, 21 июня 2010 г.

Давайте попробуем вывести рузультаты кода
Все правильно, русские символы занимают 2 байта, а английские 1.
Но нам надо унифицированно проверять длину входящей строки. Ответ прост:

Главное, чтобы входящая строка была действительно в utf-8

16 коммент.:

Спасибо большое за такую простую статью! Пол часа бился над проблемой, а решение оказывается такое простое 🙂

Не забывайте, что BOM (byte order mark) тоже считается за символы в строке, соответствующим образом изменяя ее длину.

Cyrill, ну именно поэтому все стараются сохранять файлы в UTF-8 без BOM. )

Как проверить что строка действительно в UTF-8 ?

Для проверки кодировки существует функция mb_detect_encoding

Огромное Спасибо! Коротко,понятно и главное очень полезно!)

Поздравляю, вы — балбесы.

и после этого mb_strlen и прочие начинают работать так, как ДОЛЖНЫ.

Аноним, а в чем балбесность-то?
Никакого костыля предложено не было, все в порядке. Ваш вариант, конечно же, тоже верный.