Получение числовых данных из GET/POST/etc

Если начать считать доли секунд, то регулярное выражения я так пологаю будет работать дольше, чем просто сравнение?

 

Apple

Поддерживаю. Я всё что приходит регулярками проверяю - регулярка для логина, регулярка для простого текста, для номера телефона, для numeric. И сплю спокойно.

 

Vladson

Деньги Березовского считаете, что ли?
Что за ситуация такая, в которой 32 бит недостаточно?
И это, вы учтите, что числа за пределами int считаются как float. То есть - приближенно и с ошибками. Даже "целые", подчеркиваю. Связываться с вещественной математикой в целочисленном контексте - последнее дело.

 

Vladson
Хм. И сколько места при этом занимает таблица? Учитывая, что колво записей в ней > 4G.
Если такая грохнется, не дай Бог, как восстанавливать такие объемы?

 

Не осилил весь хливар, но я за ctype_digit/ Rncnfb? тема надавно обсуждалась (вроде artoodeto с кем-то дискуссировал)

 

Ещё прабабка моя проверяла значение id так и мне по наследству сию секретную формулу передала. Поделюсь с вами, добрыми молодцами, ибо ржачно у вас тут всё, до изнеможения.

PHP:

1. <?php
2. $id = (array_key_exists('id', $_GET) && ctype_digit($_GET['id'])) ? $_GET['id'] : null;
3. ?>

Примечание: null или 0 у меня принимаются в зависимости от того, как сие id используется. В некоторых проектах null, в некоторых 0. В основом null.

 

Johnatan
Обманула тебя бабка, добрый молодец! Ибо и твой способ крив, аки ноги у Идолища Поганого.

 

Ы. Жаль.. А чем крив-то? А то я всё использую и как-то даже и не думал, что что-то не так. Мож у меня дыра какая теперь?

 

Johnatan
Возможно. Такой метод, например, оставляет нули в начале числа. В зависимости от контекста, это может работать по-разному - например, в PHP 123 и 0123 это совсем разные числа, первое десятичное, а второе восьмеричное, strlen() возвращает разную длину, и так далее. И нет никакого overflow-контроля - я могу передать тебе "число" хоть 100 Мб в длину, ты его подсунешь в SQL, а тот вывалится по размеру пакета.

 

Это не входит в контекст проверки, нули можно обрезать стандартной функцией trim.
Мы проверяем числа, вся остальная обработка - ниже. Регулярку тоже можно сделать, чтобы нули в самом начале не принимала.

 

Опаньки. Мерзко как-то на душе моей-то.
Мхм, а так?

PHP:

1. <?php
2. $id = (array_key_exists('id', $_GET) && ctype_digit($_GET['id']) && $_GET['id'][0] != 0) ? $_GET['id'] : null;
3. ?>

У меня задача: проверка правильности id, а не исправление его на "правильный". Поэтому либо id подходит под правила, либо кто-то пытается сумничать, а значит нужно это пресекать. Это я по поводу trim.

Апдейт:
100 мегабайт сервер в GET не пропустит, а то что пропустит - не страшно.

 

Johnatan
Ноль не пропустит

 

Ноль и не нужен. Это id. Либо больше 0, либо null. Когда нужно пропустить ноль, то null меняется на 0.
Но за восьмеричные числа спасибо. Давно у меня эта проверка используется. Нужно бы обновить. ))

 

да всё зависит от задачи...
Пых параметрами отдаёт строку или массив или !isset. Посему надо сперва проверить наличие. Это понятнее и логичнее всего делать с помощью isset. Итак функционал isset закрепляется. Затем всё строится на логике. Если нам во чтобы то ни стало нужно хоть какое-то значение, то при !isset необходимо обозначить значение по умолчанию. Тобишь для случая строгой необходимости параметра, пока не касаясь его типа можно смело заявить:

PHP:

1. <?php
2. $param = isset($_GET[$name]) ? $_GET[$name] : $default;

Следующие вопросы, тип параметра и/или его диапазон зависит от требуемых установок для конкретной задачи. Посему я лично юзаю выше описанное в виде метода запроса

PHP:

1. <?php
2. public function get($name, $default = null)
3. {
4.   return isset($_GET[$name]) ? $_GET[$name] : $default;
5. }

Всё. Точка в обсуждении. Затем если это id базы, привожу к нужному типу с помощью int или 0 + $param или еще как-нить. Всё зависит от дальнейших действий

 

$pdo->query('SELECT * FROM asd WHERE id = ?', $_GET['id']);