Делаю поиск для форума. Все как бы работает уже, но есть еще одно "но". Поиск производится по полю text (сообщения юзеров), и в этом поле есть теги. Мне нужно чтоб командой SELECT * FROM forum WHERE text = 'query' искало не включая тех тегов. Просто сделал подсветку для найденого и если попытаться найти '<img', то этот тег заменяется на "подсветку" и получается такое - <span style=""><img</span> и на странице фигня выходит :? В идеале должно быть так SELECT * FROM forum WHERE strip_tags(text) = 'query'. Но так нельзя. Есть у когото идеи? Кстати, делать strip_tags для самого запрашиваемого слова 'query' както тоже не вариант, поскольку если вбить strong - то функция этого не вырежет, но слово (а это будет тегом) найдется и заменится.
Апельсин ага, щаз разбежались все отвечать на вопрос, который изложен не до конца понятным зы: и к тому же в бредовом стиле, когда человек не понимает о чём говорит... так что можешь попробовать перезадать
В бредовом стиле тут разве что ты пишешь. Непонимание вопроса не обязательно свидетельствует о его неправильной формулировке, а иногда об умственной неспособности его понять. Тему закройте, сам разберусь. спс.
Апельсин, виноват всегда более умный, в том, что не смог понять дурака. Вы все еще настаиваете, что виноват Костян?
а что непонятного в вопросе? единственно, что меня напрягло SELECT * FROM forum WHERE text = 'query' может вместо равенства использовать like? нда, задачка нетривиальная. я б не стал подсвечивать с пом. sql, ибо сложно такую логику заложить в запрос. вообще, самое простое, по-моему, подсвечивать на стороне клиента жаваскриптом. обходим DOM-элементы, и реплэйсим их innerText.
Апельсин поверь я много вопросов видел, у тебя есть места где он противоречит себе же... а правильно поставленный вопрос уже половина ответа. Не надо нервничать. Спроси по нормальному, что тебе надо искать без тегов или подсвечивать их или всё вместе...
engager Да, там действительно LIKE упустил, так как запрос большой, не стал копировать. Вот примерно такого вида формируется запрос (зависит от критериев самого поиска, по которому ищет юзер): [sql]SELECT `id`, `ulogin`,`user_id`,`date`, `text` FROM `forum_posts` WHERE (`text` LIKE "%bbbb%" OR `text` LIKE "%gggggg%" ) ORDER BY `date` LIMIT 10[/sql] Для тех у кого рядом холодильник повторю. При таком запросе все что требуется - находит. Но поле `text` содержит контент вместе с тегами. То есть примерно вот такого вида: Выходит, что если юзер будет искать по ключевому слову strong, то поиск найдет все теги, а не действительно нужную инфу, например, может он хотел найти фразу "strong man", а найдет хлам в виде "<strong>ы</strong>". Поэтому и спрашивал, как урезать все теги чтоб поиск производился без их учета. engager Подсветка сделана на стороне не mysql, а пхп. Написал функцию, которой передается кусок текста и искомое слово, и она (функция) это слово обрамляет вот так - <span style="">слово</span> Кстати, я в js не силен, но с ним тут тоже не справиться. Ошибка будет еще до подсвечивания, потому что mysql ведь найдет слово strong в какойто части текста и выдаст этот результат. Пример: ищет юзет "strong man", mysql находит слово strong в тексте "<strong>woman</strong>" но как тег и выдает результат что найдено. А найдено то что? Совсем ведь не то что искали. ПОэтому повторюсь - в идеале должно было бы быть вот так: [sql]SELECT `id`, `ulogin`,`user_id`,`date`, `text` FROM `forum_posts` WHERE (strip_tags(`text`) LIKE "%bbbb%" OR strip_tags(`text`) LIKE "%gggggg%" ) ORDER BY `date` LIMIT 10[/sql] но синтаксис sql не допускает вставки функции strip_tags в запрос. Вот и гемор, как сделать аналогичный эффект.
стрип_тэгс, это конечно хорошо, только вот я не понимаю, как ты собираешься восстанавливать после замены (подстветки) уже "подсвеченный" текст в первозданный вид? ну грубо говоря сделать unstrip_tags. или такой задачи не стоит? если нет, то конечно тупо сделать уже в пхп-скрипте стрип и подсветку. MySQL абстрагирован от задач веб-программирования, поэтому есессно, у него вряд-ли будут такие специфичные функции типа strip_tags
ща буду глупости говорить: можно хранить отдельно индекс страниц, без тэгов, всяких «в», «на», значков препинания и прочего мусора, который не используется в поиске. И искать по этой таблице. А ещё вопрос как у вас организована подсветка… PHP: <?php $text = 'текст <strong>Strong</strong> <em>man</em> ещё текст'; $words = array('strong', 'man'); foreach ($words as $v) { $text = preg_replace('/>([^<]*)('.$v.')/usi', '>\\1<span style="color:#cc0000">\\2</span>', $text); } echo $text; но это всё глупости и никто не мешает делать свои велосипеды
Luge PHP: function backlight($text_b, $word_b) { $new_b = $text_b; for($i = 0; $i < count($word_b); $i++) { $new_b = preg_replace('/('.$word_b[$i].')/i','<span style="background-color:red">$1</span>', $new_b); } return $new_b; } На выходе - тот же самый текст что и на входе, на с подсвеченными словами. Про индекс страниц - отдельную таблю (поле) делать чтоли? Это ведь форум, "потолстеет" резко бд в обьеме тогда. engager Если запрос такой был бы [sql]SELECT `id`, `ulogin`,`user_id`,`date`, `text` FROM `forum_posts` WHERE (strip_tags(`text`) LIKE "%bbbb%" OR strip_tags(`text`) LIKE "%gggggg%" ) ORDER BY `date` LIMIT 10[/sql] то я получал бы точно такой текст, strip_tags ведь применяется тут для условия поиска, а не для обработки того что выведется. Иначе говоря, без тегов мы бы получили, если б заюзали вот так [sql]SELECT `id`, `ulogin`,`user_id`,`date`, strip_tags(`text`) FROM `forum_posts` WHERE (`text` LIKE "%bbbb%" OR `text` LIKE "%gggggg%" ) ORDER BY `date` LIMIT 10[/sql] Так что ничег овосстанавливать не нужно. На форумах типа этого, ищет же без тегов. Вот не знаю как на больших форумах реализован подобный поиск.
Апельсин те, у кого рядом холодильник хранят текст в базе в виде исходного, где тегов еще нету и благодаря этому не попадают в такие ситуации как ты.
любой СУБД абсолютно наплевать на данные. Тэги, числа, картинки — всё это для неё абстрактные и ничего не значащие понятия. Я предложил свою работающую глупость, Вы можете придумать свою, Simpliest сейчас ещё что-нибудь предложит А ещё, сообщения хранят с нераспарсенными BB-кодами не просто так
Luge Хранить в ввиде бб не тру. У меня при добавлении сообщения из бб в хтмл конвертирует, тем самым удаляя возможные xss и прочие шалости экспериментаторов, оставляя только разрешенные теги.
ну да, конечно. А сейчас я порву этот форум, phpBB, ведь, хранит данные именно в BB-кодах <script>alert('Mega Hack')</script> <script>alert('Mega Hack')</script> <script>alert('Mega Hack')</script> [js]<script>alert('Mega Hack')</script>[/js] чёрт, не получилось
это уже сто раз обсуждалось тру или нет. За то чтобы хранить чистые данные больше "за" чем "против". Если интересно поищи соответствующую тему. На крайняк можешь хранить сообщение в обоих видах.
Luge Это ни о чем сейчас сообщение было. То, будет храниться в виде [strong] или <strong> - никак не повлияет на "находимость" слова "strong" - и так, и так найдет. А лично для меня приемлем вариант записи по такой схеме: 1. Имеем "<script>alert('Mega Hack')</script>" 2. При записи в базу конвертируем разрешенные бб в хтмл, остальные теги превращаем в мнемоники. 3. При выводе выводим все "в готовом" виде, ничего не преобразуя. Даже htmlspecialchars() юзать не нужно, так так текст был проверен еще перед записью. Быстро и просто, чем перед выводом бб в хтмл перекидывать для каждого сообщения. Если я все правильно понял. Костян См. первое предложение в этом посте. бб тут не решает проблему. второе точнее.
ну, ни о чём, так ни о чём, кто ж спорит? Кстати, не [strong], а не спорю, теперь решите свою же задачу с поиском
это не проблема... Я тебе говорю, если хочешь всё находить, храни в чистом виде, без биби тегов, мнемоник твоих или чё там еще, и в другом виде в котором выводишь. Тогда ты найдешь топики где есть у тебя слова те что надо по "чистому" тексту, а обрабатывать будешь "грязный". Ну а там как ты это будешь отображать это уже другое дело. Один хрен смысла распарсивать весь результат нету, так как нет смысла его весь отображать. Десяток распарсил и всё. Я же надеюсь ты не будешь выводить сразу сотню результатов.
Luge Разве есть какаято стандартизация в бб?))) Если память не изменяет, strong более новей тег, чем b, но имеено b более помнится всем. Потому, возможно, его используют. Хотя в регулярке ничто не мешает поставить megatag вместо b и сделать это работоспособным. Но меня совсем другой вопрос сейчас интересует.
Костян Лимит установлен в 10 записей на страницу. Нагрузок не будет на базу. Если выход только в создании второго поля, то прийдется так и делать.
есть исторически сложившийся набор BB-тэгов, как они будут интерпретироваться — это другой вопрос, но, классический, всё же , а не [strong]. И большинству привычней набирать именно . Но это всё лирика. Теперь к нашим баранам. Теретически, можно избавиться от тэгов при поске используя в запросе регулярки, но вот это точно уже не тру. Как хранить данные — личное дело каждого, но, в любом случае, для поиска надо надо иметь текст без паразитных элементов (читай тэгов и т.д. и т.п.) иначе будет как раз ситуация со Strong man и <strong>. Если не жалко ресурсов php, то можете сделать дополнитеьную фильтрация полученных из БД результатов, но, это опять же, не есть тру. Уговаривать и настаивать на конкретном решении не хочется.