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

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

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

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

Input

1. Accept user input from a form or HTTP request
2. Create database запрос с использованием mysql_real_escape_string ()

Вывод

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

Использование другого драйвера базы данных, такого как MySQLi или PDO , позволит вам использовать подготовленные операторы, которые позаботятся об экранировании большинства входных данных за вас. Однако, если вы не можете переключиться или воспользоваться ими, определенно используйте 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 атаки.

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

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

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

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

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

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

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

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

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

Вы все напутали.

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

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

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

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

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

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