Форум PHP

1. Тем что оригинал не изменяется. Но в вашем случае это не аргумент. Я понял.
2. Суперглобальные массивы лучше вообще не изменять. Я недавно столкнулся с одной CMS, которая просто валилась с фаталом, Когда полез в логи и код выяснять в чем дело, увидел такое объявление функции:

<?php   function funcname($_REQUEST, $params){     ..... тело функции ......   }

Я конечно офигел и не понял вообще зачем так делать в принципе. Но у клиента на пхп 5.2 оно работало. И оказалось, что начиная с пхп 5.4 взять вот так и полностью переопределить суперглобальный массив уже нельзя! И я не исключаю, что их со временем вообще запретят редактировать.

In english:
http://stackoverflow.com/questions/4882307/when-to-use-htmlspecialchars-function
http://stackoverflow.com/questions/7245440/should-htmlspecialchars-be-used-on-information-on-input-or-just-before-output
http://evertpot.com/when-to-escape-your-data/

Если мало, вот пара сот тыщ объяснений одного и того же:
https://www.google.ru/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#newwindow=1&q=htmlspecialchars%20before%20database

По русски - че-то беда с "по русски"..... Вот статья на хабре http://habrahabr.ru/post/143035/, но там автор как раз пропагандирует ваш подход. Поэтому можете сразу к камментам переходить. Там вы прочтете всю ту дискуссию, которая начинается здесь. И не вижу смысла продолжать ее здесь.

> В бд надо не скриптов бояться, а sql-инъекций.

sql-инъекций я не боюсь, я с ними борюсь с помощью функции mysql_escape_string

Ну а если без эпитетов вроде "паники", "насилуете" и т.д., а конкретно что криминального в этой строке
$_POST['name'] = htmlspecialchars($_POST['name']) ?

Пока я услышал такие доводы:
"нечего htmlspecialchars делать в начале скрипта"
"Потому что в таком случае, данные и в БД попадут обработанными. А в БД оно не нужно."
"вы уже в панике занимаетесь тем, чем вообще не стоит"
"Хотеть можно все что угодно. А правильно в данной ситуации так, как вам тут все говорят."

Из этого всего я так и не понял, почему я делаю неправильно.

Я так и не понял, чем это
$name = htmlspecialchars($_POST['name']);
лучше этого
$_POST['name'] = htmlspecialchars($_POST['name']);

Это не повод для паники.

>я фильтрую её один раз непосредственно после получения из формы.

Вы не фильтруете, вы насилуете. Ведь у вас даже проверки данных еще нет, а вы уже в панике занимаетесь тем, чем вообще не стоит.

Хотеть можно все что угодно. А правильно в данной ситуации так, как вам тут все говорят. В бд надо не скриптов бояться, а sql-инъекций. Ладно, не хотите слышать, не надо. Со временем сами придете к тому, о чем вам говорят....

А если не придете сами, то когда-нить устроитесь программистом, и тогда вам тим-лид или ведущий программист, увидев такое, просто скажет: "Чтоб такого больше не было!" =)
И это я перевел его гнусную брань на цензурный язык :D

P.S. А что вы будете делать с этими данными из БД, если они вам не в браузере понадобятся? Ну в эксель-таблице, например.... Обратно обрабатывать?
Можно не отвечать. Информация к размышлению.

> Потому что в таком случае, данные и в БД попадут обработанными

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

Лучше обрабатывать именно при выводе:

<?php   echo htmlspecialchars($_POST['name']);

Либо, если одно и то же значение выводится несколько раз, то чтобы не обрабатывать многократно, присвоить результат обычной переменной:

<?php   $name = htmlspecialchars($_POST['name']);   echo $name;

Но никак не:
> в начале скрипта обрабатываю данные через функцию htmlspecialchars
Потому что в таком случае, данные и в БД попадут обработанными. А в БД оно не нужно. Перед вставкой в БД нужно обрабатывать совсем другими функциями.
И даже если в данном конкретном примере у вас нет вставки в БД, все равно не нужно обрабатывать в начале скрипта. Потому что привыкнув обрабатывать так, а не правильно, в конце концов у вас где-то да закрадется ошибка, пусть даже в другом скрипте.