Mysql как записать html код

Запись в базу данных mysql на php через форму

Рассмотрим на примере, как создать форму, с помощью которой мы будем делать запросы в базу данных mysql на языке php, используя PDO.

1. Создадим разметку html-формы

Форма отправляется методом POST и обрабатывается на текущей странице.

2. Создадим таблицу, в которую будем записывать данные

Можно выполнить через SQL в PhpMyAdmin или ручками.

CREATE TABLE `mytable` ( `id` int(20) NOT NULL PRIMARY KEY AUTO_INCREMENT, `name` varchar(255) CHARACTER SET utf32 NOT NULL, `text` text NOT NULL ) 

3. Подключимся к базе данных и напишем запрос для записи.

Подключимся к базе данных.

// Переменные с формы $name = $_POST['name']; $text = $_POST['text']; // Параметры для подключения $db_host = "localhost"; $db_user = "user"; // Логин БД $db_password = "123"; // Пароль БД $db_base = 'mybase'; // Имя БД $db_table = "mytable"; // Имя Таблицы БД try < // Подключение к базе данных $db = new PDO("mysql:host=$db_host;dbname=$db_base", $db_user, $db_password); // Устанавливаем корректную кодировку $db->exec("set names utf8"); > catch (PDOException $e) < // Если есть ошибка соединения, выводим её print "Ошибка!: " . $e->getMessage() . "
"; > 

Кодировку установили, чтобы избежать лишних проблем (не обязательно).

Не забудьте заранее создать таблицу в базе данных с трёмя значениями (id, name, text), подробнее об этом читать здесь.

Далее напишем наш запрос для записи в базу данных и запишем его в переменную.

// Собираем данные для запроса $data = array( 'name' => $name, 'text' => $text ); // Подготавливаем SQL-запрос $query = $db->prepare("INSERT INTO $db_table (name, text) values (:name, :text)"); // Выполняем запрос с данными $query->execute($data); 

Здесь мы сначала все наши данные для записи записываем в переменную $data, затем подготавливаем запрос с плейсохледарами (переменные) и выполняем запрос передавая ему данные для заполнения из $data

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

if ($result)

4. Подключение формы к запросу

Форму создали, к базе подключились и написали запрос, теперь нужно связать всё это.

Форма отправляется методом POST, поэтому мы можем сделать проверку на него, а именно на любое поле формы.

У нас передаются поля с именами «name» и «text», на них мы и сделаем проверку.

Вставим весь наш скрипт в эту проверку:

if (isset($_POST['name']) && isset($_POST['text']))< // Переменные с формы $name = $_POST['name']; $text = $_POST['text']; // Параметры для подключения $db_host = "localhost"; $db_user = "user"; // Логин БД $db_password = "123"; // Пароль БД $db_base = 'mybase'; // Имя БД $db_table = "mytable"; // Имя Таблицы БД try < // Подключение к базе данных $db = new PDO("mysql:host=$db_host;dbname=$db_base", $db_user, $db_password); // Устанавливаем корректную кодировку $db->exec("set names utf8"); // Собираем данные для запроса $data = array( 'name' => $name, 'text' => $text ); // Подготавливаем SQL-запрос $query = $db->prepare("INSERT INTO $db_table (name, text) values (:name, :text)"); // Выполняем запрос с данными $query->execute($data); // Запишим в переменую, что запрос отрабтал $result = true; > catch (PDOException $e) < // Если есть ошибка соединения или выполнения запроса, выводим её print "Ошибка!: " . $e->getMessage() . "
"; > if ($result) < echo "Успех. Информация занесена в базу данных"; >> 

То есть, если существует значения «name» и «text» переданные методом POST, то выполняется подключение к БД и запись в таблицу.

Запись HTML кода в MySQL

Доброго времени суток,
прошу подсказки по стандартным способам мнемонизации HTML кода для внесения в БД и его последующего извлечения оттуда.
В наличии MySQL + Lazarus.

Суть проблемы: HTML код содержит одинарные и двойные кавычки, слеши и т.п., что блокирует выполнение стандартных команд SQL.

попытка выполнения кода

SQLQuery.SQL.Add(‘Insert into source’);
SQLQuery.SQL.Add(‘(HTML) ‘);
SQLQuery.SQL.Add(‘Values (:pHTML);’);
SQLQuery.Params.ParamByName(‘pHTML’).AsString:=A;

ожидаемо приводит к RunTime Error с комментарием о несовпадении числа столбцов в 2 и 3 строке.

в PHP есть функция addslashes(строка) проводящая мнемонизацию служебных символов при записи в БД, прошу подсказки в отношении возможных аналогов в Lazarus или эту проблему лучше решать самостоятельно? (функция замещения спецсимволов вещь не самая сложная в исполнении, однако не хочется изобретать велосипед).

Как хранить HTML в БД?

Мужики, есть админка. Основное поле textarea, которая вводит и выводит текст страницы с разметкой (HTML код).
При сохранении используется функция mysql_real_escape_string(). Хранится HTML код в БД тоже в чистом виде. То есть вписали в textarea Тест. Это же сохранилось в БД. Это же и надо получить.

А когда повторно открываю страницу редактирования, то появляются кавычки, особенно это касается, если я вставляю Тес’т

Наверно тут надо задействовать функцию stripslashes(). Но не совсем понимаю порядок.

Еще и в файле htaccess стоит php_flag magic_quotes_gpc off.

Может есть подробный мануал, как сохранять и выводить данные безопасно в textarea?

Цель: сохранить HTML код в textarea с защитой от инъекций и вывести этот текст и в textarea и на странице одинаково. Ранее для админки использовали phpmyadmin. Туда напрямую сохраняли HTML код. Но появилась потребность сохранять код не в pma, а через мини админку, которую надо защитить.

• Вопрос задан более трёх лет назад
• 1411 просмотров

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

Каким образом необходимо обрабатывать текст и 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.

• Вопрос задан более трёх лет назад
• 19015 просмотров

Комментировать
Решения вопроса 1

Чебуратор тега РНР

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

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

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

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

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

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

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

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

Вот с этого и надо было начинать. У тебя проблема с кодировками.
Ответ написан более трёх лет назад
Нравится 7 2 комментария

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

megahanga, ооооо, очередной вундеркинд 🙂
Тебе мамка-то разрешает в интернете так поздно сидеть?
Ответы на вопрос 4
Saboteur @saboteur_kiev
software engineer

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

Ответ написан более трёх лет назад
Комментировать
Нравится 2 Комментировать

Александр Маджугин @Suntechnic

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

Ответ написан более трёх лет назад
Нравится 1 23 комментария

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

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

Александр Маджугин @Suntechnic
FanatPHP: ответ на что?

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

Александр Маджугин @Suntechnic

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

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

Александр Маджугин @Suntechnic

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

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

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

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

Александр Маджугин @Suntechnic

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

Александр Маджугин @Suntechnic
Это ты HTML назвал удобным инструментом? Ну тогда да — понятно.

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

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

Александр Маджугин @Suntechnic

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

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

Александр Маджугин @Suntechnic

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

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

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

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

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

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

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

Александр Маджугин @Suntechnic

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

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

Ответ написан более трёх лет назад
Нравится 1 14 комментариев

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

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

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

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

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

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

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

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

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

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

copenhagen72 @copenhagen72 Автор вопроса

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

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