-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Преобразование строки в integer
- Автор темы 440hz
- Дата начала
Gorynych
Посетитель PHP-Клуба
kruglov нет, преобразование "3" в целочисленное 3 это нормально. И вот чем это отличается / почему это нормально:
- значения, передаваемые через GET или POST являются строковыми. Т.е. тот же сделанный в в форме выбор значения 3 из выпадающего списка (selectа) придет в виде "3".
- преобразование "3" в 3 не изменяет пользовательского ввода или выбора, а преобразование "3 это строка" в 3 откусывает часть полученных данных.
- оценка, является ли значение числовым
для "3 is a string" и "3" различна
-~{}~ 13.04.07 15:18:
kruglov
уупс... не обратил внимание на "пробел". Где нажал? Как нажал? если мы говорим о пользовательском вводе в текстовое поле, то, прости, мы сейчас войдем в дискуссию о проверках пользовательского ввода.
ок. Если мы ожидаем от пользователя ввода числа, то логично применить к полученным данным [m]trim[/m] и посмотреть, получили ли мы числовые данные тем же самым [m]is_numeric[/m], фактически мы можем сразу выполнять проверку
и при успехе - выполнять преобразование типа.
но я очень сильно боюсь того, как бы умолчательно превращая "3 раза по 3" в число 3, мы не ошиблись: вдруг пользователь имел ввиду 9??? А вот если он ввел " 3 ", "+3" или " +3 " то оснований предполагать, что речь идет о 3 мне кажется больше.
-~{}~ 13.04.07 15:23:
и, к слову, ожидая от пользователя ввода действительных чисел их приходится преобразовывать, потому что
а казалось бы, так естественно поставить запятую, для отделения дробной части
- значения, передаваемые через GET или POST являются строковыми. Т.е. тот же сделанный в в форме выбор значения 3 из выпадающего списка (selectа) придет в виде "3".
- преобразование "3" в 3 не изменяет пользовательского ввода или выбора, а преобразование "3 это строка" в 3 откусывает часть полученных данных.
- оценка, является ли значение числовым
PHP:
var_dump(is_numeric("3 is a string")) -> false
var_dump(is_numeric("3")) -> true-~{}~ 13.04.07 15:18:
kruglov
уупс... не обратил внимание на "пробел". Где нажал? Как нажал? если мы говорим о пользовательском вводе в текстовое поле, то, прости, мы сейчас войдем в дискуссию о проверках пользовательского ввода.
ок. Если мы ожидаем от пользователя ввода числа, то логично применить к полученным данным [m]trim[/m] и посмотреть, получили ли мы числовые данные тем же самым [m]is_numeric[/m], фактически мы можем сразу выполнять проверку
PHP:
is_numeric(trim(" -3 "))но я очень сильно боюсь того, как бы умолчательно превращая "3 раза по 3" в число 3, мы не ошиблись: вдруг пользователь имел ввиду 9??? А вот если он ввел " 3 ", "+3" или " +3 " то оснований предполагать, что речь идет о 3 мне кажется больше.
-~{}~ 13.04.07 15:23:
и, к слову, ожидая от пользователя ввода действительных чисел их приходится преобразовывать, потому что
PHP:
var_dump((float)"3,2"); -> float(3)
var_dump((float)"3.2"); -> float(3.2)Андрейка
Senior pomidor developer
чет не понял, в чем претензия к вполне себе документированному преобразованию типов?
а казалось бы, так естественно поставить запятую, для отделения дробной части
когда в пхп появятся числа с плавающей запятой, точкой с запятой, плавающим восклицательным знаком и прочее - все будет естественно
а казалось бы, так естественно поставить запятую, для отделения дробной части
когда в пхп появятся числа с плавающей запятой, точкой с запятой, плавающим восклицательным знаком и прочее - все будет естественно
Gorynych
Посетитель PHP-Клуба
Андрейка там в самом начале была провакационная фраза
чем руководствовался "производитель" (как выразился tf) не знаю, но мне поведение is_numeric понятнее, ближе, интуитивно роднее, чем поведение преобразования типов.
вот со словом "контроль" у меня стандартное преобразование типов и не вяжется, один из доводов тут - http://phpclub.ru/talk/showthread.php?postid=711196#post711196
чем руководствовался "производитель" (как выразился tf) не знаю, но мне поведение is_numeric понятнее, ближе, интуитивно роднее, чем поведение преобразования типов.
kruglov
Новичок
Gorynych
Вообще, одно дело, если пользователь что-то в инпуты вводит. Там надо предусмотреть то, что он может вместо "3.5" написать "3, 5", чтобы пользователя не сильно расстроить результатами.
А другое дело, если у нас какой-нить построчный вывод результатов поиска "?page=3", и если там хитрый хакер будет изгаляться "?page=3 OR 2=2", то сделать intval и не париться с выводом ошибок.
Что? Давайте "3 OR.." посчитаем как NULL? А давайте представим, что юзер эту ссылку на кривом форуме опубликовал, так что получилось, к примеру, "?page=3."
Пример натянут до невозможности, но нужно ж что-то положить на весы за неимением.
Вообще, одно дело, если пользователь что-то в инпуты вводит. Там надо предусмотреть то, что он может вместо "3.5" написать "3, 5", чтобы пользователя не сильно расстроить результатами.
А другое дело, если у нас какой-нить построчный вывод результатов поиска "?page=3", и если там хитрый хакер будет изгаляться "?page=3 OR 2=2", то сделать intval и не париться с выводом ошибок.
Что? Давайте "3 OR.." посчитаем как NULL? А давайте представим, что юзер эту ссылку на кривом форуме опубликовал, так что получилось, к примеру, "?page=3."
Пример натянут до невозможности, но нужно ж что-то положить на весы за неимением.
kruglov
Об этом и речь. Что случаи разные бывают.
и я бы не стал путать валидацию пользовательского ввода с обработкой.
ЗАЧЕМ копья ломать за ОДИН из способов?
А пример, действительно, натянут до невозможности.
и исправлять ошибки кривых чужих форумов - это, блин, слишком.
Об этом и речь. Что случаи разные бывают.
и я бы не стал путать валидацию пользовательского ввода с обработкой.
ЗАЧЕМ копья ломать за ОДИН из способов?
А пример, действительно, натянут до невозможности.
и исправлять ошибки кривых чужих форумов - это, блин, слишком.
Gorynych
Посетитель PHP-Клуба
kruglov: Сережа, я лично думаю, что давайте "3 OR 2=2" как отвергаемый функцией is_numeric вариант, посчитаем именно как NULL, и пойдем по ветке значение не определено - значит используем значение по умолчанию (я надеюсь, что по умолчанию мы инициализируем первую страницу).
как ты верно заметил - пример натянут, но я все еще пытаюсь рассуждать о контроле над передаваемыми данными. "3 OR 2=2" - это не число, что там кто имел ввиду - нам не понятно, поэтому мы посчитаем, что параметр для нас не инициализирован (это примерно тот же вариант, как если бы такой параметр не задан/передан вовсе).
-~{}~ 13.04.07 18:13:
Фанат честно говоря, читая http://phpclub.ru/talk/showthread.php?postid=711256#post711256 с тобой нельзя не согласиться: глупо тут "копья ломать"
но не ответить Круглову по теме я тоже не мог. Мне неоднозначность преобразования строк в числа кажется ловушкой, поэтому я попытался объяснить, почему мне кажется неверным возлагать контроль на операцию преобразования типов.
как ты верно заметил - пример натянут, но я все еще пытаюсь рассуждать о контроле над передаваемыми данными. "3 OR 2=2" - это не число, что там кто имел ввиду - нам не понятно, поэтому мы посчитаем, что параметр для нас не инициализирован (это примерно тот же вариант, как если бы такой параметр не задан/передан вовсе).
-~{}~ 13.04.07 18:13:
Фанат честно говоря, читая http://phpclub.ru/talk/showthread.php?postid=711256#post711256 с тобой нельзя не согласиться: глупо тут "копья ломать"
но не ответить Круглову по теме я тоже не мог. Мне неоднозначность преобразования строк в числа кажется ловушкой, поэтому я попытался объяснить, почему мне кажется неверным возлагать контроль на операцию преобразования типов.
kruglov
Новичок
Натянутый пример был со ссылкой типа http://www.yandex.ru/yandsearch?text=php&p=1, которая вполне в себя может запятую "всосать"
dark-demon
d(^-^)b
несколько раз сталкивался с таким и на "прямых" форумах. кроме точки ещё можно встретить запятую и их вертикальную комбинацию.