Добро пожаловать на Pro Pawn - Портал о PAWN-скриптинге.
Страница 3 из 3 ПерваяПервая 1 2 3
Показано с 21 по 22 из 22
  1. #21
    Аватар для Daniel_Cortez
    "Это не хак, это фича"

    Статус
    Оффлайн
    Регистрация
    06.04.2013
    Адрес
    Novokuznetsk, Russia
    Сообщений
    2,192
    Репутация:
    2589 ±
    Цитата Сообщение от DeimoS Посмотреть сообщение
    mysql_format - нет.
    mysql_format + "%e" - да (хотя format + "%q" будет шустрее и результат, при этом, будет тем же)
    Ну всё-таки подход с format() больше применим при использовании SQLite, а не MySQL. Если пользоваться инструментами которые как бы выполняют как бы ту же работу как бы похожим образом, такой подход рано или поздно становится источником багов. На сайтах с новостями по IT-шной тематике то и дело пишут, как в таком-то проекте исправлена такой-то баг или уязвимость, возникшая из-за использования ненадлежащей функции из не имеющего отношения к решаемой задаче фреймворка.

    Да и в реализации функции у тебя тоже небольшой изъян: если случайно выпадает один из "опасных" символов, вместо него выбирается один из следующих ('\"', '(', ']'), из-за чего вероятность возникновения этих трёх символов в строке становится в 2 раза больше, т.е. символы распределяются неравномерно.
    Равномерную выборку можно сделать примерно так:
    1. GenerateSalt(buf[], len = sizeof(buf))
    2. {
    3. --len;
    4. for (new i = 0, c; i < len; i++)
    5. {
    6. c = 33 + random(94 - 3);
    7. c += _:(c >= '%') + _:(c >= '\'') + _:(c >= '\\');
    8. }
    9. buf[len] = '\0';
    10. return len;
    11. }
    Индивидуально в ЛС по скриптингу не помогаю. Задавайте все свои вопросы здесь (click).

  2. #22
    Аватар для DeimoS
    Модератор?

    Статус
    Оффлайн
    Регистрация
    27.01.2014
    Адрес
    Восточный Мордор
    Сообщений
    5,588
    Репутация:
    1984 ±
    Цитата Сообщение от Daniel_Cortez Посмотреть сообщение
    Ну всё-таки подход с format() больше применим при использовании SQLite, а не MySQL. Если пользоваться инструментами которые как бы выполняют как бы ту же работу как бы похожим образом, такой подход рано или поздно становится источником багов. На сайтах с новостями по IT-шной тематике то и дело пишут, как в таком-то проекте исправлена такой-то баг или уязвимость, возникшая из-за использования ненадлежащей функции из не имеющего отношения к решаемой задаче фреймворка.
    Я понимаю о чём ты говоришь, но в данном случае обе функции выполняют практически идентичную работу (если не считать того изъяна со слешем, о котором писал выше), но format, при этом, будет работать шустрее. Это как вместо кастомной функции PlayerToPoint пользоваться IsPlayerInRangeOfPoint, ибо суть одна, но нативка работает быстрее.
    Хотя я не призываю переходить на format. Как я выше сказал, у format есть своя не очень приятная особенность, которую нужно учитывать при написании кода. Просто изменить mysql_format на format не получится.

    Ну и как ранее писал, я предпочитаю просто запрещать использование апострофа/слеша там, где это возможно. Это позволяет не заморачиваться с контролем данных в дальнейшем. Но и тут, опять же, всё нужно делать с умом.


    Цитата Сообщение от Daniel_Cortez Посмотреть сообщение
    Да и в реализации функции у тебя тоже небольшой изъян: если случайно выпадает один из "опасных" символов, вместо него выбирается один из следующих ('\"', '(', ']'), из-за чего вероятность возникновения этих трёх символов в строке становится в 2 раза больше, т.е. символы распределяются неравномерно.
    Равномерную выборку можно сделать примерно так:
    1. GenerateSalt(buf[], len = sizeof(buf))
    2. {
    3. --len;
    4. for (new i = 0, c; i < len; i++)
    5. {
    6. c = 33 + random(94 - 3);
    7. c += _:(c >= '%') + _:(c >= '\'') + _:(c >= '\\');
    8. }
    9. buf[len] = '\0';
    10. return len;
    11. }
    Только проблем от повышения вероятности выпадения символов никаких не будет :) Шанс генерации двух одинаковых строк повысится несущественно (конечно, зависит от количества символов) и соль, в любом случае, будет выполнять свою функцию.
    Хотя хуже не станет от такой реализации, соглашусь.
    Связаться со мной в VK можно через личные сообщения этой группы
    Заказы не принимаю

    Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину).
    Великих идей полно, на них нет спроса.
    Воплощение идеи в законченную игру требует долгой работы,
    таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов.
    Предложить идею просто, воплотить – вот в чём проблема

    Steve Pavlina

 

 
Страница 3 из 3 ПерваяПервая 1 2 3

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •