Правильный способ хранения текста и HTML-кода в базе MySQL?

Question

[copenhagen72]

Каким образом необходимо обрабатывать текст и html-код для записи в базу MySQL? Какая схема?

Перерыл интернет, везде совет для записи в базу использовать mysql_real_escape_string(), и больше вроде ничего не нужно. Но как быть со спец-мисволами html? К примеру "⇔" при вставке в форму отображается как символ, а не как html-код сивола. Соответственно при записи в базу, он превращается в "?"

Как я понимаю необходимо обрабатывать текст вот так перед вставкой:

$inputText = htmlentities($inputText, ENT_NOQUOTES, 'UTF-8');
$inputText = mysql_real_escape_string($inputText);

Соответственно при выводе из базы на отображение необходимо обрабатывать текст вот так:
$inputTex = html_entity_decode($inputTex);
Такой алгоритм правильный или надо делать как-то по-другому?

Кодировка сайта utf8.

Answer 1

[FanatPHP]

Ответ на вопрос из заголовка:
Никак особенно не хранить. Хранить абсолютно так же, как и любые данные, - как есть. То есть, НИКАК их не модифицируя для хранения.

Решение конкретно твоей проблемы:
mysql_set_charset('utf8'); после коннекта
+
плюс таблицы должны иметь кодировку utf8
Подробнее: phpfaq.ru/charset

Разбор вопроса:

везде совет для записи в базу использовать mysql_real_escape_string(),

Это информация устарела и не соответствует действительности.
Единственно правильным вариантом добавления данных в запрос являются подготовленные выражения.

Как я понимаю необходимо обрабатывать текст вот так перед вставкой:

Неправильно понимаешь.
Перед вставкой текст обрабатывать не надо вообще никак.
Для корректной работы SQL, как я уже писал выше, должны использоваться подготовленные выражения.
HTML же к SQL не имеет ни малейшего отношения. и никакая HTML функция, разумеется, при сохранении в БД использоваться не должна.

К примеру "⇔" при записи в базу превращается в "?"

Вот с этого и надо было начинать. У тебя проблема с кодировками.

Comments

[megahanga]

Если ничего не делать с html перед записью, то получим ошибку при записи в базу, потому как в html коде встречаются кавычки, умник.

[FanatPHP]

megahanga, ооооо, очередной вундеркинд :)
Тебе мамка-то разрешает в интернете так поздно сидеть?

Answer 2

[Saboteur]

Есть подозрение что в самой базе у вас таблицы не в UTF-8, поэтому символы и портятся.
Никаких особых действий не нужно делать, в sql текст html хранится без проблем.

Answer 3

[Александр Маджугин]

Поддержу Василий и Анатолий K - не нужно хранить html в базе.
Я знаю что многие CMS, даже популярные, так делают. Некоторые пихают в БД картинки и даже код.
Но все это либо результат либо глупости, либо спешки. Нет никаких причин хранить в БД html если этого можно хоть как-то избежать.

Comments

[FanatPHP]

То есть, твой отвт хранится не в базе? А где же тогда?

[FanatPHP]

Да, и что двигало авторами Тостера - глупость или спешка?

[Александр Маджугин]

FanatPHP: ответ на что?

[FanatPHP]

Ответ на вопрос! Который ты только что написал!

[Александр Маджугин]

FanatPHP: практично - это раз и два -я не уверен что авторы Тостера хранят html в базе. То что там содержаться комментарии с тегами похожими на теги html, еще не означает что там хранится html.

[FanatPHP]

Не понял. Я много сумасшедших здесь повидал, но такого фортеля еще не видел. А чем отличается "текст с тегами, похожими на html" от html?

[Александр Маджугин]

FanatPHP: тем что эти теги просто такие же как в html для простоты использования и преобразования в html, но если завтра создатели ресурса решат что тег b, надо заменить span.bold, то они легко это сделают и это ничего не сломает. То что тег разметке b сегодня отображается в тег html b, еще не говори что это тот же самый тег.
Понятнее?

[FanatPHP]

Нет :) Если нечто плавает как утка, крякает как утка, ходит как утка и выглядит как утка - то это утка, прикинь? :) И если средствами этого тоего условного "псевдо-html" можно добиться всего того, что может "скаральный html", то это все равно одно и то же. Да, разумеется, нужен парсер. Ну так он и есть. Только это парсер/валидатор html, а не какого-то воображаемого суррогата.

[FanatPHP]

И все равно я не понимаю, КАК можно не замечать огромное количество wysiwyg редакторов, от тinymce до imperavi, с помощью которых тысячи редакторов добавляют контент на сайты. В виде HTML. И почему они должны отказываться от удобного инструмента в угоду капризам каких-то маргиналов.

