Не правильно делаешь, надо на ромбики заменять. Ты вообще книжку по пхп брал в руки, хотя бы подержать? Почитай про sql injection и методы защиты.
Чувак, вот добавил в базу данных такое вот - "слово", 'слово' которые пойдут в теги title и description при выводе из БД. Что у тебя получится, подумай. Интересует больше не защита от sql injection, а ввод данных в БД с целью корректных выводов из неё в дальнейшем. Лучше обработать переменные один раз при вводе чем каждый раз обрабатывать их при выводе.
Ты с каменного века? Какие ромбики? Нонче в моде ASCII-смайлики-негры ☻! Что в базу введешь, то из нее и выведешь. Лучше кури защиту от инъекций нормальную, а не посредством порчи данных. Увы, тут тоже мимо. Хранить данные надо как есть. А обрабатывать перед отдачей. Потому как исходник потом хрен нароется.
Чтобы кавычки корректно добавились в базу, надо экранировать данные перед добавлением. Это же защищает от SQL-инъекций. Замена на "ёлочки" с целью корректного добавления в базу смысла не имеет. МОжно менять, если действительно надо потом выводить ёлочки
слушай людей. и еще, вот http://habrahabr.ru/post/148701/ только прочти)) Добавлено спустя 46 секунд: подобное уже на раз обсуждалось и на этом форуме, и лучший вариант был подобран, но увы не смог найти, выложите ссыль на топик
Это вы CSS с MySQL спутали. В БД вводится все как есть с экранами на зарезервированные символы, список прилагается NUL (ASCII 0), \n, \r, \, ', ", and Control-Z. Из БД выводится все как требует интерфейс. Если это HTML - значит в первую очередь htmenities() или по обстоятельствам. Миф про % и _ нестоятельный. Не надо их экранами закрывать.
Не заблуждайте народ. Экранирование защищает привод БД от попадания внутрь песка. Если песок попадет - будет скрипт, если все правильно сделано - его не услышит никто, если все сделано неправильно - никакое экранирование не спасет. Инъекции тут вообще не стояли. Добавлено спустя 9 минут 36 секунд: Про правильные методы: это по-нашему, да. Стопицот лет назад вопрос с ниппелем был решен на глобальном уровне, и только советские программисты не знали, типа на другом глобусе жили. Конечно не лучше, полностью наоборот. Бесконтрольный вывод означает что на ввод - на фронтир - ложится вся ответственность за будущие поколения. Достаточно одного пропустить и оба-на, ты - папа. В результате чего внутри тела скрипта зреет саркома - бесконечное преобразование из покоцанных на вводе данных в нормальный вид для вывода, типа ромбики обратно в кавычки, брекеты в шевроны, бры в переносы и тп. Так делали да, пока на глобальном уровне не было установлено что: Писать надо как есть Выводить как надо Добавлено спустя 5 минут 30 секунд: Простой формальный признак по которому легко диагностировать саркому: если хоть 1 раз у вас применяется функция nl2br, значит у вас саркома. Добавлено спустя 6 минут 39 секунд: Резюме (в контексте mysqli) на вводе real_ecsape_string() (с правильно установленной кодировкой заранее), на выводе в html - htmlentities (с правильной кодировкой установленной заранее). Не хотите кажный раз - делайте один раз ob_start(); include the_very_main_layout_under_all_site.php $content=htmlentities(ob_get_contents() // тут все правильные опции ob_end_clean(); echo $content; ну или типа того
Запись в БД Код (PHP): <?php $query = sprintf('INSERT INTO my_table SET text = "%s"', mysql_real_escape_string($text)); mysql_query($query); Вывод Код (PHP): <?php $query = mysql_query('SELECT text FROM my_table LIMIT 1'); $data = mysql_fetch_assoc($query); echo htmlentities($data['text'], ENT_QUOTES, 'UTF-8');
Логика в чем? Фильтруется введенное пользователем, например вернуть в форму данные после ошибки валидации, или напечатать сообщение на форуме, типа этого. Когда возникает много таких случаев, то пишется либа-прокладка между БД и выводом типа bbcode. Вот и все. Когда источник проверенный, то ничего не фильтруется вообще, иначе как вы будете хтмл выводить - ентитьками что ли?