Ответ 1
Точно так же (для драйвера MySQL):
- Прогоняет
mysql_real_escape_string()(это будет в 99% случаев) - Возвращается к
mysql_escape_string() - Возвращается к
addslashes() - В ручном режиме выходит
%и_вLIKEс помощьюstr_replace()
/**
* Escape String
*
* @access public
* @param string
* @param bool whether or not the string will be used in a LIKE condition
* @return string
*/
function escape_str($str, $like = FALSE)
{
if (is_array($str))
{
foreach ($str as $key => $val)
{
$str[$key] = $this->escape_str($val, $like);
}
return $str;
}
if (function_exists('mysql_real_escape_string') AND is_resource($this->conn_id))
{
$str = mysql_real_escape_string($str, $this->conn_id);
}
elseif (function_exists('mysql_escape_string'))
{
$str = mysql_escape_string($str);
}
else
{
$str = addslashes($str);
}
// escape LIKE condition wildcards
if ($like === TRUE)
{
$str = str_replace(array('%', '_'), array('\\%', '\\_'), $str);
}
return $str;
}
Обратите внимание, что это просто экранирование символов, поэтому запросы MySQL не будут ломаться или делать что-то неожиданное и используются только в контексте запроса к базе данных для обеспечения правильного синтаксиса на основе того, что вы передаете ему.
Нет никакой магии, которая делает все данные безопасными для любого контекста (например, HTML, CSV или XML-выход), и на всякий случай, когда вы задумывались об этом: xss_clean() не является решением одного размера и он не на 100% пуленепробиваемый, иногда это на самом деле совершенно неуместно. Класс Active Record автоматически выполняет запрос, но для всего остального вы должны избегать/дезинформировать данные вручную правильным образом для данного контекста с помощью вывода, а не вашего ввода strong > .