real_escape_string не очистка введенного текста

Question

Я думал, что правильный способ «санитарной обработки» входящие данные из HTML-формы перед тем введя его в базу данных MySQL, чтобы использовать real_escape_string на него в PHP скрипт, например:

$newsStoryHeadline = $_POST['newsStoryHeadline']; 
$newsStoryHeadline = $mysqli->real_escape_string($newsStoryHeadline); 
$storyDate = $_POST['storyDate']; 
$storyDate = $mysqli->real_escape_string($storyDate); 
$storySource = $_POST['storySource']; 
$storySource = $mysqli->real_escape_string($storySource); 
// etc. 

И как только это будет сделано, вы можете просто вставить данные в базу данных, как это:

$mysqli->query("INSERT INTO NewsStoriesTable (Headline, Date, DateAdded, Source, StoryCopy) VALUES ('".$newsStoryHeadline."', '".$storyDate."', '".$dateAdded."', '".$storySource."', '".$storyText."')"); 

Так я думал, что делать это будет заботиться о очищая все невидимые «мусорные» символы, которые могут приходить в с представленным вами текст.

Тем не менее, я только что вставил текст, который я скопировал с веб-страницы в свою форму HTML, нажал «отправить», который выполнил вышеупомянутый скрипт и вставил этот текст в мою БД, но когда я прочитал этот текст назад из БД я обнаружил, что в этом фрагменте текста все еще есть мусорные символы, такие как –.
И эти мусорные символы, конечно, вызвали PHP-скрипт, который я написал, что извлекает информацию из базы данных для сбоя.

Итак, что я делаю неправильно?

Использует real_escape_stringне путь сюда? Или я должен использовать его в сочетании с чем-то еще? ИЛИ, есть ли что-то, что я должен делать (например, больше экранов) при чтении данных чтения из базы данных mySQL?

(Я должен упомянуть, что я разработчик Objective-C, а не разработчик PHP/mySQL, но мне, к сожалению, была предоставлена ​​эта задача, чтобы сделать некоторые вещи БД - отсюда мой вопрос ...) спасибо!

Answer 1

Ваше предположение неверно. mysqli_real_escape_string Единственное намерение состоит в том, чтобы избежать определенных символов, чтобы полученная строка могла быть безопасно использована в MySQL string literal. Вот и все, ничего больше, не меньше.

Результат должен состоять в том, чтобы точно сохранившиеся данные сохранялись, включая «мусор». Если вы не хотите, чтобы этот «мусор» в вашей базе данных, вам необходимо обнаружить, проверить или фильтровать его перед переходом в MySQL.

В вашем случае «мусор», по-видимому, обусловлен различными кодировками символов: данные ввода, по-видимому, кодируются с помощью UTF-8, в то время как позднее он отображается с использованием Windows-1250. В этом случае символ – (U + 2013) будет закодирован с 0xE28093 в UTF-8, который будет представлять три символа â, € и “ в Windows-1250. Properly declaring the document’s encoding, вероятно, исправит это.

Answer 2

Санитария - сложный вопрос, потому что это никогда не означает одно и то же в зависимости от контекста. :)

real_escape_string Просто убедитесь, что ваши данные могут быть включены в запрос (внутри кавычек, конечно), не имея возможности изменить «смысл» запроса.

manual page объясняет, что действительно делает функция: она пропускает nul-символы, линейные каналы, возврат каретки, простые кавычки, двойные кавычки и «Control-Z» (возможно, символ SUBSTITUTE). Поэтому он просто вставляет обратную косую черту перед этими символами.

Все. Он «санизирует» строку, поэтому ее можно передать без изменений в запросе. Но это не дезинфицирует его ни в одной другой точке зрения: пользователи все равно могут передавать, например, HTML-маркеры или «странные» символы. Вам нужно создавать правила в зависимости от формата вывода (в большинстве случаев HTML, но HTTP не ограничивается документами HTML) и того, что вы хотите позволить своим пользователям.

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

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