Что делать с данными, приходящими от пользователя?

[_RVK_]

Что делать с данными, приходящими от пользователя?

Сегодня, с удивлением для себя, обнаружил что не все согласны с тем, что данные, приходящие от пользователя, нужно сохранять в БД, так, как есть (естествено, проескейпив перед этим служебные символы), и только при выводе обрабатывать их, так как это требуется.

Пример этого форума:
</TD></TR>

Как вы обрабатываете даныные в своих скриптах? Какие функции применяете перед добавлением в БД, какие при выводе? Главное почему. Ваши доводы.

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

Пример выделен синим. Нажимая на "редактировать" я получаю то, что писал. Значит в БД это хранится именно в таком виде, и только при выаоде обрабатывается htmlspecialchars.

 

[SiMM]

> Сегодня, с удивлением для себя, обнаружил что не все согласны с тем, что данные, приходящие от пользователя, нужно сохранять в БД, так, как есть
Я даже больше скажу. Тот же IPB (что меня всегда удивляло) хранит в базе черт знает что. Получается двойная обработка данных - при вводе пользователем и при выводе. Если бы этим исключалась обработка при выводе - ещё можно было бы понять мотивы (хотя какие там мотивы при выводе 15-30 сообщений на странице?), но поскольку она не исключается - лично мне мотивы непонятны. А если нужно ещё что-нибудь кроме HTML иметь - так это жуть просто какая-то получается.
PS: сам предпочитаю делать это при выводе. При вводе максимум - избавиться от "лишних" слэшей.

 

[_RVK_]

SiMM
ХОчешь сказать что HTML обратно преобразовывается?

 

[SiMM]

_RVK_, нет. Всё гораздо запущенней. BB-коды при вводе преобразуются в другие коды А те, в свою очередь, в HTML при выводе. Ответ на вопрос "зачем плодить сущности" лично мне неизвестен
А.. не въехал сразу. Ну так вот, в случае необходимости редактирования эти "другие коды" преобразуются в BB-коды. Вот такие вот перипетии

 

[_RVK_]

Тема не строль проста, как кажется. Чего только я не видел перед добавлением в БД. Начиная от trim и кончая жуткими регами. Мне кажется нужно как-то поределить общую политику, обозначить общее мнение.

Или, все же, общего мнения тут быть не может?

 

[svetasmirnova]

_RVK_
Сохраняю "как есть", если бизнес-логикой не предусмотрено обратного.

 

[sakon]

_RVK_
Извечная проблемма щита и меча.
щит - недоверять вводу пользователя
меч - отсечь все лишнее при выводе.

 

[_RVK_]

svetasmirnova
Интересен вариант когда предусмотренно.

 

[svetasmirnova]

sakon
А почему эти подходы конфликтуют? Одно другому не мешает совсем.

 

[white phoenix]

я считаю что нужно всю информацию типа BB-кодов и т.д. хранить в БД "как есть", и только потом обрабатывать. доводы:
+ такой подход позволяет корректо редактировать значения
+ позволяет изменять механизм обработки кодов
- небольшие потери в скорости

 

[_RVK_]

white phoenix
BB тут непричем. Дело в HTML, JS и прочих, обрабатываемых браузерами, примочках.

 

[SiMM]

> + такой подход позволяет корректо редактировать значения
Я бы сказал - позволяет это делать просто, а не через заднее кирильцо.

 

[svetasmirnova]

_RVK_
Покопалась
От банального trim: зачем хранить лишние пробелы. Это не относится к "свободному тексту" a-la форум, конечно. Также удаление лишних символов. Например, хранятся телефоны. Люди их вводят "как хотят", а при выводе и для поиска хорошо бы стандартизировать. При поиске понятно почему: "22 333 22" и "2233322" - это разные строки. Плюс из "2233322" проще сделать любое форматирование, чем из разнокалиберных.
Есть ещё фильтры для булёвых значений.

 

[_RVK_]

Света, в каких случаях нужно обрабатывать данные при сохранении в БД? Подчеркну, не проверять, а именно обрабатывать.

-~{}~ 15.12.05 00:27:

много пробелов внизу

-~{}~ 15.12.05 00:29:

Да, обрезает

Насчет телефонов.... не совем согласен. Либо добавлять как есть, либо говорить пользователю перед добавлением что формат неверен

 

[sakon]

>Насчет телефонов....
Вот здесь (imho) все же лучше предварительно обработать, что бы в базе лежали в стандартизованном виде. И поиск проще будет.
Хотя это и частный случай.... Но все же.

 

[_RVK_]

>стандартизованном виде. И поиск проще будет

Хорошо, обработай этот телефон: !@#$%^&*()_+

 

[svetasmirnova]

_RVK_
Я примеры привела с тем, что в базе лежит. Про булёвые подробнее? Фактически это не ввод в поле input, а checkbox или radio. Какое-то у него значение. Преобразуется в булёвое и сохраняется в базу.
Ещё вариант: дата.
Причём данные типа булёвых и дат всё равно на соответствие ожидаемым надо проверять. Поэтому необязательно получать из формы дату в том формате, который будет в базе. И преобразовывать из человекопонятного в структурированный вид - это нормальная практика.

Вообще все такие случаи по определению частные. Естественно, можно заставить пользователя ввести данные в нужном формате. Но вспомните западные сайты с их непременно 5-ти значным обязательным (!) полем zip

 

[white phoenix]

_RVK_
> либо говорить пользователю перед добавлением что формат неверен
я пойду повешусь тогда

 

[svetasmirnova]

>Хорошо, обработай этот телефон: !@#$%^&*()_+
Я же не говорила про такой случай. Достаточно проверить, что введены цифры, скобки, дефисы и пробелы. Причём цифр не менее 5. Не сложно =)

 

[_RVK_]

svetasmirnova
Почему тогда не проверить что введены только числа если допустимые скобки и дефисыты все равно режешь?