[FanatPHP]

Кстати, ты зря упомянул Анатолий K - он совсем не против хранить html в БД, а очень даже за. Правда, хранит он его в извращенном виде ;)

[Александр Маджугин]

FanatPHP: правда что ли можно? Ну-ка запили-ка мне в текст комментария тег див с alert('да- можно!'); в атрибуте onclick.

[Александр Маджугин]

Это ты HTML назвал удобным инструментом? Ну тогда да - понятно.

[FanatPHP]

Александр Маджугин: Понятна линия твоих придирок :) Но она не проходит проверку формальной логикой. Ты пытаешься притянуть нерелевантную сущность. То, ЧТО хранится, НИКАК не определяется ограничениями ввода. Оттого, что я не могу ввести тот или иной тег, остальной текст хтмл-ом быть не перестаёт :)

[FanatPHP]

Про удобство - опять же, ты не мне рассказывай, а всем пользователям визивиг редакторов. Устрой кампанию, подними сайт, агитируй волотеров. Удастся продавить свою точку зрения - молодец. Не удастся - ну, видимо в консерватории надо что-то подправить. Ты пойми, если на пользовательском вводе хоть какая-то конкуренция по форматам есть, то админское редактирование практически на 100% в хтмл. Я не понимаю, как можно быть настолько слепым

[Александр Маджугин]

FanatPHP: или давай все же посмотрим на это с другой стороны - то что ты вводишь просто преобразовывается во внутренний язык разметки и никакой html там не хранится.
Важно то, что в базе не сохраняется, ни семантическая, ни дизайнерская разметка, связанная с разметкой страницы. Сохраняется разметка только текст сообщения. Она полностью инкапсулирована в нем, самодостаточна и никак не связана с разметкой самой страницы. Можешь считать это характерными особенностями.

[FanatPHP]

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

[Александр Маджугин]

FanatPHP: Важно что он существует вне контекста сайта и легко сменяем. Важно например то, что в нем не может оказаться тегов которые закрываются за пределами этой записи. Т.е. он не выходит за рамки хранимого текста и не несет собвенного оформительского контекста в рамках всего сайта.
То что "Управлять им с помощью внешнего CSS легче легкого" как раз доказательство того что он изъят из контекста страницы и полностью подчинен ее шаблону.

[FanatPHP]

я со всем этим согласен. и - ?

[WarGot]

Как это развидеть ?
Давайте может человеку про MVC расскажем чтобы в общих чертах понимать начал, и не хранил html в базе. Прямо netcat style какой-то

[FanatPHP]

WarGot: откуда вы все лезете? Давайте вы сначала команде Тостера про MVC расскажете, чтобы она HTML в таблице комментариев не хранила. А потому же и там, грешным, счет истины изливайте. Deal?

[WarGot]

FanatPHP: Мы не лезем. Вы просто мимо проходили и в шоке от ответа на вопрос.
1. А откуда инфа что команда тостера хранит html в базе ? Исходный код тостера видели ? Не поделитесь ?
2. Разницу между html и размеченным текстом представляете ?
3. Лезем мы из рассылки тостера в которой этот пост упоминается.

[Орк]

ещё один супер программист: "не нужно хранить html в базе"...

Значит ты парень в своей жизни только html- странички и писал)..
Бываю такие задачи в практике, что БЕЗ ЗАПИСИ HTML сущностей В БД - НЕ ОБОЙТИСЬ!

[Александр Маджугин]

Матвей Уваров: пример и я тебе расскажу как обойтись без записи html в БД.
Не гарантирую, что это будет лучше или быстрее или дешевле. Не настаиваю, что так нужно делать всегда.
Но если это требуется, то с вероятностью 98% у вас что-то с архитектурой проекта не то.
Есть правда вероятность в 2% что это действительно нужно и целесообразно. Но скорее всего - нет.
Это как бег в мешках - глупо в них бегать. Медленно и неудобно. Но есть соревнования по бегу в мешках и если на них вы будете бежать без мешка - вас диквалифицируют.

Answer 4

[Владимир Балин]

Правильный ответ - не храните статичное в БД, вы же не храните там JS и CSS и версионировать неудобно. Если таки надо, что бы пользователь мог куски HTML править (например пользовательская шапка для его блога), то надо постараться держать все в UTF-8 и экранировать потенциальные MySQL-инъекции. Но и даже тут, лучше пусть в файлах все будет.

Comments

[FanatPHP]

Опять 25. Этот мой комментарий тоже в файлах хранить?

[Владимир Балин]

