爲什麼要使用ATTR_EMULATE_PREPARES，是mysql_real_escape_string的任何選擇？在PDO

Question

1. 是否有任何PDO的替代品，因爲在MySQL是mysql_real_escape_string？
2. 爲什麼我們應該設置'false' - > ATTR_EMULATE_PREPARES常量？

Answer 1

1. 你沒有在事先準備好的聲明中使用mysql_real_escape_string在PDO
2. 不一定。你可以用任何一種方式

要回答的問題編輯

NO，有沒有辦法。你應該使用準備好的語句。

Answer 2

使用mysql擴展，只有這樣，才能動態地嵌入值插入查詢是：

$query = "SELECT ... WHERE foo = '$bar'"; 

爲了避免在最壞的情況下，可以利用如SQL注入語法錯誤，你需要申請mysql_real_escape_string到$bar這裏以轉義的值正確。如果您不知道這意味着什麼，請閱讀The Great Escapism (Or: What You Need To Know To Work With Text Within Text)。

準備語句提供通過完全分離的查詢和所述值，以使用動態值完全不同的方式：

$stmt = $db->prepare('SELECT ... WHERE foo = :bar'); 
$stmt->execute(array(':bar' => $bar)); 

這實際上是發送到數據庫作爲兩個單獨的件;語法永遠不會被搞砸或被利用，因爲這兩個部分從來沒有實際合併過。

儘管所有數據庫都不支持此功能，但有些（舊的）數據庫仍然希望使用舊式的未準備好的轉義查詢。 ATTR_EMULATE_PREPARES給出了選項，好吧，模擬準備好的語句。您仍然可以在代碼中使用$db->prepare()->execute() API，但在幕後，PDO將轉義該值並將其連接到查詢中。要明確禁止PDO執行此操作並強制它使用數據庫提供的本地準備語句API，請將ATTR_EMULATE_PREPARES設置爲false。

如果您的數據庫本地支持預處理語句，則應該執行此操作;最近的所有數據庫都是這樣。如果讓PDO模擬預準備語句，則在某些條件下（主要是在人工構建的多字節連接編碼情況AFAIK下），SQL注入的可能性仍然很小。

在任何情況下，您都不能使用mysql擴展中的函數和PDO擴展;它不會起作用，因爲mysql_real_escape_string需要通過mysql_connect建立單獨的數據庫連接。