Я, конечно, не хочу лишний раз напоминать - но не так давно и сам был на месте того, кого Вы подозревали в некомпетентности. Разумеется, я постарался проанализировать, что в моих сообщениях пошло не так - однако сейчас Вы пишете, что я всё же конструктивно отвечаю по поставленному вопросу. Я никого не обвиняю и по-человечески понимаю, что у всех могут быть трудные периоды, но нам, как команде PHP.SU - придётся отложить личные вещи в сторону во время пребывания на конференции. Надеюсь на понимание. Дальнейшее мы можем продолжить в ЛС, так как такая беседа всё менее соответствует тематике
Насчёт экранирования и использования кавычек - в ORM так нередко поступают. Не скажу, что при этом будет наблюдаться разница. Нет - оверхед на приведение типов, как правило, пренебрежимо мал. С другой стороны, лично я бы использовал проверку и приведение типов до вставки значения в подготовленный запрос (prepared statement) - так как это, во-первых, отвечает самой логике (читающий код поймёт, что ожидается, например, целое число, а не строка), а во-вторых, так можно быть уверенным, что проверка не пропустила, например, "", которое будет приведено к 0 - и, значит, бизнес-логика не будет нарушена. Но не всегда возможно использовать явную валидацию и приведение - нередко запрос сложен, генерируется динамически - и тогда использование кавычек и экранирования можно использовать, как универсальный вариант (опять же, так и поступают во многих ORM)
Stokmam
Нет смысла так смешивать различные функции. Вообще, htmlspecialchars() обычно стоит использовать при отображении данных. Сами пользовательские данные вряд ли стоит модифицировать иным оразом, кроме как экранирование при записи в БД (при этом само экранирование не портит данные, оно просто позволяет им верно храниться в БД). Кратко: каждая проверка хороша там, где действительно нужна, каждая валидация должна проверять/отсекать только то, что предусмотрено логикой.
armancho7777777
Насчёт кавычек - я не очень понял, в чём состоит "противостояние", однако на практике, как правило, нет разницы - ставить их или нет. Если говорить о правильных числах, заключённых в кавычки - то разница будет состоять лишь в неявном приведении типов. Таким образом, при заключении числовых параметров в кавычки ничего плохого не произойдёт, но запрос всё-таки будет работать медленнее, поскольку приведение типов всё-таки потребляет ресурсы системы.
В старых версиях MySQL (наподобие 4) возможна так же ситуация, когда заключение числовых значений в кавычки приведёт к тому, что СУБД не будет использовать индекс, однако точных случаев я описать не могу, да и, кроме того, в MySQL 5.0+ такое не произойдёт никогда (то есть индекс всегда будет использоваться, если это возможно - независимо от того, заключено ли значение в кавычки или нет).
То есть, как резюме - не заключать числовые значения в кавычки можно считать "хорошим тоном", но нет ничего страшного в том, чтобы эти самые кавычки использовать. Если вопрос не стоит об "оптимизации миллиметров", то в скорости разницы тоже нет. Многие ORM используют заключение полей в кавычки как универсальный способ передачи параметров - и при этом всё работает верно.
[upd.] armancho7777777, призываю Вас к более сдержанному стилю ведения беседы на конференции. Это не первый случай, когда Вы прибегаете к обвинению собеседника в некомпетентности - прошу подумать, стоит ли так делать.
Именно в данном случае
http://stackoverflow[dot]com/a/12118602/272927
Неверно. Приведённое исследование верно только в случае, если:
- Версия MySQL - ниже 5.1
- И не используется mysql_set_charset() / $mysqli->set_charset()
- И не используется DSN для PDO
- И используется кодировка GBK/BIG-5
Таким образом - да, существует возможность выйти за границы mysql_real_escape_string() - но, если обратить внимание на список "требований" для этого выше - это представляется очень маловероятным (если хотя бы один пункт не выполнен, атака не удастся).
По теме - вероятно, данную дискуссию об SQL-уязвимости стоит выделить в отдельное обсуждение.
Предположим, что есть массив строк, который нужно перемешать в случайном порядке. Требуется реализовать такое перемешивание, чтобы оно удовлетворяло требованиям псевдослучайности, то есть реализацией должна быть некоторая функция, например, "getShuffle", которая будет принимать два параметра - массив и некоторое значение (целое число). Внутри одного значения этого числа порядок внутри массива должен быть одинаковым при последовательном перемешивании, неважно сколько раз применялась функция.
Пример:
Всё верно, вчера, 23-го октября, около 02 PM google добавил все домены php.net (lxr, wiki, bugs и т.п.) и чуть позже - сам php.net в список вредоносных ресурсов.
Точных причин я не смог узнать. В настоящее время создан тикет. Дальшейшее развитие событий, полагаю, определится в ближайшее время.
Интересно, как предлагается регулировать шифрованный трафик. Т.е. провайдер будет иметь право писать только шифрованный трафик и его отдавать, или MITM принудительно внедрят?
Наиболее вероятно. Сертификаты *.* - и большинство неграмотных пользователей попросту нажмут в браузере "игнорировать и продолжить" в окне предупреждения о несоответствии сертификата. Остальные - просто будут вынуждены искать обходные пути. Но не думаю, что надолго. Логичный шаг - введение лицензирования на шифрование. Например, выдавать ключи только "проверенным" - тем, кто пришёл и согласовал в соответствующих органах это (разумеется, у таких органов останутся закрытые ключи) - и только для юр. лиц. Введение белых списков, опять же - и т.п. Вариантов ужесточения можно придумать много. Невозможно выиграть у кого-либо в игру, в которой этот кто-либо устанавливает правила.
armancho7777777
Не уверен, как прокомментировать последнее сообщение. Поскольку обычно я придерживаюсь конструктивизма, то неплохо было бы узнать, в чём состоят (и в каком объеме) вышеупомянутые единицы массы моих ненужных комментариев. На всякий случая, я, конечно, вспомнил мои последние "объемные" комментарии - наподобие этого, этого или этого. Больше в обозримом прошлом мною не было ничего создано. Поскольку скрывать мне особенно нечего, то всегда можно обратиться к данному списку. Дабы не возникало эффекта "оправдания" - всё это приведено лишь по той причине - что Вы - достаточно давно на конференции и степень доверия к Вам много выше, чем к иным её посетителям.
По данной теме - я решил уточнить исходную проблему, отметив при этом, как раз-таки верную на мой взгляд мысль пользователя SAD о том, что, скорее всего, исходный вопрос возник из-за неверного её понимания (и я всего лишь несколько поправил высказывание данного пользователя). Можно считать это ответом на вопрос "как бы сделал я" - то есть "я бы сначала выяснил".
Хотелось бы избежать обсуждения конкретных пользователей в данной теме, поскольку это будет вне топика. Все предложения/жалобы/нарекания я охотно выслушаю через сервис личных сообщений.
Что такое "Название"? Как можно объединить в CSV-файл строки с предположительно разным числом ключей/значений? Пример, более наглядный, чем имеющийся, сильно повысит шанс на корректный ответ.
Используется СУБД MySQL. Дана таблица test. У неё есть два поля id и title - требуется добавить новую колонку, например, new - значение в которой будет увеличиваться каждые 100 строк по символам английского алфафита. То есть 1-100 строка значение 'A', 101-200 строка значение 'B' и т.п. После значения 'Z' процесс циклически повторяется (то есть начинается снова с 'A').
Требуется сделать это одним запросом (предполагается, что соответствующий ALTER-DDL для добавления колонки new уже сделан).
avtor.fox
Если уже делать через внешний вызов, то почему не tail -n 1 ?
tuareg пишет:
armancho7777777 А PHP_EOL нельзя использовать вместо
Нет, поскольку считывание идёт в один байт. Если PHP_EOL будет использоваться под Win, то равенства, очевидно, не произойдёт никогда, ведь один байт никогда не будет равен двум сразу.
armancho7777777 пишет:
if($strlen && ($char == "\r" || $char == "\n"))
Так проверять перенос строки - некорректно, поскольку в зависимости от OS перенос строки может быть разным. Такой же код посчитает возврат каретки переводом строки в *nix, например, что неверно.
Правильная мысль:
SAD пишет:
а не проще ее хранить в отдельном файле? и перезаписывать
- а точнее, для начала ответить на вопрос - зачем это нужно? Подозреваю, что это попытка решить не ту проблему не тем способом.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 8901
