mysql_real_escape_string vs mysql_escape_string

Согласно документации, стоит использовать только функцию mysql_real_escape_string.
Насколько я понимаю, это связано в основном с применением юникода и действительно оправдано.

Вопрос: насколько часто ошибается mysql_escape_string и можно ли в языках с нативной поддержкой юникода пользовать своей реализацией вроде:
/**
 * Escape string for mysql. Don't use native function,
 * because it doesn't work without connect.
 */
exports.escapeStr = function(str) {
    return str.replace(/[\\"']/g, "\\$&").replace(/[\n]/g, "\\n")
                .replace(/[\r]/g, "\\r").replace(/\x00/g, "\\0");
};


UPD: Вышеприведённый код не полный, в нём присутствуют не все символы, которые нужно экранировать. Давайте будем исходить из того, что replace для \b, \t, \Z, _, % также присутствуют:
exports.escapeStr = function(str) {
    return str.replace(/[\\"']/g, "\\$&").replace(/\n/g, "\\n")
                .replace(/\r/g, "\\r").replace(/\x00/g, "\\0")
                .replace(/\b/g, "\\b").replace(/\t/g, "\\t")
                .replace(/\x32/g, "\\Z") // \Z == ASCII 26
                .replace(/_/g, "\\_").replace(/%/g, "\\%");
};
  • Вопрос задан
  • 6062 просмотра
Пригласить эксперта
Ответы на вопрос 5
taliban
@taliban
php программист
Я думаю Вы, ошибаетесь чаще чем те кто делали функцию mysql_real_escape_string. Я не хочу сказать что вы хуже программируете, а лишь то что:
1 — эта функция использует не только юникод, а текущую кодировку подключения.
2 — те кто писал эту функцию, возможно, наступили на не одни грабли, о которых Вам не известно
3 — этих четырех замен, возможно, будет не хватать для полноценного спокойствия
4 — она банально быстрей работает
Ответ написан
@shagguboy
переходите наконец на bind параметры. кроме отсутствия вот таких проблем в плюс еще не будет повторного разбора запроса при каждом выполении.
Ответ написан
Здесь надо подходить со стороны — А используются ли запрещённые символы в проекте?

Лично у меня, для примера, в текущем проекте данные символы не используются, поэтому Я просто запретил их по белому списку, а от функции mysql_real_escape_string вообще отказался за ненадобностью.
Ответ написан
lashtal
@lashtal
На stackoverflow ищем да? =)
goo.gl/LgdZi

Краткий пересказ: нельзя, ибо для экранирования нужна информация о кодировке подключения к базе.
Внизу, правда, дана якобы безопасная функция.
Ответ написан
pentarh
@pentarh
Если latin1, то нафиг этот real_escape.

В быдло-коде на один скрипт обычно десяток-другой эскейпов. Ато и больше. И если использовать real_escape там, где он не нужен, то это будет 1 запрос к базе на 1 real_escape. На высоких нагрузках может встать на ручник.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы