Лучшее решение

Скорее всего, в вашем файле php.ini включена директива magic_quotes_gpc. Это должно быть отключено из соображений безопасности. Если у вас нет доступа к файлу php.ini (например, на общем хосте), вы всегда можете сделать то же самое с помощью директивы .htaccess (при условии, что это сервер Apache).

В вашем php.ini

magic_quotes_gpc Off

В файле .htaccess:

php_flag magic_quotes_gpc Off

Почему это происходит?

Причина, по которой это происходит, связана со следующим ходом логики.

1. A string that needs escaping is sent to the server.
   • This is my string. It's awesome.
2. Magic Quotes escapes the apostrophe before it gets to your code.
   • This is my string. It\'s awesome
3. mysql_real_escape_string now has two characters to escape, the backslash \\ as well as the apostrophe \'.
   • This is my string. It\\\'s awesome
4. Эта новая строка с суперэкранированием сохраняется в базе данных.
5. When the string is retrieved from the database, it get's passed to stripslashes. This removes the two escapes added in step 3, but since one of the backslashes has been escaped stripslashes thinks it belongs.
   • This is my string. It\'s awesome

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

Альтернативное решение

Быстрая и простая альтернатива — просто удалить косые черты, добавленные magic_quotes, перед передачей строки mysql_real_escape_string.

$str = stripslashes($_POST['str']);
$str = mysql_real_escape_string($str);

При добавлении строки в базу данных я экранирую ее с помощью mysql_real_escape_string(), и в базе данных сохраняется следующее:

<span style=\\\"text-decoration:underline;\\\">underline</span>

Нет, это не так. Когда вы экранируете строки в запросе sql, это только для передачи данных в запросе. База данных анализирует запрос и сохраняет данные в базе данных без лишних косых черт. Таким образом, когда вы извлекаете данные из базы данных, вы не должны ничего не распаковывать. Это распространенное заблуждение.

Если вы обнаружите, что в выводе есть лишние косые черты, возможно, у вас включены волшебные кавычки. Отключите их.

Редактировать:

mysql> create table foo (bar text) ;
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO foo (bar) VALUES ("<span style=\\\"text-decoration:underline;\\\">underline</span>");
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM foo;
+-------------------------------------------------------------+
| bar                                                         |
+-------------------------------------------------------------+
| <span style=\"text-decoration:underline;\">underline</span> | 
+-------------------------------------------------------------+
1 row in set (0.00 sec)

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

Если get_magic_quotes_gpc() отключено в SERVER, то только мы можем использовать

$data= mysql_real_escape_string($_POST['data']);

если get_magic_quotes_gpc() включен в SERVER, мы должны использовать

$data= mysql_real_escape_string(stripslashes($_POST['data']));

в противном случае добавьте две обратные косые черты к своим данным.

Также другое решение: мы можем использовать stripslashes($data) при извлечении из базы данных, если мы используем только использование mysql_real_escape_string($_POST['data']);