Из статьи я увидел что htmlspecialchars(); используется только для вывода. А если переменная которая приходит выводится без занесения в базу? Тогда разумнее экранировать её на входе, например:
name='Vasya', а кто-то возьмёт и впишет name='Vasya<br> ..(30 <br>).. <br>' =)??
Вывод будет очень интересен), да и каждый раз при выводе писать htmlspecialchars(); долго, быстрее ведь будет сделать это единожды в начале).

"mysql_escape_string() - работает только при открытом соединении" У меня оно открывается с самого начала:) т.е. в принципе тоже можно использовать + она используется в функции совместно с stripslashes, как я и писал выше.
Так почему тогда ужос?

А если потом захочется её где нибудь использовать?
Функция htmlspecialchars() предназначена для обработки данных для корректного отображения браузером. И только для этого. А в браузер данные отдаются не на входе, а на выходе.
В скрипте данные должны быть в том виде, в каком они получены.

Иначе получется через ж выход. Зачем переваривать пищу, когда можно сразу скушать г производный продукт...

А в этом какой смысл, если нет проверки get_magic_quotes_gpc()?
По крайней мере ты об этом не упоминал.

Насколько я себя знаю, этого не произойдёт, т.к. таким образом фильтруются только переменные вывода, например: логин, текст комментария и т.д. =)
Например, написал пользователь комментарий "/> (это из моей практики!), и? Естественно в базу лучше записать то отфильтрованное значиние.

magic_quotes_gpc() включена в конфиге, вместе с register_globals и выключеным safe_mode

Не знаю я какое это

но в базе должно храниться то, что написал юзер. А именно "/> а не &quot;/&gt; Иначе
1. Будучи повторно обработанными при выдаче функцией htmlspecialchars(), это и вылезет на экран в таком виде: &quot;/&gt;
2. Это сделает невозможным корректный поиск по базе.
3. Код, в которов все кверхногами, (а именно функции предназначенные для вывода используются на входе) становится трудночитаемым.
По этому такой вывод:
1. См мой предыдущий пост. Накормили базу тем, что нужно было нести в туалет.
2.

