(PHP 4 >= 4.3.0, PHP 5)

mysql_real_escape_stringmysql_query에서 특수 문자열을 이스케이프하기위해 사용


string mysql_real_escape_string ( string $unescaped_string [, resource $link_identifier ] )

unescaped_string된 문자열에서 접속의 현재 문자 집합으로 특수 문자열을 이스케이프하여 mysql_query() 수행시 안전하게 질의할 수 있도록 한다. 이진 데이터를 입력할 경우 이 함수를 사용해야 한다.

mysql_real_escape_string()는 MySQL 라이브러리 함수인 mysql_real_escape_string를 호출하여, 다음의 문자에 백슬래시를 붙인다: \x00, \n, \r, \, ', ", \x1a.

이 함수는 MySQL로 질의를 전송하기 전에 안전하게 데이터를 만들기 위해 항상 사용해야한다.



이스케이프할 문자열.


MySQL 연결. 지정하지 않으면 mysql_connect()로 연 마지막 연결을 사용합니다. 연결이 없으면, 인수 없이 mysql_connect()를 호출하여 연결을 만듭니다. 연결이 성립되지 않으면 E_WARNING 등급의 오류를 생성합니다.


이스케이프된 문자열을 반환하고 에러가 발생하면 FALSE를 반환한다.


Example #1 mysql_real_escape_string() 예제

