Это байты в распространённой hex записи.
Пользуясь какой-нибудь таблицей кодирования можно попробовать представить в виде символов.
Для utf8 это будет один символ т, для cp1251 - строка из двух символов: "С‚", строка "Ń‚" в cp1250 и так далее по куче разных кодировок с различным эффектом.
Doox911 пишет:
Не совсем понял что за d0 b0:
Тоже байты в hex виде. Без \x и с пробелами обычно читается легче человеком.
Строгое сравнение IS_IDENTICAL опкода приходит сюда: https://github[dot]com/php/php-src/b[dot][dot][dot]perators[dot]c#L2112
Что видим:
- проверка на типы в самом начале
- если обе строки показывают в одно место в памяти - то они идентичны и можно не сравнивать
- иначе сравниваем их длины в байтах
- если длина идентичная, то дёргаем стандартную C функцию memcmp по байтовому сравнению участка памяти двух указателей с указанной длиной.
Unicode - да, стандарт.
Кодировки UTF8, UTF16, UTF32 - возможные представления этого стандарта.
Зависит от того что считать корректным. С точки зрения механики - все результаты корректны.
Мелкий пишет:
var_dump(preg_match("~[абв]~", "где"));
Обозначу для краткости символы:
а состоит из байтов 1 и 2 (реально d0 b0)
б - 1 и 3 (d0 b1)
в - 1 и 4 (d0 b2)
г - 1 и 5 (d0 b3)
д - 1 и 6 (d0 b4)
е - 1 и 7 (d0 b5)
да, d0 у них у всех реально совпадает. В итоге получаем без модификатора u выражение:
Именно так, сравниваем байты, в символьной маске не 3 объекта для сравнения, а 6, из них 3 одинаковые. Есть у нас байт 1? Есть, потому и получаем совпадение.
С модификатором u рассматриваем именно символы, потому в символьной маске будет только 3 объекта. И соответственно отсутствие совпадения.
Doox911 пишет:
при перемене мест символов?
При перемене мест байт. Я специально воспользовался hex записью чтобы проиллюстрировать и дописал комментарий, что такая изменённая последовательность байт вообще недопустима в utf8.
т.е. когда я беру символ и сравниваю именно как символ и знаю что символ в utf-8 php всё равно не понимает его код?
Не понял вопроса.
Doox911 пишет:
Он всегда сравнивает по битно?
Побайтово.
zend движок я не знаю, не покажу место в исходнике.
Doox911 пишет:
И что значит utf-8, что резиновая?
Да, от 1 до 4 байт на символ. Есть ли следующий байт для этого символа определяется по крайнему биту каждого байта.
По старому стандарту в UTF8 было от 1 до 6 байт, потом отпилили до 4 байт максимум.
Doox911 пишет:
utf-16 2 я так понимаю строго 2 байта = 16 бит.
Нет. Бывает 16 или 32 бита на символ.
Постоянную ширину из UTF имеет только UTF32, где символ всегда занимает 4 байта.
Кстати, 4 байт юникода вполне используется в жизни всякими смартфонами под смайлики. От чего интересные грабли собирали пользователи mysql, где utf8 кодировка не может хранить 4 байт, только максимум 3 на символ. Поэтому в mysql появилась utf8mb4, в 5.5 помнится.
Для UTF8 как представителя кодировки с переменной шириной символа в принципе нет возможности взять произвольный i-тый символ строки без просмотра всех символов от 0 до i, что ожидаемо даёт замедление алгоритма.
Поясню как раз на замечательном примере из другой вашей темы: http://forum.php.su/topic.php?fo...87399#1531887399
Ваш алгоритм некорректно обрабатывает символы utf8. Но сама идея байтового обхода исходной строки при этом корректна.
Пример armancho7777777 получит замедление потому что в принципе невозможно получать offset в mb_substr без полного просмотра этого самого offset. На каждой итерации цикла.
Корректно обходить кодировки переменной длины - это взять следующий байт строки, если это не полный символ кодировки - брать следующие байты. Когда собрали символ - сверять полученный символ с заданной символьной маской. Если есть совпадение, то берём следующий байт и собираем новый символ и проверяем уже его. Если не совпали - ура, выходим, под шаблон строка не подпадает. Именно так работает PCRE и вообще конечные автоматы регулярных выражений.
В возможность корректно обойти utf8 в userspace php и обогнать элементарную регулярку - я не верю. Проверять лениво, много граблей обходить надо. А производительность libpcre в PHP ещё и весьма непросто корректно проверять из-за кеша регулярок в нескромные 4096 штук. Ёпт, а там ещё и JIT включен уже может быть. Это без вариантов, по крайней мере пока для userspace не прикрутят JIT.
Становится очевидно, почему ^т$ и ^[т]$ ведут себя различно в зависимости от u?
Сравниваем байты или символы. Маленькая разница, небольшие но важные изменения. (Добавление)
Ну и маленький выдуманный пример, проверим, что в строке есть хотя бы одна буква а, б или в:
Берите профилировщик и сравните. Что быстрее, вызов скомпилированной libpcre или userspace реализация. Замечательное место где можно сильно просесть алгоритмически и не заметить - как выбирается следующий символ сравниваемой строки.
Ммм, а вы вообще что-нибудь по синтаксису регулярок читали?
1. модификаторы
2. какую кавычку?
3. Это два разных спецсимвола, и их объясняют буквально в любом руководстве. Это не рекурсивная регулярка, а совершенно базовые вещи. + - сокращение для {1,}, $ - конец строки
Сильно зависит от сложности нужного форматирования.
Можно взять headless браузер и воспользоваться его рендером - phantomjs например. Сумеет нарисовать соответственно всё как десктопный браузер.
Или выбирать что-то под определённые хотелки. В html всё-таки много чего есть.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 11869
