PHP-вопрос

[harinalex]

И тогда функция вернёт истину на любой набор символов хоть с одной цифрой (если я не ошибаюсь)
Вот за то и не люблю регулярные, что можно написать такого, что сам потом не разберёшь.
Но, конечно, это только отмазка, чтобы мозг не ломать "китайской грамотой".
Если знать их хорошо и функции которые с ними работают, то инструмент мощнейший.

нет , только этот диапазон цифр

[Mirnyi]

нет , только этот диапазон цифр

int preg_match (string pattern, string subject [, array matches [, int flags]])

Ищет в subject совпадения с регулярным выражением, заданным в pattern.

Если matches предоставлен, он заполняется результатами поиска. $matches[0] будет содержать текст, совпавший со всем патэрном, $matches[1] будет содержать текст, совпавший первым захваченным субпатэрном в скобках, и так далее.

Или я ничего не понимаю, или встретив одну цифру в subject, эта функция вернёт не 0, т.е. истину.
Т.е., можно и такую маску задать, но тогда нужно менять условия или инклюдить уже не переменную, а результаты функции (которые ещё выбрать нужно правильно).
Т.е., кроме самого регулярника нужно ещё учитывать что же оно реально делает в функции.

[harinalex]

Или я ничего не понимаю, или встретив одну цифру в subject, эта функция вернёт не 0, т.е. истину.
Т.е., можно и такую маску задать, но тогда нужно менять условия или инклюдить уже не переменную, а результаты функции (которые ещё выбрать нужно правильно).
Т.е., кроме самого регулярника нужно ещё учитывать что же оно реально делает в функции.

мне функция preg_match не нравится , имхо для таких целей лучше preg_match_all использовать , она не остановится после первого нахождения.
мне больше по душе htmlspecialchars(preg_replace("/[^1-9]/"),"",$id)


В общем , надо память освежить - пошел читать http://php.net/

[DogEater]

Или я ничего не понимаю, или встретив одну цифру в subject, эта функция вернёт не 0, т.е. истину.
Т.е., можно и такую маску задать, но тогда нужно менять условия или инклюдить уже не переменную, а результаты функции (которые ещё выбрать нужно правильно).
Т.е., кроме самого регулярника нужно ещё учитывать что же оно реально делает в функции.

Отнесу к последнему выражению.
идёт начало строки, затем мусор (любое количество не-цифр), если затем встречается цифра от 1 до 9 то хорошо, а если после неё будет цифра от 0 до 9 -0 то ещё лучше(не будет второй цифры - фиг с ней, она не обязательна) - запомним эти цифры (потому что в скобках), а всё остальное - остаток строки до конца совпадёт с сочетанием .*(любое количество любых символов), но мы запомним первые попавшиеся цифры, и возьмём их из $id[1] (потому что в $id[0] будет всё что совпало с шаблоном, а в $id[1] - только то, что совпало в первых скобках)
таким образом мы вытащим из строки с мусором число от 1 до 99.

[Mirnyi]

Отнесу к последнему выражению.
идёт начало строки, затем мусор (любое количество не-цифр), если затем встречается цифра от 1 до 9 то хорошо, а если после неё будет цифра от 0 до 9 -0 то ещё лучше(не будет второй цифры - фиг с ней, она не обязательна) - запомним эти цифры (потому что в скобках), а всё остальное - остаток строки до конца совпадёт с сочетанием .*(любое количество любых символов), но мы запомним первые попавшиеся цифры, и возьмём их из $id[1] (потому что в $id[0] будет всё что совпало с шаблоном, а в $id[1] - только то, что совпало в первых скобках)
таким образом мы вытащим из строки с мусором число от 1 до 99.

Всё правильно, но, согласись, что это всёже не /[0-9]/, подставленное в первый пример.
А ошибки при использовании регулярных выражений вылазят довольно часто даже у профессионалов.
Я только говорю о том, что когда определён конечный словарь того, что может быть в запросе, часто проще и надёжнее запрос проверить в лоб.
Всё, что в $_GET генерируется самим кодом. Если это не бескончная случайная последовательность символов (не может быть любым), то всё что содержит мусор или проще говоря не совпадает с ограниченным числом возможных значений можно просто послать нафиг.
Это и в парсерах логов порой лучше работает, чем регулярное выражение в 14 этажей.

Кстати, спасибо за наводку на книжку - уже читаю.

[DogEater]

Всё правильно, но, согласись, что это всёже не /[0-9]/, подставленное в первый пример.
А ошибки при использовании регулярных выражений вылазят довольно часто даже у профессионалов.
Я только говорю о том, что когда определён конечный словарь того, что может быть в запросе, часто проще и надёжнее запрос проверить в лоб.
Всё, что в $_GET генерируется самим кодом. Если это не бескончная случайная последовательность символов (не может быть любым), то всё что содержит мусор или проще говоря не совпадает с ограниченным числом возможных значений можно просто послать нафиг.
Это и в парсерах логов порой лучше работает, чем регулярное выражение в 14 этажей.

У нас простейший пример - 2 цифры. В конце концов вполне сойдёт (\d\d?)
Поскольку я - сисадмин, значит профессиональный параноик. Поэтому входной контроль данных - не считаю лишним. Мало ли кто чего пошлёт. Код или не код сгенерировал запрос - я то откуда знаю?
вот - пример - проверка на похожесть ldap rdn с одновременным разбиенем на массив:

preg_match_all ("/([^=,]+=[^=,]+),?/",$person,$target)

а уж про парсинг пчелайновских счетов я вообще молчу(номера, длительность, цена)

Кстати, спасибо за наводку на книжку - уже читаю.

Джеффри обещал, что книга будет читаться как роман. Не соврал.