// Connect
$link mysql_connect('mysql_host''mysql_user''mysql_password')
    OR die(

// Query
$query sprintf("SELECT * FROM users WHERE user='%s' AND password='%s'",

Example #2 SQL 인젝션 공격(Injection Attack)의 예

// Query database to check if there are any matching users
$query "SELECT * FROM users WHERE user='{$_POST['username']}' AND password='{$_POST['password']}'";

// We didn't check $_POST['password'], it could be anything the user wanted! For example:
$_POST['username'] = 'aidan';
$_POST['password'] = "' OR ''='";

// This means the query sent to MySQL would be:
echo $query;

MySQL로 전송되는 질의:

SELECT * FROM users WHERE user='aidan' AND password='' OR ''=''

유효한 비밀번호 없이 누구나 접속하여 접근이 가능하다.

Example #3 "Best Practice" 질의

mysql_real_escape_string()은 각 변수에 대해 SQL 인젝션을 방지한다. 이 예제는 Magic Quotes 설정과는 별개로 데이터베이스를 질의하는 "best practice" 방법을 시연한다.

if (isset($_POST['product_name']) && isset($_POST['product_description']) && isset($_POST['user_id'])) {
// 접속
$link mysql_connect('mysql_host''mysql_user''mysql_password');

is_resource($link)) {

"서버 접속 실패\n";
// ... 오류를 적절히 기록

} else {

// ON일 경우 magic_quotes_gpc/magic_quotes_sybase 효과 제거

if(get_magic_quotes_gpc()) {
$product_name        stripslashes($_POST['product_name']);
$product_description stripslashes($_POST['product_description']);
        } else {
$product_name        $_POST['product_name'];
$product_description $_POST['product_description'];

// 안전한 질의 만들기
$query sprintf("INSERT INTO products (`name`, `description`, `user_id`) VALUES ('%s', '%s', %d)",


        if (
mysql_affected_rows($link) > 0) {
"Product inserted\n";
} else {
"Fill the form property\n";

SQL 인젝션 공격이 동작하지 않으며 질의가 정확하게 실행될 것이다.



mysql_real_escape_string()을 사용하기 전에 MySQL 접속이 필요하다. 그렇지 않으면 E_WARNING 등급의 에러가 발생되며, FALSE가 반환될 것이다. 만약 link_identifier가 정의되지 않으면, 최근 MySQL 접속이 사용된다.


magic_quotes_gpc이 활성화되면, stripslashes()가 모든 데이터에 먼저 적용된다. 이 함수를 데이터에 사용하면 이스케이프된 데이터에 중복 처리될 것이다.


이 함수가 데이터 이스케이프를 위해 사용되지 않으면, 질의는 SQL Injection Attacks으로 취약점이 생기게 된다.

Note: mysql_real_escape_string()%_를 이스케이프하지는 않는다. LIKE, GRANT, REVOKE와 결합되어 사용되는 와일드카드이기 때문이다.


add a note add a note

User Contributed Notes 7 notes

6 years ago
Just a little function which mimics the original mysql_real_escape_string but which doesn't need an active mysql connection. Could be implemented as a static function in a database class. Hope it helps someone.

function mysql_escape_mimic($inp) {
array_map(__METHOD__, $inp);

$inp) && is_string($inp)) {
str_replace(array('\\', "\0", "\n", "\r", "'", '"', "\x1a"), array('\\\\', '\\0', '\\n', '\\r', "\\'", '\\"', '\\Z'), $inp);

Walter Tross
4 years ago
For further information:
(replace your MySQL version in the URL)
10 years ago
Note that mysql_real_escape_string doesn't prepend backslashes to \x00, \n, \r, and and \x1a as mentionned in the documentation, but actually replaces the character with a MySQL acceptable representation for queries (e.g. \n is replaced with the '\n' litteral). (\, ', and " are escaped as documented) This doesn't change how you should use this function, but I think it's good to know.
sam at numbsafari dot com
4 years ago
No discussion of escaping is complete without telling everyone that you should basically never use external input to generate interpreted code. This goes for SQL statements, or anything you would call any sort of "eval" function on.

So, instead of using this terribly broken function, use parametric prepared statements instead.

Honestly, using user provided data to compose SQL statements should be considered professional negligence and you should be held accountable by your employer or client for not using parametric prepared statements.

What does that mean?

It means instead of building a SQL statement like this:


You should use mysqli's prepare() function ( to execute a statement that looks like this:


NB: This doesn't mean you should never generate dynamic SQL statements. What it means is that you should never use user-provided data to generate those statements. Any user-provided data should be passed through as parameters to the statement after it has been prepared.

So, for example, if you are building up a little framework and want to do an insert to a table based on the request URI, it's in your best interest to not take the $_SERVER['REQUEST_URI'] value (or any part of it) and directly concatenate that with your query. Instead,  you should parse out the portion of the $_SERVER['REQUEST_URI'] value that you want, and map that through some kind of function or associative array to a non-user provided value. If the mapping produces no value, you know that something is wrong with the user provided data.

Failing to follow this has been the cause of a number of SQL-injection problems in the Ruby On Rails framework, even though it uses parametric prepared statements. This is how GitHub was hacked at one point. So, no language is immune to this problem. That's why this is a general best practice and not something specific to PHP and why you should REALLY adopt it.

Also, you should still do some kind of validation of the data provided by users, even when using parametric prepared statements. This is because that user-provided data will often become part of some generated HTML, and you want to ensure that the user provided data isn't going to cause security problems in the browser.
strata_ranger at hotmail dot com
7 years ago
There's an interesting quirk in the example #2 about SQL injection:  AND takes priority over OR, so the injected query actually executes as WHERE (user='aidan' AND password='') OR ''='', so instead of returning a database record corresponding to an arbitrary username (in this case 'aidan'), it would actually return ALL database records.  In no particular order.  So an attacker might be able to log in as any account, but not necessarily with any control over which account it is.

Of course a potential attacker could simply modify their parameters to target specific users of interest:


// E.g. attacker's values
$_POST['username'] = '';
$_POST['password'] = "' OR user = 'administrator' AND '' = '";

// Malformed query
$query = "SELECT * FROM users WHERE user='$_POST[username]' AND password='$_POST[password]'";


// The query sent to MySQL would read:
// SELECT * FROM users WHERE user='' AND password='' OR user='administrator' AND ''='';
// which would allow anyone to gain access to the account named 'administrator'

plgs at ozemail dot com dot au
7 years ago
Don't forget that if you're using Mysqli (ie, the "improved" Mysql extension) then you need to use the corresponding mysqli function mysqli_real_escape_string().  The parameter order is also different.
presto dot dk at gmail dot com
7 years ago
If you want to make sure that the ID you're using to do a query is a number, use sprint() of (int) or intval(), but don't use mysql_real_escape_string.

There is no difference between ISO-8859-1's number 10 and UTF-8's number 10.
To Top