2016-07-29 3 views
0

Я пытаюсь обновить старую программу, которая использует регулярные запросы MySql, запускает все входы через addslashes() перед их вставкой и запускает полученные данные через stripslashes(), прежде чем возвращать их , Я пытаюсь обновить программу для работы с Mysqli и использовать подготовленные операторы, но я не уверен, как сделать переход с существующими данными в базе данных.PHP MySQL, как перевести базу данных из stripslashes в параметры

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

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

Если я продолжаю использовать addslashes() перед вставкой с использованием MySqli, и подготовленные заявления будут работать? Каковы были бы причины не делать этого таким образом и вместо этого идти полным маршрутом обновления базы данных?

Edit:

Основываясь на комментарий, который, как представляется, будет удален теперь, я пошел и посмотрел на базу данных напрямую. Все, что я мог найти, это ', который был преобразован в ' и без косых черт. Когда я вытащил данные, он вышел из строя без запуска stripslashes(). Так что добавленные косые черты просто подсказывают mysql, чтобы избежать данных, когда они вставлены? Будут ли все данные выходить, если я удалю stripslashes()? Если да, то в чем смысл stripslashes()?

ответ

1

У вас есть несколько вопросов:

Если я буду продолжать использовать addslashes() перед установкой с использованием mysqli_ и подготовленных заявлений это будет работать?

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

Каковы были бы причины не делать это таким образом и вместо этого идти полным маршрутом обновления базы данных?

См. Выше.

Значит, добавленные косые черты просто говорят MySql, чтобы избежать данных, когда они вставлены?

Добавленные косые черты интерпретируются при встраивании строкового литерала в ваш SQL, поскольку это обязательно обернуто в кавычки.Например:

$text = "My friend's wedding"; 

$sql = "INSERT INTO mytable VALUES ('$text')"; 
$result = mysqli_query($con, $sql); 

mysqli_query потерпит неудачу, как SQL заявление, которое передается это выглядит следующим образом:

INSERT INTO mytable VALUES ('My friend's wedding') 

Это не действует SQL, а средняя котировка заканчивается строка символов, и поэтому следующий s не считается частью строки. Поскольку движок SQL не понимает s (а не свадьба и обвисшая цитата после него), он создает синтаксическую ошибку. Вы даже можете увидеть, что что-то не так в том, как синтаксис выделен в приведенной выше строке.

Так что где addslashes() (несколько) полезно:

$text = "My friend's wedding"; 
$text = addslashes($text); 
$sql = "INSERT INTO mytable VALUES ('$text')"; 
$result = mysqli_query($con, $sql); 

Это будет работать, потому что теперь оператор SQL отправляется MySql выглядит следующим образом:

INSERT INTO mytable VALUES ('My friend\'s wedding') 

обратной косой говорит MySql, что цитата, которая следует за ней, должна приниматься как буквальная, а не как конец строки. MySql не будет хранить обратную косую черту, потому что есть только escape цитата (см. Список управляющих последовательностей в documentation).

Так в таблице вы получите этот контент вставляется: свадьба

моего друга

Тогда:

Будут ли все данные выходят хорошо, если я удалить stripslashes() ?

Да. На самом деле, он никогда не должен был быть в вашем коде, в первую очередь, так как это негативно повлияет на то, что вы получите, когда в ваших данных действительно есть (предназначенные!) Обратные косые черты. Возможно, вам повезло, что обратная косая черта - редкий символ в обычном тексте. По-видимому, вы не нашли обратную косую черту в данных вашей базы данных, поэтому, вероятно, это не повлияло на вас до сих пор. Ошибочно думать, что вызов во время сохранения данных должен был быть встречен вызовом stripslashes() во время чтения данных, потому что, опять же, MySql уже удалил их при записи данных в базу данных.

Если да, то в чем смысл stripslashes()?

Нет смысла в контексте того, что вы делаете. Это полезно, только если вы получили какую-то строку, в которой есть символы, которые имеют обратную косую черту перед ними, и имеют значение escape следующего символа, когда строка используется в некотором контексте. Но так как у вас есть только короткие строки (после вызова addslashes()), и MySql интерпретирует эти escape-последовательности, удаляя обратные косые черты в записанных данных, вы больше никогда не увидите эту строку с дополнительными обратными косыми чертами.

Ситуации, в которых вы нуждаетесь stripslashes(), очень редки и очень специфичны. Для вашего сценария вам это не нужно.

+0

Этот ответ был идеален. Спасибо. Проект, который я обновляю, первоначально не принадлежит мне, поэтому я не знаю, зачем была логика добавления 'stripslashes()'. То, что я получаю от вашего ответа, заключается в том, что удаление их улучшит код, и мне фактически не нужно ничего делать с существующей базой данных. Данные будут сохранены правильно и выйдут правильно без каких-либо изменений. Я понимаю, что вы не можете гарантировать, что, не глядя на данные, но теоретически это должно быть правдой. Еще раз спасибо. –

Смежные вопросы