вспомнишь эти слова через некоторое время, когда захочешь чего нибудь модернизировать.
3. Если пишешь на корзину, то волен делать что хочешь конечно. Зачем тогда задавать вопросы... Напиши
$text = htmlspecialcars(trim(strip_tags(substr(stripslashes(и_так_далее и спи спокойно. Но посаран! Юзеры тоже.
Проще написать все в кучу, чем разобраться и расставить на свои места.

Вроде я писал что для вывода не использую эту функцию)

Почему же ? Если на входе поиска делать то же....

Код? Я ведь вроде бы говорил что это используется для комментариев, логинов и прочей мелкой чепухи.
Ладно, если всё дело заключалось только в особенностях написания каждого, а не безопасности и правильности отображения, тогда пойду дописывать)

Вот именно. В удобной тебе форме. То есть эта база будет жестко привязана к скрипту. Даже не к скрипту, а к его кривому исполнению.
База данных предназначена для хранения данных, а не особенностей мест, откуда растут руки. Данные эти могут быть обработаны и в другом скрипте. Полно случаев, даже далеко не надо ходить, тут на форуме, люди плачут и взывают о помощи, что им досталась кривая база по наследству.
Еще раз говорю, если пишешь на корзину, то делай что хочешь.
А если делать по человечески, нужно придерживаться общих правил.

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

Распространенное мнение, и мне оно кажется ошибочным.
Обосную на примере стандартных форумных ББ-кодов:
Пользователь вводит:

при просмотре отдается:

Предположим, страницу топика в среднем просматривают 1000 посетителей (на большинстве форумов больше, но возьмем эту цифру).
Если хранить в базе преобразованный код, преобразование выполняется ОДИН раз: при записи в базу.
Если хранить в базе исходный код, преобразование потребуется выполнять при КАЖДОМ запросе страницы.
Таким образом, хранение в базе преобразованного кода снизит ресурсоемкость движка в 1000 и более раз...

ИМХО, вопрос в задачах скрипта.
Например в форуме мы не разрешаем пользователям никакой ХТМЛ-код.

Если пользователь ввел <b>, тогда в базе буду хранить &lt;b&gt;
Если пользователь ввел [b], тогда в базе буду хранить <b>

Не правильный подход. Проверяться/защищаться должно все и вся, даже есть у тебя есть 100% уверенность что доступа в админку ни у кого кроме тебя не будет.
Взломают админку - утащут всю базу (самое безобидное).

Вот я и смотрю, нет у меня такого.
Я почему спросил. Во первых такую базу можно пользовать только под этим движком, перенести на другой уже сложно. Но это пол беды.
Главные проблемы (как я понял именно из за такой схемы), это вот:

и иже с ней. Особенно при редактировании, рвется постоянно.
Там обратное преобразование должно как то быть, я вообще не понял. Как ты в бб для редактирования переводишь html?
Не знаю, может я и не прав, но мне кажется так делать совсем ни к чему. Если

то тогда это надо кэшировать. И не только из за разметки а вообще. Что по моему у тебя очень грамотно реализовано. А в кэше уже должен быть html с эквивалентами, как и положено для html страничек. Это уже вывод.
А хранить разметку в базе...
Впрочем каждый сам решает, что ему больше по душе.

Тут дело не в этом вовсе, а в подходе. Если начинаешь изобретать велосипед, то можно такое седло ему приделать, что геморрой неминуем. Привычка рулит. И в мыслях не должно быть где то халявить, для себя любимого пишешь или на публику.

Проблема в другом.
Чтобы корректно работала highlight_string, нужен открывающий и закрывающий тег независимо от того, ввели его в коде или нет, поэтому используется конструкция:

Если же в коде после ?> используются еще какие-то ХТМЛ-теги, начинаются глюки.

Если напишешь лучше функционал подсветки синтаксиса - охотно использую. А тут я завяз и забросил.

Не вижу смысла. База содержит тот код, который отдается на экраны пользователей.
Тут же практически ситуация с вложенными циклами: цикл считывания записей из БД и для каждой записи цикл регулярок преобразования ББ в ХТМЛ.
Нерационально гонять вложенные циклы и затем кешировать, рационально один цикл провести при вводе информации в базу, а при выводе считывать цикл по строкам из БД.

Мне сложно судить, я плохо понимаю, как у тебя устроен кэш. Но сдается мне ты писал, что хранишь тексты в файлах, откуда и отдаешь в поток. Хотя может и путаю. Если так, то зачем на выдаче преобразования... А если нет, то что это за кэш такой интересный.
Бес с ним, не станем же сейчас препарировать форум

Основная кака с закрывающим тегом.
Если после него есть хоть один символ - глюки. Если два закрывающих - тоже глюки.

Руки не доходят выдернуть из геши массивы подстрок для окраски, и сделать обычными str_replace обрамление тегами цвета.

Именно так.
Например, для использования css в сообщении (кнопки нет, а возможность есть ):

Это не кеширование, это раздельное хранение.
Если размер сообщения больше 4000 знаков, в БД пишется один пробел, а текст пишется в файл.
При генерации страницы топика в цикле по строчкам таблицы БД условие: если в поле текста один пробел, то считывать из файла.

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

Код без подсветки, HTML и SQL не глючат. Глючит только пхп...

Ну тогда я вообще ничего не понимаю. Если реализован такой механизм, для чего в базе хранить разметку.
Во первых это увеличивает объём. Особенно подсветка. И не на маленько, а не порядки.
Во вторых, проблемы, описанные выше.
В третьих - обратное преобразование. Ты конечно сделал это уже, но ведь это как то не по людски...
4000 знаков, это ведь совсем не много. И вообще логичнее было бы просто уменьшить, если есть потребление. Или еще лучше - писать в файлы кроме объёмных рейтинговые страницы.

Если подсчитать (трудно это конечно) сколько ресурсов тратится на преобразование бб в разметку (на выдаче) при низкочастотных запросах и малом количестве текста с тем, сколько потребляется на вытаскивание текста с разметкой (то есть большего объёма), то не думаю, что будет выигрыш.

Можно посчитать. Страница текстового поиска по файлам совершает поиск за 4 секунды, считывая 3500 файлов (общий вес 160 Мб).
Значит, среднее время доступа к файлу 0,001 секунды при среднем размере файла 40 Кб.
В среднем на странице 15 сообщений. Страница с 600 Кб информации съест серверного времени 0,015 секунды.

Время запроса

при размере ячейки всего 4 Кб составляет в среднем 0,04 секунды, а при размере ячеек в 1 байт всего 0,005 секунды.
Значит, из БД страница весов 60 Кб будет генерироваться 0,025 секунды, а 600 Кб - вдесятеро дольше: 0,25 секунды.

Вывод: При равном размере, хранение в файлах дает выигрыш в скорости почти в 20 раз.

Хранение в БД текстов меньше 4 Кб оправдано по причине кластерности файловой системы. Если все мелкие сообщения скидывать в файлы, скорость-то возрастет, но будет с бешеной скоростью расходоваться дисковое пространство на хостинге.

У нас gZIP, поэтому разница будет 0,6 и 0,9 - всего в полтора раза.
И при ширине канала в 400 Мбит это такая мелочь, которой можно просто пренебречь.
Я в тестах использую 7-меговый текст, 1,3 Мб под gZIP-ом. Это предел, который может вытянуть наш движок на 24-х Мб, выделенных пхп.
Мы же на выводе делаем массу замен; те же макросы, те же шаблоны.

На ввод я могу вколотить и 15-меговый текст, он нормально преобразуется и запишется, только на экран его не получишь, "эксцид мемори".


Но главной для меня является даже не столько ресурсоемкость, сколько безопасность.
В нашем движке в принципе запрещено принимать на вход служебные символы: никаких кавычек никакого формата, никаих амперсандов, никаких угловых скобок, даже восклицательный знак преобразуется в метасимвол #33.
Паранойя? Зато линейку 1.х не удалось взломать ни разу с 2005 года. В других форумах случаи взлома и выходы новых патчей безопасности происходят практически ежемесячно.

Не знаю. Преобразование символов в эквиваленты на входе мало имеет отношения к безопасности. Фильтрация до добра редко кого доводит. Безопасность это правильная обработка, а не запреты и замены. Они порождают массу неоправданных сложностей и неудобств. А ломают форумы совсем не обязательно такими методами.
Хотя опять повторюсь - каждый пляшет как он хочет.
Пусть будет так.

PS. kirik
А где взглянуть можно?