Аа... Ну понятно... Вы тут уже пробурлили на эту тему. Ясно. В любом случае в БД должна быть выжатая инфа, без разметки...

[Владимир Балин]

И, да, я не претендую не на что, - это - я так считаю

[FanatPHP]

Я понимаю, это узость кругозора. Ладно оставит Тостер, программистов которого ты считаешь лохами. Скажи, ты слышал о WYSISYG редакторах? TinyMCE, Imperavi? О старицах, создаваемых редактором сайта? С картинками, ссылками, шрифтовым выделением?

[Владимир Балин]

Дак естессено слышал, даже больше, - использовал, но если твой, мой милый тролль ))), кругозор, не позволяет тебе понять, что редактируемые фрагменты разметки (а оссобенно если они еще потом шаблонизатором парсятся), всетки можно и даже нужно стараться хранить таки в файлах, то - это значит мы смотрим на это по разному и не надо тут жечь напалмом ))))) Конечно бывают такие случаи когда надо хранить все это в БД, но они редки и их вообще лучше избегать... Простой пример: в статье с "богатым" форматированием должны быть фотки. И что? Вы собираетесь их контент прям в разметку засовывать? Ну неее... Извращение. Лучше загружать их вообще отдельно как прикрепления и накрайняк ссылки тут же выдавать для вставления их пользователем в редактируемый текст. Да и вообще, вариантов много, можно повсякому делать. Вы высказали свое мнение, я свое, давайте разойдемся.

[FanatPHP]

Ты заврался, мой мальчик. Покажи-ка мне шаблонизатор, который парсит "редактируемые фрагменты разметки". Ну и попробуй наврать, при чем здесь вообще шаблонизатор. А потом можешь расходиться

[Владимир Балин]

Г-н тролль, тут такое дело, что, например, твиг может парсить строки, которые могут быть чем угодно... И, да, я понял, почему мы не понимаем друг-друга, вы (и автор) говорите о контенте, генерируемом пользователем, а я о разметке страниц, которую пользователь может создавать сам, при этом тут и шаблонизатор. И не ведите себя как хам, а то стрёмно смотрится. И не вам решать, когда "можешь расходиться", грамотей ;)

[FanatPHP]

Автор вообще не говорит об источнике данных. Это вас, учителей неграмотных, набежало целое стадо, поблеять о своём. Что характерно, ответить на вопрос ни один не осилил.

[Владимир Балин]

В чем-то вы правы, например в том, что автор не упоминал источник. Но мы упомянули. И разобрались в том, что вас так беспокоит в моих ответах. И ЧСВ тешить нужно, наверно, в дргом месте, а не хвастать тут тем, что вы один поработали википедией в этом вопросе. И, представляете, вопросы могут еще вызывать другие вопросы и затрагивать не только те темы, которые автор предусматривал. Ведь на то он и тостер, что бы несведущих просвещать, разбираться в вопросах. А как это можно сделать, если вопрос некорректен или не полон? Ни как. Поэтому и раскрываются другие моменты, что не так уж и плохо. Может автор по другому взглянет на проблему. Ну, что бы наглядно свою мысль продемонстрировать, давайте рассмотрим вот такой диалог:
- (автор) как засунуть шар в треугольную дырку?
- (вы) надо сильнее давить (помечено как правильный ответ)
- (кто-то еще) надо взять треугольних
- (еще кто-то) надо в круглую дырку пихать
- (опять вы) "Автор вообще не говорит об круглости дырок. Это вас, учителей неграмотных, набежало целое стадо, поблеять о своём. Что характерно, ответить на вопрос ни один не осилил."

[FanatPHP]

Забавно. Я разобрался в вопросе, который и корректен, и полон, и вполне решаем. И ответил автору, разобрав все аспекты его проблем, как воображаемые, так и реальные. У тебя ума хватило прочесть только заголовок и разразиться пафосным оффтопиком, не несущим автору никакой пользы (поскольку очевидно, что его проблема вообще никак не связана с HTML). И при этом мой ответ ты называешь "дави сильнее". К просто дуракам я здесь привык, а вот подлеца встречаю впервые.

[copenhagen72]

