mb strlen php utf 8
Функция strlen в php
Покажет количество байт в два раза больше, чем элементов!
Синтаксис функции strlen
Для понимания работы функции strlen нам понадобится несколько примеров:
Функция strlen и число в php
Для иллюстрации работы функции и получения результатов, нам потребуется функция var_dump в том числе, но давайте все по порядку.
Нам нужно число, над которым мы будем проводить наши изыскания!
Пусть это будет «123456»
Оборачиваем это число в функцию strlen:
Результат вывода длины числа через strlen:
Далее(для общего развития), чтобы узнать возвращаемые данные и тип переменной обернем эту конструкцию в var_dump и выведем с помощью echo
Вывод число(int) и strlen, что с числом, изначально имеющий тип int вернет тип «int» и значение «6», количество байт равно количеству символов.
Функция strlen и число(тип string) в php
Передадим в функцию strlen число тип string
Следующий эксперимент, передадим в функцию число с типом «string», если мы помести число в кавычки, то это уже будет строка, а не число, например давайте получим результат var_dump(‘123456’); :
Теперь эту строку поместим в strlen. Мы выяснили, что данное число имеет тип string, пропустим данные через strlen echo strlen(‘123456’) :
Узнаем тип возвращенных данных echo var_dump(strlen(‘123456’)); :
Вывод число(string) и strlen, что с числом, изначально имеющий тип string вернет тип «int» и значение «6», количество байт равно количеству символов.
Strlen и строка(тип string) utf-8 в php
Мы узнали, что эта строка, следующим действием пропустим эту строку через strlen:
echo strlen(‘Привет’) :
Логично было предположить, что функция вернет значение такое же как и var_dump. Теперь проверим тип возвращенных данных.
var_dump( strlen (‘Привет’) );
Вывод строка(string) и strlen, что со строкой, изначально имеющий тип string вернет тип «int» и значение «12», количество байт НЕ равно количеству символов.
кириллица + utf-8 и strlen
Это можно сделать так:
echo strlen(iconv(«UTF-8», «windows-1251», «Привет»));
Функции для работы с многобайтовыми строками
Схемы многобайтного кодирования символов и их реализации достаточно сложны, и их описание находится за пределами этой документации. Более исчерпывающую информацию о кодировках и их устройстве можно почерпнуть из нижеприведённых источников.
Материалы по Юникоду
Информация о символах японской/корейской/китайской кодировок
Содержание
User Contributed Notes 35 notes
Please note that all the discussion about mb_str_replace in the comments is pretty pointless. str_replace works just fine with multibyte strings:
= ‘漢字はユニコード’ ;
$needle = ‘は’ ;
$replace = ‘Foo’ ;
?>
The usual problem is that the string is evaluated as binary string, meaning PHP is not aware of encodings at all. Problems arise if you are getting a value «from outside» somewhere (database, POST request) and the encoding of the needle and the haystack is not the same. That typically means the source code is not saved in the same encoding as you are receiving «from outside». Therefore the binary representations don’t match and nothing happens.
PHP can input and output Unicode, but a little different from what Microsoft means: when Microsoft says «Unicode», it unexplicitly means little-endian UTF-16 with BOM(FF FE = chr(255).chr(254)), whereas PHP’s «UTF-16» means big-endian with BOM. For this reason, PHP does not seem to be able to output Unicode CSV file for Microsoft Excel. Solving this problem is quite simple: just put BOM infront of UTF-16LE string.
SOME multibyte encodings can safely be used in str_replace() and the like, others cannot. It’s not enough to ensure that all the strings involved use the same encoding: obviously they have to, but it’s not enough. It has to be the right sort of encoding.
UTF-8 is one of the safe ones, because it was designed to be unambiguous about where each encoded character begins and ends in the string of bytes that makes up the encoded text. Some encodings are not safe: the last bytes of one character in a text followed by the first bytes of the next character may together make a valid character. str_replace() knows nothing about «characters», «character encodings» or «encoded text». It only knows about the string of bytes. To str_replace(), two adjacent characters with two-byte encodings just looks like a sequence of four bytes and it’s not going to know it shouldn’t try to match the middle two bytes.
While real-world examples can be found of str_replace() mangling text, it can be illustrated by using the HTML-ENTITIES encoding. It’s not one of the safe ones. All of the strings being passed to str_replace() are valid HTML-ENTITIES-encoded text so the «all inputs use the same encoding» rule is satisfied.
The text is «x = ‘x ;
mb_internal_encoding ( ‘HTML-ENTITIES’ );
?>
Even though neither ‘l’ nor ‘;’ appear in the text «x y» and in the other it broke the encoding completely.
One more reason to use UTF-8 if you can, I guess.
Yet another single-line mb_trim() function
PHP5 has no mb_trim(), so here’s one I made. It work just as trim(), but with the added bonus of PCRE character classes (including, of course, all the useful Unicode ones such as \pZ).
WEB IT blog
Блог про веб-разработку, администрирование, дизайн
понедельник, 21 июня 2010 г.
Давайте попробуем вывести рузультаты кода
Все правильно, русские символы занимают 2 байта, а английские 1.
Но нам надо унифицированно проверять длину входящей строки. Ответ прост:
Главное, чтобы входящая строка была действительно в utf-8
16 коммент.:
Спасибо большое за такую простую статью! Пол часа бился над проблемой, а решение оказывается такое простое 🙂
Не забывайте, что BOM (byte order mark) тоже считается за символы в строке, соответствующим образом изменяя ее длину.
Cyrill, ну именно поэтому все стараются сохранять файлы в UTF-8 без BOM. )
Для проверки кодировки существует функция mb_detect_encoding
Огромное Спасибо! Коротко,понятно и главное очень полезно!)
Поздравляю, вы — балбесы.
и после этого mb_strlen и прочие начинают работать так, как ДОЛЖНЫ.
Аноним, а в чем балбесность-то?
Никакого костыля предложено не было, все в порядке. Ваш вариант, конечно же, тоже верный.
mb_strlen
(PHP 4 >= 4.0.6, PHP 5, PHP 7, PHP 8)
mb_strlen — Получает длину строки
Описание
Получает длину строки ( string ).
Список параметров
Строка ( string ), для которой измеряется длина.
Возвращаемые значения
Ошибки
Список изменений
Смотрите также
User Contributed Notes 7 notes
Speed of mb_strlen varies a lot according to specified character set.
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.
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.
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.
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:
2. Iterating through a string’s characters:
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.
strlen
(PHP 4, PHP 5, PHP 7, PHP 8)
strlen — Возвращает длину строки
Описание
Список параметров
Строка ( string ), для которой измеряется длина.
Возвращаемые значения
Примеры
Пример #1 Пример использования strlen()
Примечания
Функция strlen() возвратит количество байт, а не число символов в строке.
Смотрите также
User Contributed Notes 8 notes
I want to share something seriously important for newbies or beginners of PHP who plays with strings of UTF8 encoded characters or the languages like: Arabic, Persian, Pashto, Dari, Chinese (simplified), Chinese (traditional), Japanese, Vietnamese, Urdu, Macedonian, Lithuanian, and etc.
As the manual says: «strlen() returns the number of bytes rather than the number of characters in a string.», so if you want to get the number of characters in a string of UTF8 so use mb_strlen() instead of strlen().
// the Arabic (Hello) string below is: 59 bytes and 32 characters
$utf8 = «السلام علیکم ورحمة الله وبرکاته!» ;
The easiest way to determine the character count of a UTF8 string is to pass the text through utf8_decode() first:
We just ran into what we thought was a bug but turned out to be a documented difference in behavior between PHP 5.2 & 5.3. Take the following code example:
?>
This is because in 5.2 strlen will automatically cast anything passed to it as a string, and casting an array to a string yields the string «Array». In 5.3, this changed, as noted in the following point in the backward incompatible changes in 5.3 (http://www.php.net/manual/en/migration53.incompatible.php):
«The newer internal parameter parsing API has been applied across all the extensions bundled with PHP 5.3.x. This parameter parsing API causes functions to return NULL when passed incompatible parameters. There are some exceptions to this rule, such as the get_class() function, which will continue to return FALSE on error.»
So, in PHP 5.3, strlen($attributes) returns NULL, while in PHP 5.2, strlen($attributes) returns the integer 5. This likely affects other functions, so if you are getting different behaviors or new bugs suddenly, check if you have upgraded to 5.3 (which we did recently), and then check for some warnings in your logs like this:
strlen() expects parameter 1 to be string, array given in /var/www/sis/lib/functions/advanced_search_lib.php on line 1028
If so, then you are likely experiencing this changed behavior.
When checking for length to make sure a value will fit in a database field, be mindful of using the right function.
There are three possible situations:
1. Most likely case: the database column is UTF-8 with a length defined in unicode code points (e.g. mysql varchar(200) for a utf-8 database).
Find the character set used, and pass it explicitly to the length function.
There’s a LOT of misinformation here, which I want to correct! Many people have warned against using strlen(), because it is «super slow». Well, that was probably true in old versions of PHP. But as of PHP7 that’s definitely no longer true. It’s now SUPER fast!
I created a 20,00,000 byte string (
20 megabytes), and iterated ONE HUNDRED MILLION TIMES in a loop. Every loop iteration did a new strlen() on that very, very long string.
The result: 100 million strlen() calls on a 20 megabyte string only took a total of 488 milliseconds. And the strlen() calls didn’t get slower/faster even if I made the string smaller or bigger. The strlen() was pretty much a constant-time, super-fast operation
So either PHP7 stores the length of every string as a field that it can simply always look up without having to count characters. Or it caches the result of strlen() until the string contents actually change. Either way, you should now never, EVER worry about strlen() performance again. As of PHP7, it is super fast!
Here is the complete benchmark code if you want to reproduce it on your machine: