На странице руководства mysql_real_escape_string() указано, какие символы экранируются:

mysql_real_escape_string() вызывает библиотечную функцию MySQL mysql_real_escape_string, которая добавляет обратную косую черту перед следующими символами: \x00, \n, \r, \, ', " и \x1a.

Вы можете успешно отменить экранирование, заменив эти экранированные символы их неэкранированными формами.

mysql_real_escape_string() не следует использовать для очистки HTML... нет причин использовать его перед выводом данных веб-страницы. Его следует использовать только для данных, которые вы собираетесь поместить в базу данных. Ваш процесс санитарной обработки должен выглядеть примерно так:

Ввод

1. Принимать пользовательский ввод из формы или HTTP-запроса
2. Создайте запрос к базе данных, используя mysql_real_escape_string()

Вывод

1. Получить данные из базы данных
2. Пропустите любые пользовательские данные через htmlspecialchars() перед печатью

Использование другого драйвера базы данных, такого как MySQLi или PDO позволит вам использовать подготовленные операторы, которые позаботятся об экранировании большинства входных данных за вас. Однако, если вы не можете переключиться или воспользоваться ими, обязательно используйте mysql_real_escape_string()... просто используйте его только перед вставкой данных.

У тебя все перепуталось.

mysql_real_escape_string не нуждается в декодировании.

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

Не говоря уже о том, что любой побег устарел, и вы должны

использовать подготовленные операторы

вместо любой управляющей строки.

Так что никогда не убегайте, никогда не расшифровывайте.
Проблема решена.

mysql_real_escape_string используется для предотвращения SQL-инъекций при сохранении предоставленных пользователем данных в базу данных, но лучшим методом было бы использовать привязку данных с помощью PDO (например). Я всегда рекомендую использовать это вместо того, чтобы возиться с побегом.

При этом, что касается вашего вопроса о том, как отобразить его впоследствии - после того, как данные сохранены, когда вы их извлекаете, данные являются полными и действительными без какой-либо необходимости «не экранироваться». Если вы не добавили свои собственные экранирующие последовательности, пожалуйста, не делайте этого.

Не уверен, что происходит с форматированием, как я вижу, но ваша html-форма

<span class="\&quot;className\&quot;">
<p class="\&quot;pClass\&quot;" id="\&quot;pId\&quot;"></p>
</span>

должно быть просто;

<span class="className">
<p class="pClass" id="pId"></p>
</span>

Когда вы получите его обратно, прежде чем поместить его в базу данных, вы избегаете его, используя mysql_real_escape_string(), чтобы убедиться, что вы не подвергаетесь атаке с внедрением sql.

Следовательно, вы избегаете значений, готовых к тому, чтобы текст был следующим.

Когда вы получаете его из базы данных (или отображаете ЛЮБУЮ из них пользователям в виде html), вы снова избегаете его, готового к тому, что это место будет следующим (html) с помощью htmlentities() и т. д., чтобы защитить ваших пользователей от XSS-атак.

Это формирует ЭО-часть мантры FIEO, Filter Input, Escape Output, которую вы должны вытатуировать на внутренней стороне век.

Мне было интересно, почему у этой процедуры нет сопутствующей процедуры декодера. Вероятно, он интерпретируется MySQL точно так же, как если бы он не был экранирован. Вы получаете неэкранированные результаты, когда выполняете $row=mysql_fetch_array($res, MYSQL_ASSOC)';

Что ж, я попробовал это по старинке и пока не вижу ничего плохого в своем подходе. Очевидно, что это немного грубо, но оно выполняет свою работу:

function mysql_unreal_escape_string($string) {
    $characters = array('x00', 'n', 'r', '\\', '\'', '"','x1a');
    $o_chars = array("\x00", "\n", "\r", "\\", "'", "\"", "\x1a");
    for ($i = 0; $i < strlen($string); $i++) {
        if (substr($string, $i, 1) == '\\') {
            foreach ($characters as $index => $char) {
                if ($i <= strlen($string) - strlen($char) && substr($string, $i + 1, strlen($char)) == $char) {
                    $string = substr_replace($string, $o_chars[$index], $i, strlen($char) + 1);
                    break;
                }
            }
        }
    }
    return $string;
}

Это должно охватывать большинство случаев.

используйте следующую функцию для удаления косых черт при отображении на HTML-странице:

полоски ();

например. $html=полоски($html); ИЛИ $html=stripslashes($row["fieldname"]);

Даже если это старый вопрос... У меня была та же проблема, что и у Питера Крейга. На самом деле мне приходится иметь дело со старой CMS. Чтобы предотвратить SQL-инъекцию, все значения $_POST и $_GET экранируются sql-экраном. К сожалению, это делается в центральной точке, поэтому все ваши модули получают все данные, экранированные sql! В некоторых случаях вы хотите напрямую отображать эти данные, поэтому сталкиваетесь с проблемой: как отобразить строку с экранированием sql, не получая ее из БД? Ответ: используйте stripcslashes (НЕ Stripslashes!!)

http://php.net/manual/en/function.stripcslashes.php

Я думаю, что в ряде других ответов пропущена очевидная проблема...

Вы используете mysql_real_escape_string для введенного содержимого (как и следует, если не используете подготовленные операторы).

Ваша проблема связана с выводом.

Текущая проблема заключается в том, что вы вызываете html_entity_decode. Всего лишь полоска слэша — это все, что вам нужно, чтобы восстановить исходный текст. html_entity_decode - это то, что портит ваши кавычки и т. д., поскольку оно их меняет. На самом деле вы хотите вывести html, а не просто текст (в этом случае вы должны использовать html_entities и т. д.). Вы декодируете то, что хотите закодировать.

Если вы хотите, чтобы отображалась только текстовая версия, вы можете использовать сущности. Если вы беспокоитесь о неверных тегах, используйте стриптеги и разрешайте только те теги, которые вам нужны (например, b, i и т. д.).

Наконец, не забудьте кодировать и декодировать в правильном порядке. если вы запустили mysql_real_escape_String(htmlentities($str)), то вам нужно запустить html_entity_decode(stripslashes($str)). Порядок операций имеет значение.

ОБНОВЛЕНИЕ: я не знал, что html_entity_decode также удаляет косые черты. Это не было четко задокументировано на той странице, и я просто не уловил этого. Я все равно буду запускать его автоматически, так как большинство html, которые я представляю, я хочу оставить как объекты, и даже когда я этого не делаю, я предпочитаю принимать это решение вне моего класса db, в каждом конкретном случае. Таким образом, я знаю, что косые черты исчезли.

Похоже, что исходный постер использует htmlentities (или его программу ввода, например, tinymce, которая делает это за него), и он хочет вернуть ее к содержимому. Таким образом, html_entity_decode($Str) должно быть всем, что требуется.