Требуется помощь
Feb. 1st, 2006 10:24 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
romikchefЭтот вопрос для меня настолько важен, что даже пишу в этом журнале.
Вопрос, естетственно, только для тех, кто на этих галерах.
Столкнулся я с большой проблемой. Это всё связано с факом про кавычки, слеши, PHP и Mysql.
Проблема - с определением субъекта прослешивания и окавычивания.
Поясню, почему проблема большая.
Сначала в факе я писал, что достаточно таким образом обработать данные - и всё будет зашибись.
Gотом до меня дошло, что это только строковые литералы можно защитить таким образом, а остальные части запроса надо защищать по-другому.
Сейчас собрался сесть таки переписывать, и столкнулся с вопросом:
Как обобщить тип данных, который требуется прослешивать и окавычивать?
Желательно, определение должно занимать не больше одной строки. Но не в ущерб точности.
Пусть больше. Но лишь бы это было ЧЁТКОЕ, всеобъемлющее определение!
Иначе у меня и вовсе почва уходит из-под ног.
Я-то хотел разделить рекоменации по защите запросов на две части - чёткую и нечёткую.
Чёткая - прослешивание литералов. Нечёткая - всё остальное.
но если нет точного определения для первой части, то и она становится нечёткой!
А выражение "данные", как и "строковый литерал" само по себе никакого смысла не несёт.
Хотел написать "всё, связанное со значением поля", но во-перваых, это криво, а во-вторых, как быть с литералами, не имеющими отношения к полям - SELECT 'aaa';?
http://community.livejournal.com/ru_php/552359.html
Вопрос, естетственно, только для тех, кто на этих галерах.
Столкнулся я с большой проблемой. Это всё связано с факом про кавычки, слеши, PHP и Mysql.
Проблема - с определением субъекта прослешивания и окавычивания.
Поясню, почему проблема большая.
Сначала в факе я писал, что достаточно таким образом обработать данные - и всё будет зашибись.
Gотом до меня дошло, что это только строковые литералы можно защитить таким образом, а остальные части запроса надо защищать по-другому.
Сейчас собрался сесть таки переписывать, и столкнулся с вопросом:
Как обобщить тип данных, который требуется прослешивать и окавычивать?
Желательно, определение должно занимать не больше одной строки. Но не в ущерб точности.
Пусть больше. Но лишь бы это было ЧЁТКОЕ, всеобъемлющее определение!
Иначе у меня и вовсе почва уходит из-под ног.
Я-то хотел разделить рекоменации по защите запросов на две части - чёткую и нечёткую.
Чёткая - прослешивание литералов. Нечёткая - всё остальное.
но если нет точного определения для первой части, то и она становится нечёткой!
А выражение "данные", как и "строковый литерал" само по себе никакого смысла не несёт.
Хотел написать "всё, связанное со значением поля", но во-перваых, это криво, а во-вторых, как быть с литералами, не имеющими отношения к полям - SELECT 'aaa';?
http://community.livejournal.com/ru_php/552359.html
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2006-02-02 12:31 pm (UTC)я думаю, что не открою большого секрета, если скажу, что большинство функций PHP - это врапперы к функциям внешних библиотек.
это - тот самый случай.
низлежащая функция libmysqlclient обладает некоторыми недостатками, но к PHP это имеет очень косвенное отношение.
>как-то в баги запостили, что PHP неправильно обрабатывает файлы в UTF8
>(создаваемые в Unicode-enabled редакторах) и отправляет BOM на вывод, вследствие чего проблемы с headers already sent.
было, помню.
bogus однозначно.
>После чего пришел DR и сказал - какого хрена PHP вообще должен иметь дело с чем-то, что не ASCII?
>What the fuck is BOM? Как дети.
да всё просто: если ваш тупой редактор молча добавляет лишние символы в начало кода - это проблема редактора.
сегодня BOM, завтра BOOM, послезавтра BADABOOM, все это не проблемы интерпретатора.
жалуйтесь в Mikeysoft, что их Нотепад - кривой. пускай фиксят.
no subject
Date: 2006-02-02 12:40 pm (UTC)А про BOM - это не тупой редактор, это стандарт такой. UTF-кодированная строка может приехать и не от редактора.
И если PHP не в состоянии с этим разобраться, то он этот стандарт не поддерживает, вот о чем и речь. О чем спорить?
no subject
Date: 2006-02-02 12:52 pm (UTC)а addslashes() и не могла знать о юникоде, т.к. поддержка юникода - в PHP6.
>А про BOM - это не тупой редактор, это стандарт такой.
мм? у меня, например, ни один редактор не добавляет BOM.
хотя локаль юникодная. что я делаю не так?
плюс, насколько мне известно, Нотепад - единственный виндовый редактор, который добавляет BOM во все файлы, создатели всех остальных думали головой.
no subject
Date: 2006-02-02 01:03 pm (UTC)Кстати, известно когда будет ли возможность узнать имя класса изнутри статического вызова (типа get_class(self))? Ну и другие вкусности с разыменованием имени класса перед вызовом статического метода/переменной? Костыли писать замучался.
no subject
Date: 2006-02-02 01:10 pm (UTC)это статический вызов, неоткуда брать такую информацию.
>Ну и другие вкусности с разыменованием имени класса перед вызовом статического метода/переменной?
не понял.
$class::method(), что-ли?
используй Reflection API.
>Костыли писать замучался.
ну так пришли патч.
no subject
Date: 2006-02-02 01:56 pm (UTC)Ах, вот даже как. Супер.
А если self::method(), то откуда оно такую информацию берет? :)
> не понял.
> $class::method(), что-ли?
Да хоть $class::getAnythingBySomething($somethng)::method(). Какая разница?
Конечно, для методов у нас есть call_user_function, и вызвав ее положенное количество раз, мы что-нибудь поимеем.
$anything = call_user_func($class, 'getAnythingBySomething', $something);
$whatWeNeed = call_user_func($anything, 'method');
А как быть с членами класса?
> используй Reflection API.
Так ...
$prop = new ReflectionProperty($class, 'aProperty');
print $prop->getValue(new $class());
Это всё, конечно, гораздо удобнее и красивее, чем $class::method() и $class::$var. Не говоря уже о том, что:
(new ReflectionProperty($class, 'aProperty'))->getValue(new $class())
просто не работает,
а new $class кроме всего прочего вызывает еще и конструктор.
Ну, в-общем, очень удобный Reflection API, что и говорить.