Bueno, de acuerdo con la página de referencia de la función mysql_real_escape_string: "mysql_real_escape_string () llama a la función de biblioteca mysql_real_escape_string de MySQL, que escapa de los siguientes caracteres: \x00, \n, \ r,\,',"y \x1a."

Con eso en mente, entonces la función dada en el segundo enlace que publicaste debería hacer exactamente lo que necesitas:

function mres($value)
{
    $search = array("\\",  "\x00", "\n",  "\r",  "'",  '"', "\x1a");
    $replace = array("\\\\","\\0","\\n", "\\r", "\'", '\"', "\\Z");

    return str_replace($search, $replace, $value);
}

En oposición directa a mi otra respuesta, esta función siguiente es probablemente segura, incluso con caracteres de varios bytes.

// replace any non-ascii character with its hex code.
function escape($value) {
    $return = '';
    for($i = 0; $i < strlen($value); ++$i) {
        $char = $value[$i];
        $ord = ord($char);
        if($char !== "'" && $char !== "\"" && $char !== '\\' && $ord >= 32 && $ord <= 126)
            $return .= $char;
        else
            $return .= '\\x' . dechex($ord);
    }
    return $return;
}

Espero que alguien más conocedor que yo pueda decirme por qué el código anterior no funcionará ...

A partir de nuevas investigaciones, he encontrado:

Http://dev.mysql.com/doc/refman/5.1/en/news-5-1-11.html

Solución de seguridad:

Se ha encontrado un agujero de seguridad de inyección SQL en el procesamiento de codificación multibyte. El error estaba en el servidor, analizando incorrectamente la cadena escapada con la función API mysql_real_escape_string () C.

Esta vulnerabilidad fue descubierta y reportada por Josh Berkus y Tom Lane como parte de la colaboración de seguridad entre proyectos de el consorcio OSDB. Para obtener más información sobre la inyección SQL, consulte el siguiente texto.

Discusión. Se ha encontrado un agujero de seguridad de inyección SQL en el procesamiento de codificación multibyte. Un agujero de seguridad de inyección SQL puede incluir una situación en la que cuando un usuario suministra datos para ser insertados en una base de datos, el usuario puede inyectar sentencias SQL en los datos que el servidor ejecutará. Con respecto a esta vulnerabilidad, cuando se utiliza el escape de conjunto de caracteres-inconsciente (por ejemplo, addslashes() en PHP), es posible omitir el escape en algunos conjuntos de caracteres de varios bytes (por ejemplo, SJIS, BIG5 y GBK). Como resultado, una función como addslashes () no es capaz de prevenir ataques de inyección SQL. Es imposible arreglar esto en el lado del servidor. La mejor solución es que las aplicaciones usen el escape de conjunto de caracteres ofrecido por una función como mysql_real_escape_string ().

Sin embargo, se detectó un error en cómo el servidor MySQL analiza la salida de mysql_real_escape_string (). Como resultado, incluso cuando se usó la función de conjunto de caracteres mysql_real_escape_string (), la inyección SQL era posible. Este error ha sido corregido.

Soluciones alternativas. Si no puede actualizar MySQL a una versión que incluya la corrección del error en el análisis mysql_real_escape_string (), pero ejecute MySQL 5.0.1 o superior, puede usar el modo SQL NO_BACKSLASH_ESCAPES como solución alternativa. (Este modo fue introducido en MySQL 5.0.1.) NO_BACKSLASH_ESCAPES habilita un SQL modo de compatibilidad estándar, donde la barra invertida no se considera un carácter especial. El resultado será que las consultas fallarán.

Para establecer este modo para la conexión actual, ingrese la siguiente instrucción SQL:

SET sql_mode='NO_BACKSLASH_ESCAPES';

También puede establecer el modo globalmente para todos los clientes:

SET GLOBAL sql_mode='NO_BACKSLASH_ESCAPES';

Este modo SQL también se puede habilitar automáticamente cuando el servidor se inicia utilizando la opción de línea de comandos sql sql-mode = NO_BACKSLASH_ESCAPES o estableciendo sql-mode=NO_BACKSLASH_ESCAPES en el archivo de opciones del servidor (por ejemplo, my.cnf o my.ini, dependiendo de su sistema). (Bug#8378, CVE-2006-2753)

Véase también el Bug#8303.