我什麼時候不應該使用mysql_real_escape_string

我看到此評論.... http://www.php.net/manual/en/function.mysql-real-escape-string.php#93005 我什麼時候不應該使用mysql_real_escape_string

並開始疑惑爲什麼這會是一個壞主意。

來源

2010-06-30 Webnet

每當你可以使用[準備好的語句（http://php.net/manual/en/mysqli.prepare.php）來代替。 – Mike 2010-06-30 20:46:51

這是一對夫婦的原因是一個壞主意：

第一，它假定您的輸入將始終進入數據庫並單獨存入數據庫。如果將在HTML輸出中使用怎麼辦？或者在電子郵件中？或寫入文件？或許多其他事情..你的過濾應始終是上下文敏感的。
更重要的是，它鼓勵馬虎使用GET，POST等，因爲沒有跡象表明他們已經過濾了。如果有人看到你使用

echo $ _POST ['name'];

在頁面上，他們怎麼會知道這是被過濾？或者更糟糕的是......你確定它是？那其他應用程序呢？你知道，你剛剛上手的那一個是？新開發人員會做什麼？他們是否會知道過濾很重要？

來源

2010-06-30 20:52:34 CaseySoftware

+1。我的規則是，只有在*進入該介質之前，立即對特定介質進行消毒。所以，你只是在查詢中使用它們之前立即轉義你的字符串，*而不是在HTTP-> PHP轉換中，就像有問題的php.net註釋所暗示的那樣。 – 2010-06-30 21:16:27

對任何不會放入SQL查詢的數據。如果您需要轉義輸出，請使用htmlspecialchars（）（或類似的）。數據庫輸入也是如此;只是在它進入之前逃脫它。

來源

2010-06-30 20:46:49 Adrian

從專門針對該代碼示例的網站上的特定評論來看，我認爲他說如果magic_quotes已關閉，並且您確定只會在服務器上使用您的代碼與它關閉，你可以編輯代碼並刪除if(get_magic_quotes_gpc())... etc

一般來說，雖然它沒有用的數據，你包含在你不使用引號的查詢 - 即整數爲ids，這些需要檢查的類型。

來源

2010-06-30 20:48:12

理想情況下，在通過使用PDO準備語句的查詢中使用它之前，您絕對不應該轉義任何內容。底層的庫會照顧你逃跑。

實際上，如果您不能/不會使用預處理語句，則應該在構建查詢字符串之前立即進行轉義。不要盲目地去重新設定各種超級全球資源（GET，POST，REQUEST，COOKIES）的內容，假定所有事情都會進入數據庫。想想你必須首先驗證表單數據，並且某些字段未被正確填寫的情況。現在，您必須從「數據庫模式」中取消所有內容，然後重新轉換爲「html模式」，以便將良好數據重新插入到表單中。

htmlentities/htmlspecialchars也是如此。直到你知道你輸出爲HTML/XML爲止。一旦你去申請轉義/編碼/報價無處不在，你會遇到的雙重編碼東西的風險和無用的結構落得像&quot;

來源

2010-06-30 20:52:03

當你想逃避字符串被包含在即將到MySQL數據庫的SQL查詢，你應該使用mysql_real_escape_string - 該範圍之外的事情將是「當不使用」的明確指示它:)

這裏有一個詳細的實施：

function clean($p) 
{ 
    if(function_exists('mysql_real_escape_string')) { 
    if(function_exists('get_magic_quotes_gpc')) { 
     if(get_magic_quotes_gpc()) { 
     $p = stripslashes($p); 
     } 
    } 
    return mysql_real_escape_string($p); 
    } else { 
    return $p; 
    } 
}

來源

2010-06-30 22:14:57 nathan

我什麼時候不應該使用mysql_real_escape_string

回答

相關問題