неправильное какое-то определение. В db-интерфейсах реализовано и экринирование, и binding. Скорее "давайте ограничим пользователя в том, куда и что можно вставлять, в надежде, что он на этом и остановится"

это еще надо доказать

mysql_real_escape_string ничего не искажает

у кого? Да и мало ли почему jolly-wind.ru могло не спасать одно экранирование

Экранирование реализовано средствами самого php, так? Мы экранируем данные, запихиваем их в запрос, отдаем библиотеке для работы с БД. В то время как
prepared statements - фича базы данных.

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

ты ошибаешься. Ты, наверное, имел в виду get_magic_quotes_gpc() и addslashes/stripslashes

и тем не менее ему как-то удается

<?
mysql_connect('localhost', <login>, <passwd>) or die(mysql_error());
mysql_query('SET NAMES cp1251') or die(mysql_error());
mysql_select_db(<db>) or die(mysql_error());
mysql_query('DROP TABLE IF EXISTS t1') or die(mysql_error());
mysql_query('CREATE TABLE t1 (f1 TEXT CHARACTER SET cp1251)') or die(mysql_error());
$s = '';
for( $i=0; $i<256; $i++ )
    $s .= chr($i);
$_s = mysql_real_escape_string($s);
mysql_query("INSERT INTO t1 VALUES ('$_s')") or die(mysql_error());
$r = mysql_query('SELECT * FROM t1') or die(mysql_error());
$r = mysql_result($r, 0, 0);
if( $s != $r )
    die('mysql_real_escape_string sucks!!!');

и по поводу этого:

я не умею решать несуществующие проблемы. Если у них что-то не получилось, надо разобраться, что именно и почему. А не сразу делать вывод, что экранирование не работает

приведённый пример-это общий случай. в частном не пройдёт-вероятность возникновения частного минимальна конечно но всёже.
и всё равно эта полемика интересна-но меня интересует всего один вопрос(точнее группа вопросов)-заданный в начале этого топика
1 возможно ли слепить строку из строк с разными кодировками?-на клиенте
2 возможно ли сменить тип кодировки во время прередачи данных,или всёт аки передастся в той кодировке что указанна в странице?(одно упоминание я нашел что при гет и посте данные передаются в юникоде)-на клиенте
3. если всётаки можно изменить кодировку-можно ли скрипту рнр дать инструкции в этой строке указывающие на тип кодировки?
P.S никто не говорил что оно не работает-было сказано что оно не помагает в некоторых случаях инъекций.и то что в некоторых ситуациях оно может изменить исходную строку-что не желательно

в каких?

в каких?

повторюсь, я не умею решать проблему, не видя в чем она состоит. Но ты можешь подождать, пока кто-то другой ответит на твои вопросы

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

Да, это и имел в виду. Просто мне метод prepare-bind-execute кажется более правильным, нежели do.

правильность - это не аргумент