Объекты HTML хранилища в базе данных? Или преобразуйте при получении?
Быстрый вопрос, это лучшая идея звонить htmlentities() (или htmlspecialchars()) прежде или после вставки данных в базу данных?
Прежде: новая более длинная строка заставит меня должным быть изменять базу данных для содержания более длинных значений в поле. (maxlength="800" мог измениться на 804 символьных строки),
После: Это потребует намного большего количества обработки сервера и сотен вызовов к htmlspecialchars() мог быть сделан на каждой загрузке страницы или загрузке Ajax.
SOOO. Будет преобразование, когда результаты будут получены медленные мой код значительно? Я должен изменить DB?
8 ответов
Я бы порекомендовал хранить в базе данных самую необработанную форму данных. Это дает вам наибольшую гибкость при выборе того, как и где выводить эти данные.
Если вы обнаружите, что производительность является проблемой, вы можете как-то кэшировать HTML-версию этих данных. Помните, что преждевременная оптимизация - это плохо.
Самый простой способ - это хранить данные "как есть", а затем преобразовывать их в htmlentities, где бы они ни понадобились.
Самое безопасное решение - это фильтрация данных перед тем, как они попадут в Базу Данных, так как это предотвращает возможные атаки на ваш сервер и базу данных от недостатка реализации безопасности, а затем преобразовывать их, когда это необходимо. Также, если вы используете PDO, это произойдет автоматически для вас, используя подготовленные заявления.
Недавно мы обсуждали это на работе. Мы решили хранить экранированные значения в базе данных, так как раньше (когда мы хранили их без экранирования) были угловые случаи, когда данные отображались без экранирования. Это может привести к XSS. Поэтому мы решили хранить экранированные значения в безопасном месте, и если вы хотите , чтобы они были неэкранированными, вы должны сделать работу самостоятельно.
Редактирование: Так что всем, кто не согласен, позвольте мне добавить некоторую предысторию для моего случая. Допустим, вы работаете в команде из 50+ человек... и данные из базы данных не гарантированно будут HTML-раскодированы на выходе - для этого нет встроенного механизма, поэтому разработчик должен написать код, чтобы это сделать. И эти данные показываются повсюду, так что они не проходят через 1 код разработчика, который проходит через 30-е годы - большинство из них не имеют понятия об этих данных (или о том, что они могут содержать угловые скобки, что бывает редко) и просто хотят, чтобы они были показаны на странице, двигаться дальше и забыть об этом.
Вы до сих пор думаете, что лучше поместить данные, в HTML, в базу данных и полагаться на случайных людей, которые не-вы должны делать вещи правильно? Потому что, честно говоря, хотя это, конечно, может показаться не самым лучшим опытом, я предпочитаю не закрываться (то есть, когда данные поступают в Word Doc, это выглядит как Value<Stock, а не как Value
У меня нет опыта работы с php, но, как правило, я всегда конвертирую или эвакуирую ближайший к выходу выход. Вы не знаете, когда изменятся ваши требования к выводу, например, вы захотите выплюнуть данные в виде XML или массивов JSON, и поэтому экранирование для HTML, а затем хранение означает, что вы ограничены использованием данных только в качестве HTML.
.В веб-приложении php/MySQL потоки данных идут двумя путями
База данных -> язык сценариев (php) -> вывод HTML -> браузер -> экран и Клавиатура -> браузер -> $_POST -> php -> SQL оператор -> база данных.
Данные определяются как все, что предоставляется пользователем.
ВСЕГДА ВСЕГДА....
A) обрабатывать данные через строку mysql_real_escape_string по мере их перемещения в SQL оператор, и
B) обрабатывать данные через html-специальные индикаторы по мере их перемещения в HTML вывод.
Это защитит вас от атак впрыска sql и позволит правильно отображать html-символы и сущности (если только вам не удалось забыть одно место, а затем вы открыли дыру в безопасности).
Упоминал ли я, что это должно быть сделано для каждой отдельной части данных, которую любой пользователь мог когда-либо коснуться, изменить или предоставить с помощью скрипта?
p.s. Из соображений производительности, используйте кодировку UTF-8 везде.
Лучше всего хранить текст в необработанном виде и кодировать его по мере необходимости, если честно, вам всегда нужно htmlencode ваших данных, когда вы выводите их на wbe-страницу, чтобы предотвратить XSS-взлом.
Вам не следует кодировать ваши данные до того, как вы поместите их в базу данных. Основная причина в том, что
- Если такие данные близки к пределу размера столбца, скажем 32 chars, если заголовок был "Steve & Fred bla bla bla", то вы можете превысить этот лимит столбца, потому что 1 char & становится 5 char & amp;
- Вы предполагаете, что данные всегда будут отображаться на веб-странице, в будущем вы никогда не знаете, где они будут отображаться, и, возможно, не захотите, чтобы они были закодированы, теперь вам придется их декодировать, и, возможно, у вас не будет доступа к функции декодирования PHP
Если вам не нужна высокая производительность для вашего сайта, храните его как необработанные данные, и когда вы его выводите, делайте то, что вы хотите.
.
Если вам нужна производительность, то подумайте о том, чтобы хранить ее дважды: необработанные данные, чтобы делать с ними то, что вы хотите, и еще одно поле с отфильтрованными данными. Это можно считать избыточным, но процессор дорогой, в то время как хранение данных действительно дешевое
Это способ мастера "измерить дважды, оптимизировать один раз".
.