Насчет фильтрации и хранении данных.

Брррр почитал, аж голова разболелась!!!

У mysql_real_escape_string() Есть свои приколы, она не все кавачкы икранирует, и иногда бывает, а у меня очень часто, ошибка записи при обычных кавычкаъ... ''
Лучше фильтровать через check() хоть она и многое режет, но надежнее. Там вырезается всё, что можно.
СУГУБО ИМХО.

nVirus (17.07.2009/09:05)
У mysql_real_escape_string() Есть свои приколы, она не все кавачкы икранирует, и иногда бывает, а у меня очень часто, ошибка записи при обычных кавычкаъ... ''
Лучше фильтровать через check() хоть он

Чтоб дать правильный ответ, давай заглянем в теорию.

Для чего нам вообще нужно резать кавычки?

Тут опять таки, нужно разбить на 2 пункта.
1) Мы принимаем данные от пользователя и добавляем их в базу данных.
2) Мы извлекаем данные из базы и выводим их в браузер (чаще всего)

Опять вернемся к первому вопросу, для чего резать кавычки?
Ответ - для исключения SQL инъекции.
mysql_real_escape_string() как раз и предназначена для этого. Она экранирует те кавычки (') которые интерпретируются базой как коммандные и являются опасными.
Другие кавычки не представляют для нас опасности при добавлении в базу данных.

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

Но по любому, естть хорошее правило, что данные лучше всего хранить именно в том виде, как они заносились.
Функция check() совмещает в себе и входную (эскейп) и выходную фильтрацию.
Для мелких, однострочных текстовых полей, это вполне применимо.
Но вот для сложных, больших текстовых массивов, особенно с разбивкой по страницам, подобная функция только мешает.

К примеру, избавиться от ошибок XHTML на форуме мне удалось только тогда, когда я полностью исключил функцию check() при добавлении данных, а разбил фильтрацию на вход-выход, как я писал выше.

AlkatraZ, Это да, но у тебя в форуме посты то обрезаются и если фильтровать данные через check(), то они все записываются в формате (не помню как звать (), а если такое обрезать, получается ошибка в xhtml... Я если честно фильтрую только через htmlspecialchars() с полным вырезом всего, что можно ), пришлось это делать из за функции mysql_real_escape_string(), которая у меня почти постоянно вызывала ошибку при оденарных кавычках. Юзерам это ужс как не нравилось... Ну а вообщем я с тобой согласен на счёт фильтрование входящих и отображаемых данных, это самое приемлимое ))

Да ну нафиг, check() надо при добавлении юзать, ибо при выводе сильно пострадает генерация

Studentsov, Генерация генерацией, но все же при выводе лучше всего применять htmlspecialchars() и другие подобные функции. Это можно хорошим тоном считать, но не наоборот.

Piks (21.07.2009/13:15)
при выводе лучше всего применять htmlspecialchars() и другие подобные функции. Это можно хорошим тоном считать, но не наоборот.

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

Tzeentch (21.07.2009/13:43)
естественно лутше, большинство кодеров на это и перешли раньше не замечал, все фильтровали (ну или не фильтровали ) а сейчас наконец то пришли к верному решению..ведь данные нужно хранить в той

Я тест проводил, генерация в 2,5 раза сокращалась если мой способ юзать

Studentsov, Это капля в море. Порой, есть места, которые на много больше увеличивают генерацию, в этом направлеоии и нужно капать.

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