Владимир Балин: Раз уж тут упомянули автора, скажу что ответ FanatPHP правильный, так как помог мне в решении. Ответы всех остальных аффтаров, и ваш в том числе, даже при моем небольшом опыте, видится мне феерическим бредом.
Вообще Тостер напоминает болото, где каждый "сам себе злобный буратино" выдвигает версию одна адовее другой. Далее приходит FanatPHP, бьет автора по рукам, если тот сильно косячит, дает содержательный ответ и в своей манере щелкает буратинам по носу, после чего болото начинает бурлить. У меня был простой вопрос, на который от силы можно дать пару похожих вариантов ответа, но нет - мне на почту высыпалась туча уведомлений с "бурлением".
Конкретно про ваш ответ: зачем хранить статьи в виде html кода в файлах, если давно придуманы базы данных, из-за боязни инъекций? Я не силен в программировании, может жизнь шагнула вперед и я что-то важное пропустил, может хранить данные в бд уже нем модно, в моде снова хранение в файлах? Не зря же, наверно, почти все мне про хранение в файлах говорят...

[Владимир Балин]

Молодец вы, молодец FanatPHP. Отлично поработали. Кто бы спорил. Вы меня еще попутно понаоскорблять успели сполна. Хотя моя мысль проста: не хранить разметку в БД. И, отвечать именно так у меня были причины. Хотя бы то, что автор может посмотреть на мое сообщение и подумать, например: "А ведь и точно, что-то в программе не так, если мне приходится таким заниматься, точно, надо шаблоны сторить в fs". А может ему точно надо хранить HTML или XML-подобную разметку в БД и никак иначе и он просто проигнорирует мое сообщение. Но, пока есть подозрение, что мой ответ поможет и может быть полезным, я его оставлю. И, заметьте, только вы ко мне придрались.

[FanatPHP]

Василий: не надо бредить.

[Владимир Балин]

Василий лучше не спорь с FanatPHP, а то он расскажет тебе, что суть вопроса автора не в том, что лучше, а что автор именно хотел узнать, и только он правильно ответил на этот вопрос ))) без обид

Answer 5

[D']

Для данных в которых могут быть спецсимволы (изображения, текст) я обычно перед отправкой в базу использую base64_encode.
Вообще делать htmlentities перед записью в БД нет большого смысла. Данные нужно экранировать во view перед выводом.

Comments

[FanatPHP]

Давай ты сотрешь свой ответ? Не стоит ничего кодировать base64 и ТЕМ БОЛЕЕ не стоит советовать этот адов костыль другим.

[D']

FanatPHP: оо, ты изменил комент и удалил грубость. Ты себя уже показал "дерево". Base64 отлично справляется со своей задачей для хранения данных со спецсимволами и непонятной кодировкой. Давай ты будешь умничать у себя в деревне, где все используют mysql с prepare, и не знают о существовании других типов и видов БД.

[FanatPHP]

что характерно, чувак использует htmlentities РОВНО для тех же целей, для которых ты используешь base64 - ради идиотского хака, обхоящего проблему кодировок. То есть, ты тупо предлагаешь ему поменять один костыль на другой, АБСОЛЮТНО идентичный, но при этом его похаиваешь :)

[D']

FanatPHP: htmlentities используется для других целей, а именно для защиты от XSS. base64 используется для сохранения целостности данных и их первоначального вида.

[FanatPHP]

ну вот, не зря я написал дерево :) Я даже хотел написать "чурка", но постеснялся цензуры. А потом и вовсе подумал, что негоже ругаться на человека, пока он не проявил себя как дерево. А вот теперь можно :) Base64 отлично справляется со своей задачей только у самых отмороженных ламеров, которые даже mysql не видели, и используют реляционную БД как key-value хранилище, не подозревая, что над содержимым ячеек можно проводить различные операции, такие как сортировка, фильтрация, поиск, и пр...

[D']

FanatPHP: да, делай поиск по картинкам, удачи. Ты себя проявил мастер.

[FanatPHP]

во-первых, картинки в БД хранят только нубасы. Нормальные чуваки картинки в БД не хранят, именно по этой причине: поскольку все вышеперечисленные операции нет смысла производить над блобами. Следовательно, нет смысла хранить картинки в реляционной БД. Она придумана для другого. Во-вторых, у автора там совсем не картинки. У него раза три написано, что именно он хранит в БД. Ты становишься очинь смищной мальчик когда оправдываешься :) Но самый, конечно, ад - это твое самомнение. Так дунуть в лужу и так наглеть - это надо уметь. Илитная гопота!

[D']

FanatPHP: да да, а еще в твоем мире все хранят неэкранированные данные и всегда обрабатывают их перед выводом, а еще в твоем мире никто не использует блобы, так как это фу и бяка.

Продолжай и дальше жить в своем ущербном мирке. Разговор окончен.

[FanatPHP]

Да, кстати, ты даже после моей подсказки не смог въехать, зачем аффтар делает htmlentities :) У тебя мозги забронзовели не успев вырасти. Рекомендую бросить программирование и пойти по партийной части - там это востребовано