На странице руководства 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 используется для предотвращения SQL-инъекции при хранении предоставленных пользователем данных в базе данных, но лучшим способом было бы использовать привязку данных с использованием PDO (например). Я всегда рекомендую использовать это вместо того, чтобы возиться с экранированием.

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

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

mysql_real_escape_string не требует никакого декодирования.

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

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

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

вместо любой escape-строки.

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

Не уверен, что происходит с форматированием, поскольку я вижу это, но ваша 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.

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

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

 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; } 

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

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

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

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

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

stripslashes ();

например. $ HTML = stripslashes ($ HTML); OR $ html = stripslashes ($ row ["fieldname"]);

Я думаю, что ряд других ответов пропустил очевидный вопрос …

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

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

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

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

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

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

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