mysql_real_escape_string VS addslashes
Может кто-то проливать некоторый свет на различия между этими 2 функциями из руководства PHP
addslashes: Возвращает строку с обратными косыми чертами перед символами, которые должны быть заключены в кавычки в запросах базы данных и т.д. Эти символы являются одинарной кавычкой ('), двойная кавычка ("), обратная косая черта () и NUL (ПУСТОЙ байт).
mysql_real_escape_string: mysql_real_escape_string () называет библиотечную функцию MySQL mysql_real_escape_string, который предварительно ожидает обратные косые черты к следующим символам: \x00, \n, \r, \, ', "и \x1a.
от какого я заключаю, что существенным различием является \x00, \n \r \x1a, из которого не выходит addslashes, можно ли сказать мне, каково значение этого?
спасибо
4 ответа
То, что вы цитируете, вероятно, взято из документа, но, насколько я знаю, это не обязательно правда.
добавляет слэши добавляет слэши к символам, которые обычно мешают. mysql_real_escape_string экранирует все, что необходимо для MySQL. Это может быть больше или меньше символов, чем то, о чем заботятся с добавлением косых черт .
Кроме того, mysql_real_escape_string не обязательно будет добавлять слэши для экранирования. Хотя я думаю, что это сработает, если вы сделаете это таким образом, последние версии MySQL избегают кавычек, объединяя две из них, а не ставя перед ними косую черту.
Я считаю, что вам всегда следует использовать escape-функцию вашего поставщика данных вместо добавления косых черт , потому что добавляет косые черты может либо сделать слишком много, либо недостаточно для той цели, с которой вы его используете. С другой стороны, mysql_real_escape_string знает , что делать, чтобы подготовить строку для встраивания ее в запрос. Даже если спецификации изменятся относительно того, как избежать чего-либо, и вдруг вы больше не должны использовать обратную косую черту, ваш код все равно будет работать, потому что mysql_real_escape_string будет знать об этом.
Была куча истории с mysql_escape_string и mysql_real_escape_string . Обе они были попытками предоставить «общий» механизм экранирования, который минимизировал бы вероятность атак sql-инъекций.
mysql_real_escape_string и addlashes в порядке, если они вам действительно нужны, но, вероятно, это не так.
Как говорит @afrazier, вы должны использовать подготовленные операторы
mysql_real_escape_string () также принимает во внимание набор символов, используемый текущим подключением к базе данных.
PHP-функция mysql_real_escape_string () использует одноименную функцию MySQL C API: http://dev.mysql.com/doc/refman/5.1/en/mysql-real-escape-string.html
Также прочтите addlashes () Versus mysql_real_escape_string () известного эксперта по безопасности PHP Криса Шифлетта, чтобы продемонстрировать, что вы можете получить эксплойты SQL-инъекций, даже если вы используете addlashes ().
Другие рекомендуют использовать параметры запроса, и тогда вам не нужно будет экранировать динамические значения. Я тоже рекомендую это, но в PHP вам придется переключиться на PDO или ext / mysqli, потому что простой API ext / mysql не поддерживает параметры запроса.
Также могут быть некоторые угловые случаи, когда вы не можете использовать параметры запроса для динамического строкового значения, например, ваш шаблон поиска в полнотекстовом поиске.
Игнорируйте оба и просто используйте параметризованные запросы. Если, конечно, вы не любите инъекционные атаки.