mysql_escape_string или mysql_real_escape_string

vovanium

Новичок
mysql_escape_string или mysql_real_escape_string

Как оказалось в моей задаче mysql_real_escape_string на 20% медленнее своего более простого аналога, это не важно когда вызовов немного, но когда счет идет на миллионы, то ускорение процесса на 20% не помешают.
Так вот вопрос, кто-нибудь знает в каких случаях может быть недостаточно mysql_escape_string, в каких кодировках могут быть проблемы?
 

Mr_Max

Первый класс. Зимние каникулы ^_^
Команда форума
Ребята, эта,
Через ЛС плз.
 

vovanium

Новичок
tashkentchi
Ты не поверишь, но с помощью php можно не только страницы выводить, но и парсить различные данные и т.п.
Да в данном случае у меня файл с 4 млн. записей, дальше будет больше.

-~{}~ 14.03.09 22:31:

Mr_Max
Что через ЛС? Я задал вполне конкретный вопрос насчет различий mysql_escape_string или mysql_real_escape_string.
За пост tashkentchi, ему вообще-бы можно было выписать предупреждение, так как его пост нарушает правила форума.
 

vovanium

Новичок
Ну, не столько документация, сколько багтрекер и исходники.
Проблема с китайской GBK возникает...
И что интересно, SET NAMES оказывается на mysql_real_escape_string не влияет.
 

nerezus

Вселенский отказник
vovanium на осенблере быстрее будет.

vovanium Какой процент всего времени будет уходить именно на эскейпинг в обоих случаях? Посчитай и сравни эти нули.
 

vovanium

Новичок
nerezus
Может еще предложишь свою ОС написать ради такого случая? Нравятся мне такие советчики, я же написал что разница по времени в 20%. Т.е. замена mysql_escape_string на mysql_real_escape_string увеличивает время работы на 20%, при том что mysql_real_escape_string в данном случае не нужен, абсолютно.

Твой пост напомнил один "гениальный" код
PHP:
$id=mysql_escape_string(htmlspecialchars(trim(intval($_GET['id']))));
т.е. случай когда чел не представляет зачем нужны эти функции, но где то вычитал, что эти функции позволят уберечься от SQL-инъекций, вот и тулит его везде, и ведь в принципе то код рабочий.
Вот также и с mysql_real_escape_string, нужно знать что оно такое, и с чем его едят.
 

ustas

Элекомист №1
От китайских спасет точно mysql_escape_string, но для вывода нормализацию делать нужно. Как вариант резать все 包含脚本文件 (многобайтовые) до записи. А дольше потому что google знает только. За пять лет мог бы и почитать.
Ты заметил как фанат к тебе ласково относится? ;)
А предупреждение тебе, за то что не воспользовался поиском.
 

vovanium

Новичок
ustas
От китайских спасет точно mysql_escape_string, но для вывода нормализацию делать нужно
Как раз от китайских не спасает :) Для китайских нужен real.

А дольше потому что google знает только.
я и без гугла знаю почему дольше, так простая замена 7 символов, будет быстрее чем доставание инфы о текущей кодировке, и экранирование символов с учетом кодировки.

За пять лет мог бы и почитать
Что почитать? Вот прям всегда перед сном, читаю исходники и багтрек. В доках же не написано, в каких конкретно случаях могут быть проблемы.
 

nerezus

Вселенский отказник
> Твой пост напомнил один "гениальный" код
А твой пост напомнил пост человека, который не умеет читать. Я вот выделил даже сейчас:
Какой процент всего времени будет уходить именно на эскейпинг в обоих случаях? Посчитай и сравни эти нули.
5k импортов у меня забиваются за 11с как с mysql_escape_string, так и с mysql_real_escape_string.
Даже если _real был бы в 10 раз медленнее, то все равно разница была бы такой же: основная нагрузка идет на mysql_query, а не на экранирование.

Кстати да, почему он дольше - там тоже написано. В мануале. Сразу.
 
Сверху