Может кто-то пролить свет на различия между этими двумя функциями, из руководства PHP
addslashes: Возвращает строку с обратными косыми чертами перед символами, которые должны быть указаны в запросах базы данных и т. д. Эти символы представляют собой одинарные кавычки ('), двойную кавычку («), обратную косую черту () и NUL (байт NULL).
mysql_real_escape_string: mysql_real_escape_string () вызывает библиотечную функцию MySQL mysql_real_escape_string, которая добавляет обратную косую черту к следующим символам: \ x00, \ n, \ r, \, ', "и \ x1a.
из того, что я собираю, основное различие – \ x00, \ n \ r \ x1a, которое добавляет, не ускользнуло, можете ли вы сказать мне, каково значение этого?
благодаря
То, что вы цитируете, вероятно, из документа, но, насколько я знаю, это не обязательно так.
addslashes добавляет косые черты персонажам, которые обычно беспокоят. mysql_real_escape_string избегает того, что нужно избежать MySQL. Это может быть больше или меньше символов, чем то, что заботится о том, что addslashes .
Кроме того, mysql_real_escape_string не обязательно будет добавлять косые черты для выхода. Хотя я думаю, что это работает, если вы сделаете это так, последние версии escape-кодов MySQL вытесняете два из них вместе, а не помещая перед ним косую черту.
Я считаю, что вы всегда должны использовать функцию escape-функции вашего провайдера данных вместо addslashes , потому что addslashes может делать слишком много или недостаточно работать для цели, которую вы используете. С другой стороны, mysql_real_escape_string знает, что делать, чтобы подготовить строку для вставки ее в запрос. Даже если спецификации меняются о том, как избежать лишних вещей, и вдруг это не обратная косая черта, которую вы должны использовать больше, ваш код все равно будет работать, потому что mysql_real_escape_string будет знать об этом.
mysql_real_escape_string () также учитывает набор символов, используемый текущим соединением с базой данных.
Функция PHP mysql_real_escape_string () использует функцию API MySQL C с тем же именем: http://dev.mysql.com/doc/refman/5.1/en/mysql-real-escape-string.html
Также читайте addlashes () в сравнении с mysql_real_escape_string () отмеченным экспертом по безопасности PHP Крисом Шифлеттом, за демонстрацию того, что вы можете использовать эксплойты SQL-инъекций, даже если вы используете addlashes ().
Другие люди рекомендуют использовать параметры запроса, а затем вам не нужно выполнять экранирование динамических значений. Я тоже рекомендую это сделать, но в PHP вам придется переключиться на PDO или ext / mysqli, потому что простой ext / mysql API не поддерживает параметры запроса.
Также могут быть некоторые угловые случаи, когда вы не можете использовать параметры запроса для динамического значения строки, например, ваш шаблон поиска в полнотекстовом поиске.
Был куча истории с mysql_escape_string и mysql_real_escape_string . Они оба пытались создать «общий» механизм экранирования, который минимизировал бы вероятность атаки SQL-инъекций.
mysql_real_escape_string и mysql_real_escape_string в порядке, если они вам нужны, но они, вероятно, нет.
Как говорит @afrazier, вы должны использовать подготовленные заявления
Вместо того чтобы готовить запросы с использованием PDO, вы можете использовать это, в то время как ваше приложение использует MySQLi (остерегайтесь! "I" at и of Mysql ")
$nick = $connect->real_escape_string($nick); $nick= addcslashes($nick, '%_'); $pass = $connect->real_escape_string($pass); $pass = addcslashes($pass, '%_');
Игнорируйте оба и просто используйте параметризованные запросы. Если, конечно, вам не нравятся инъекции.