mysql_real_escape_string vs mysql_escape_string

Question

[Sannis]

Согласно документации, стоит использовать только функцию 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, "\\%");
};

Comments

[Sannis]

Речь идёт о MySQL C API и Node.js/V8/JavaScript.

Answer 1

[Анатолий]

Я думаю Вы, ошибаетесь чаще чем те кто делали функцию mysql_real_escape_string. Я не хочу сказать что вы хуже программируете, а лишь то что:
1 — эта функция использует не только юникод, а текущую кодировку подключения.
2 — те кто писал эту функцию, возможно, наступили на не одни грабли, о которых Вам не известно
3 — этих четырех замен, возможно, будет не хватать для полноценного спокойствия
4 — она банально быстрей работает

Comments

[Sannis]

1. Да, я понимаю. собственно вопрос стоио бы разбить на две части: mysql_real_escape_string vs mysql_escape_string и mysql_real_escape_string vs someone_own_escape. В первым случае, как вы думаете, разница будет только в обработке многобайтовых строк?

2. Скорее всего. Собственно, я предпочитаю использовать mysql_real_escape_string, но почему-то каждый, кто использует мою библиотеку, старается вместо вызова соответствующей функции использовать вышеприведённый код, ссылаясь на необходимость действующего подключения для mysql_real_escape_string. По идее, т.к. в javascript строки в юникода, то всё должно быть ОК.

3. Вы правы, уже вижу отсутствие обработки _, %, \t, \b и \Z. Но это дело наживное, можно дополнить для полного соответствия спецификации.

[Анатолий]

Я один раз слышал фразу от одного программиста: я не то что пхп, я себе не доверяю. Мне кажется замена нативных функций пхп не целесообразна, это не библиотека в которой, при маленьком изменении, нужно будет разбираться долго, это просто экранизация строк, те кто игнорируют это, всего лишь считают себя умней тех кто писал драйвер для mysql под пхп

[Sannis]

Буду убеждать остальных, спасибо :)

[Анатолий]

Насчет не использовать нативную потому что она использует подключение… Если Вам нужно экранировать строки не для mysql, тогда возможно стоит присмотреться к addslashes, она делает примерно то же но не использует подключение.

[Sannis]

Используется это в JavaScript, так что всё равно свою реализацию с .replace() придётся писать.

[Анатолий]

Эм, а чего вы тогда про пхп-шные функции писали?:) Ну у Вас в любом случае 2 варианта:
1 вы работаете с серверным жс, тогда у него наверняка есть свои свойства и методы
2 вы шлете с помошью жс данные на сервер, тогда почему бы просто не делать encodeURIComponent?

[Sannis]

Я про них не писал ;) Наверное стоит уточнить вопрос, спасибо за замечания.

Да, речь идёт о серверном Js, а проблема только том, что функции по работе с MySQL я же и пишу. Ну и многие предпочитаю почему-то реализацию из вопроса, потмоу я и хочу узнать, не справится ли javaScript сам с этим экранированием, без прямого вызова C-шной функции.

Answer 2

[shagguboy]

переходите наконец на bind параметры. кроме отсутствия вот таких проблем в плюс еще не будет повторного разбора запроса при каждом выполении.

Comments

[Sannis]

Предлагаете в библиотеках вообще не делать метода query(string sql)? Боюсь пользователи не поймут пока что :)

[shagguboy]

да. жутко вредный метод, на сегодняшний день приносящий больше проблем, чем пользы. потому что первое что видят, и используют, это его. а потом встают вопросы, mysql_real_escape_string vs mysql_escape_string, хотя не надо использовать ни то и ни другое.

[Sannis]

Сурово :)

[Вячеслав Плиско]

писец, нужно найти того, кто влепил вам минус и удалять такие аккаунты с хабры.
вот описание процесса dev.mysql.com/tech-resources/articles/4.1/prepared-statements.html

Answer 3

[Виталий Желтяков]

Здесь надо подходить со стороны — А используются ли запрещённые символы в проекте?

Лично у меня, для примера, в текущем проекте данные символы не используются, поэтому Я просто запретил их по белому списку, а от функции mysql_real_escape_string вообще отказался за ненадобностью.

Comments

[Sannis]

Я имею дело с разработкой библиотеки, так что не могу предугадать в каких условиях она будет использоваться :/

[gro]

Что значит запрещённые символы? Вот ТС использовал в своём тексте двойную кавычку. Следовало бы её запрещать?

Answer 4

[lashtal]

На stackoverflow ищем да? =)
goo.gl/LgdZi

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

Comments

[Sannis]

Вопрос внимательно читаем, да? %)
Если обратить внимание на мелочи, то становится ясно, что речь не про PHP, а про JavaScript.

Так что проблема многобайтовости должна отпасть сама собой, так как UTF8 поддерживается «из коробки» и без проблем.

Answer 5

[pentarh]

Если latin1, то нафиг этот real_escape.

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

Comments

[homm]

> 1 запрос к базе на 1 real_escape
Это у вас откуда такие сведения? Как я понимаю, для работы функции нужно соединение с базой данных, чтобы узнать кодировку этого соединения, а эти сведения должны быть известны клиенту и запрос на их выяснение не требуется.

[pentarh]

мда? не знал. я то думаю, нафига ему коннект… надо еще сырцы поглядеть…

[Sannis]

Да, там нужно только соединение. И то, к слову говоря, отличие от mysql_escape_string будет только тогда, когда вы измените кодировку соединения по сравнению с прописанной для клиента в my.cnf.