Добрый вечер. Сегодня созрел интересный вопрос. А как лучше проводить валидацию input?
Например мне необходимо чтобы остались только русские буквы и всё. Варианты:
1. Регуляркой;
2. По символьно (массив символов).
Что из этого быстрее и качественнее? Может есть ещё способ менее затратный по ресурсам?
Поделитесь опытом.

Любым удобным для Вас способом. Нужно сделать на клиенте и на сервере. На сервере обязательно.

Это то понятно) Просто у меня друг хранит в массиве весь алфавит и разрешенные символы и входящую строку сравнивает. Регулярка требовательна к ресурсам.

Берите профилировщик и сравните. Что быстрее, вызов скомпилированной libpcre или userspace реализация. Замечательное место где можно сильно просесть алгоритмически и не заметить - как выбирается следующий символ сравниваемой строки.

Не совсем понял, в каком месте просесть можно алгоритмически?

Для 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.

т.е. когда я беру символ и сравниваю именно как символ и знаю что символ в utf-8 php всё равно не понимает его код? Он всегда сравнивает по битно? И что значит utf-8, что резиновая? utf-16 2 я так понимаю строго 2 байта = 16 бит.

Не понял вопроса.


Побайтово.
zend движок я не знаю, не покажу место в исходнике.


Да, от 1 до 4 байт на символ. Есть ли следующий байт для этого символа определяется по крайнему биту каждого байта.
По старому стандарту в UTF8 было от 1 до 6 байт, потом отпилили до 4 байт максимум.


Нет. Бывает 16 или 32 бита на символ.
Постоянную ширину из UTF имеет только UTF32, где символ всегда занимает 4 байта.

Кстати, 4 байт юникода вполне используется в жизни всякими смартфонами под смайлики. От чего интересные грабли собирали пользователи mysql, где utf8 кодировка не может хранить 4 байт, только максимум 3 на символ. Поэтому в mysql появилась utf8mb4, в 5.5 помнится.

Как происходит сравнения символов? Например вот так: