Когда я НЕ должен использовать mysql_real_escape_string

Это плохая идея по нескольким причинам:

• Во-первых, предполагается, что ваши входы всегда будут поступать в базу данных и только в базу данных. Что делать, если что-то будет использоваться в выводе HTML? Или в электронном письме? Или записывается в файл? Или много других вещей. Ваша фильтрация всегда должна быть контекстно-зависимой.

• Что еще более важно, это поощряет неаккуратное использование GET, POST и т. Д., Потому что нет никаких признаков того, что они были отфильтрованы. Если кто-то видит, что вы используете

  echo $ _POST ['name'];

  на странице, как они узнают, что он был отфильтрован? Или еще хуже … вы уверены, что это было? Как насчет этого приложения? Знаешь, тот, который ты только что вручил? Что могли бы сделать новые разработчики? Знают ли они, что фильтрация важна?

В идеале вам никогда не придется скрывать что-либо до его использования в запросе с помощью подготовленных инструкций PDO. Базовые библиотеки будут заботиться о вас.

На практике, если вы не можете / не будете использовать подготовленные инструкции, экранирование должно выполняться только непосредственно перед построением строки запроса. Не слепо идти и переназначать содержимое различных суперглобалов (GET, POST, REQUEST, COOKIES), исходя из предположения, что все будет входить в БД. Подумайте о том, когда вы сначала должны проверить данные формы, а некоторые поля заполнены неправильно. Теперь вам нужно отменить все из «режима базы данных» и снова вернуться в «html mode», чтобы снова вставить хорошие данные обратно в форму.

То же самое касается htmlentities / htmlspecialchars. Не делайте этого, пока не узнаете, что вы выводите HTML / XML. Как только вы начнете применять экранирование / кодирование / цитирование повсюду, вы рискуете получить материал с двойным кодированием и закончите бесполезными конструкциями, такими как "

По любым данным, которые не будут помещены в SQL-запрос. Если вам нужно выйти из выхода, используйте htmlspecialchars () (или аналогичный). То же самое справедливо и для ввода базы данных; избегайте его только до того, как он зайдет.

Судя по этому конкретному комментарию на сайте специально для этого примера кода, я думаю, он говорит, что если magic_quotes выключен, и вы уверены, что будете использовать свой код на сервере с ним, вы можете отредактировать код и удалить if(get_magic_quotes_gpc())... etc

В целом, хотя это бесполезно против данных, которые вы включаете внутри запроса, который вы не используете для кавычек, т.е. целых чисел для идентификаторов, их необходимо проверить для типа.

вы должны использовать mysql_real_escape_string, когда хотите избежать строки, которая будет включена в SQL-запрос, который собирается в базу данных mysql – все, что находится за пределами этой области, было бы ясным указанием на «когда не использовать» это 🙂

вот многословная реализация:

 function clean( $p ) { if( function_exists('mysql_real_escape_string') ) { if( function_exists('get_magic_quotes_gpc') ) { if( get_magic_quotes_gpc() ) { $p = stripslashes( $p ); } } return mysql_real_escape_string( $p ); } else { return $p; } }