首先：不要使用mysql_escape_string，它已被棄用，請使用mysql_real_escape_string代替它。
mysql_real_escape_string和addslashes的區別在於：
區別一：
addslashes不知道任何有關MySQL連接的字符集。如果你給所使用的MySQL連接傳遞一個包含字節編碼之外的其他編碼的字符串，它會很愉快地把所有值為字符‘、“、\和\x00的字節進行轉義。如果你正在使用不同於8位和UTF-8的其它字符，這些字節的值不一定全部都是表示字符‘、“、\和\x00。可能造成的結果是，MySQL接收這些字符後出現錯誤。
如果要修正這個bug，可嘗試使用iconv函數，將變量轉為UTF-16，然後再使用addslashes進行轉義。
這是不使用addslashes進行轉義的原因之一。
區別二：
與addslashes對比，mysql_real_escape_string同時還對\r、\n和\x1a進行轉義。看來，這些字符必須正確地告訴MySQL，否則會得到錯誤的查詢結果。
這是不使用addslashes進行轉義的另一個原因。
addslashes V.S. mysql_real_escape_string
在GBK裡，0xbf27不是一個合法的多字符字符，但0xbf5c卻是。在單字節環境裡，0xbf27被視為0xbf後面跟著0×27(‘)，同時0xbf5c被視為0xbf後面跟著0x5c(\)。
一個用反斜槓轉義的單引號，是無法有效阻止針對MySQL的SQL注入攻擊的。如果你使用addslashes，那麼，我（攻擊者，下同）是很幸運的。我只要注入一些類似0xbf27，然後addslashes將它修改為0xbf5c27，一個合法的多字節字符後面接著一個單引號。換句話說，我可以無視你的轉義，成功地注入一個單引號。這是因為0xbf5c被當作單字節字符，而非雙字節。
在這個演示中，我將使用MySQL 5.0和PHP的mysqli擴展。如果你想嘗試，請確保你使用GBK。
創建一個名為users的表：
復制代碼 代碼如下:
CREATE TABLE users(
username VARCHAR(32) CHARACTER SET GBK,
password VARCHAR(32) CHARACTER SET GBK,
PRIMARY KEY(username)
);
下面的代碼模擬只使用addslashes（或magic_quotes_gpc）對查詢數據進行轉義時的情況：
復制代碼 代碼如下:
<?php
$mysql = array();
$db = mysqli_init();
$db->real_connect('localhost', 'lorui', 'lorui.com', 'lorui_db');
/* SQL注入示例 */
$_POST['username'] = chr(0xbf) . chr(0×27) . ‘ OR username = username /*'; $_POST['password'] = ‘guess'; $mysql['username'] = addslashes($_POST['username']); $mysql['password'] = addslashes($_POST['password']); $sql = “SELECT * FROM users WHERE username = ‘{$mysql['username']}' AND password = ‘{$mysql['password']}'”; $result = $db->query($sql); if ($result->num_rows) { /* 成功 */ } else { /* 失敗 */ }
盡管使用了addslashes，我還是可以在不知道用戶名和密碼的情況下成功登錄。我可以輕松的利用這個漏洞進行SQL注入。
要以免這種漏洞，使用mysql_real_escape_string、准備語句（Prepared Statements，即“參數化查詢”）或者任意一款主流的數據庫抽象類庫。
