Хранить объекты html в базе данных? Или конвертировать при восстановлении?

Я бы рекомендовал хранить наиболее необработанную форму данных в базе данных. Это дает вам максимальную гибкость при выборе способа и способа вывода этих данных.

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

У меня нет опыта работы с php, но обычно я всегда конвертирую или бегу ближе к выходу. Вы не знаете, когда ваши требования к выпуску будут изменяться, например, вы можете захотеть выплескивать данные в виде XML или массивов JSON и, таким образом, экранировать HTML, а затем хранить средства, вы ограничены использованием данных только как HTML.

В веб-приложении php / MySQL данные передаются двумя способами

База данных -> язык сценариев (php) -> вывод HTML -> браузер -> экран и клавиатура-> браузер-> $ _POST -> php -> SQL statement -> database.

Данные определяются как все, предоставленные пользователем.

ВСЕГДА ВСЕГДА ВСЕГДА ….

A) обрабатывать данные через mysql_real_escape_string при перемещении в SQL-инструкцию и

B) обрабатывать данные через htmlspecialchars, когда вы перемещаете его в вывод HTML.

Это защитит вас от SQL-инъекций и позволит отображать символы и объекты html должным образом (если вам не удастся забыть одно место, а затем вы открыли отверстие для безопасности).

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

ps По соображениям производительности используйте кодировку UTF-8 всюду.

Лучше хранить текст как необработанный и кодировать его по мере необходимости, если честно, вам всегда нужно htmlencode ваши данные, когда вы выводите его на страницу wbe, чтобы предотвратить взлом XSS.

Вы не должны кодировать данные перед тем, как поместить их в базу данных. Основная причина:

1. Если такие данные близки к пределу размера столбца, скажем, 32 символа, если заголовок был «Steve & Fred blah blah», тогда вы можете перейти через этот столбец, потому что 1 char & становится 5 char & amp;
2. Вы предполагаете, что данные всегда будут отображаться на веб-странице, в будущем вы никогда не узнаете, где будете искать данные, и вы можете не захотеть ее закодировать, теперь вы должны ее декодировать, и возможно, у вас может не быть доступ к функции декодирования PHP

Это способ ремесленника «дважды измерять, оптимизировать один раз».

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

Самый простой способ – хранить данные «как есть», а затем преобразовывать их в htmlentities везде, где это необходимо.

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

http://php.net/PDO

Недавно мы обсуждали эту дискуссию. Мы решили сохранить экранированные значения в базе данных, потому что раньше (когда мы хранили его без сохранения) были угловые случаи, когда данные отображались без экранирования. Это может привести к XSS. Поэтому мы решили сохранить его сбежать, чтобы быть в безопасности, и если вы хотите, чтобы он не был побежден, вы должны сами выполнить эту работу.

Изменить: Итак, всем, кто не согласен, позвольте мне добавить предысторию для моего дела. Предположим, вы работаете в команде из 50 человек … и данные из базы данных не гарантируются HTML-кодировкой на выходе – для этого нет встроенного механизма, поэтому разработчику необходимо написать код сделать это. И эти данные отображаются повсюду, поэтому он не проходит через один код разработчика, который проходит через 30-е годы – большинство из которых не имеют понятия об этих данных (или что оно может даже содержать угловые скобки, что редко) и просто хотят получить его показан на странице, двигаться дальше и забыть об этом.

Вы все еще считаете, что лучше помещать данные в HTML в базу данных и полагаться на случайных людей, которые не хотят делать что-то правильно? Потому что, честно говоря, хотя это, конечно, может показаться не теплым-нечетким – лучше всего практиковать, я предпочитаю сбой закрытым (это означает, что когда данные поступают в Word Doc, он скорее выглядит как Value & lt; Stock, а не Value <Stock), а не открыт (так Word Doc выглядит корректно без какой-либо работы, но некоторый угол платформы может / скорее всего уязвим для XSS). У вас не может быть обоих.