Почему я не должен использовать функции mysql_ * в PHP?


Answers

PHP предлагает три разных API для подключения к MySQL. Это mysql (удаленные с PHP 7), mysqli и расширения PDO .

Функции mysql_* были очень популярны, но их использование больше не поощряется. Команда документации обсуждает ситуацию с безопасностью базы данных, и обучение пользователей удалению от широко используемого расширения ext / mysql является частью этого (проверьте php.internals: deprecating ext / mysql ).

И более поздняя команда разработчиков PHP приняла решение генерировать ошибки E_DEPRECATED когда пользователи подключаются к MySQL, будь то через mysql_connect() , mysql_pconnect() или неявные функции соединения, встроенные в ext/mysql .

ext/mysql deprecated и был удален с PHP 7 .

См. Красную рамку?

Когда вы переходите на любую mysql_* функций mysql_* , вы видите красную рамку, объясняя, что ее больше не следует использовать.

Зачем

Отказ от ext/mysql не только с безопасностью, но и с доступом ко всем функциям базы данных MySQL.

ext/mysql был создан для MySQL 3.23 и с тех пор получил очень мало дополнений, в то же время сохраняя совместимость с этой старой версией, что делает код немного сложнее в обслуживании. Отсутствующие функции, которые не поддерживаются ext/mysql включают: ( deprecated ).

Причина не использования функции mysql_* :

  • Не активно развивается
  • Удалено с PHP 7
  • Отсутствует интерфейс OO
  • Не поддерживает неблокирующие, асинхронные запросы
  • Не поддерживает подготовленные операторы или параметризованные запросы
  • Не поддерживает хранимые процедуры
  • Не поддерживает несколько операторов
  • Не поддерживает transactions
  • Не поддерживает все функции в MySQL 5.1

Выше указана цитата из ответа Квентина

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

См. Сравнение расширений SQL .

Подавление предупреждений об устаревании

Хотя код преобразуется в MySQLi / PDO , ошибки E_DEPRECATED могут быть подавлены установкой error_reporting в php.ini, чтобы исключить E_DEPRECATED:

error_reporting = E_ALL ^ E_DEPRECATED

Обратите внимание, что это также скроет другие предупреждения об устаревании , которые, однако, могут быть для вещей, отличных от MySQL. ( из руководства PHP )

Статья PDO против MySQLi: что вы должны использовать? by Dejan Marjanovic поможет вам выбрать.

И лучшим способом является PDO , и теперь я пишу простой учебник PDO .

Простой и короткий учебник PDO

Вопрос. Первый вопрос в моем сознании: что такое «PDO»?

A. « PDO - объекты данных PHP - это уровень доступа к базе данных, обеспечивающий единый метод доступа к нескольким базам данных».

Подключение к MySQL

С mysql_* или мы можем сказать, что это старый способ (устаревший в PHP 5.5 и выше)

$link = mysql_connect('localhost', 'user', 'pass');
mysql_select_db('testdb', $link);
mysql_set_charset('UTF-8', $link);

С PDO : все, что вам нужно сделать, это создать новый объект PDO . Конструктор принимает параметры для указания источника базы данных. Конструктор PDO основном четыре параметра, которые являются DSN (имя источника данных) и, возможно, username , password .

Здесь я думаю, что вы знакомы со всеми, кроме DSN ; это новое в PDO . DSN - это в основном строка параметров, которые указывают PDO какой драйвер использовать, и сведения о подключении. Для получения дополнительной информации проверьте PDO MySQL DSN .

$db = new PDO('mysql:host=localhost;dbname=testdb;charset=utf8', 'username', 'password');

Примечание: вы также можете использовать charset=UTF-8 , но иногда это вызывает ошибку, поэтому лучше использовать utf8 .

Если есть какая-либо ошибка соединения, он будет генерировать объект PDOException который может быть кэширован для дальнейшего управления Exception .

Хорошо читайте : Подключение и управление подключением ¶

Вы также можете передать несколько параметров драйвера в виде массива в четвертый параметр. Я рекомендую передать параметр, который помещает PDO в режим исключения. Поскольку некоторые драйверы PDO не поддерживают собственные подготовленные инструкции, PDO выполняет эмуляцию подготовки. Он также позволяет вам вручную включить эту эмуляцию. Чтобы использовать собственные подготовленные инструкции на стороне сервера, вы должны явно установить значение false .

Другой - отключить подготовку эмуляции, которая включена в драйвере MySQL по умолчанию, но подготовить эмуляцию следует отключить, чтобы безопасно использовать PDO .

Позже я объясню, почему подготовка эмуляции должна быть отключена. Чтобы найти причину, пожалуйста, проверьте этот пост .

Это можно использовать только в том случае, если вы используете старую версию MySQL которую я не рекомендую.

Ниже приведен пример того, как вы можете это сделать:

$db = new PDO('mysql:host=localhost;dbname=testdb;charset=UTF-8', 
              'username', 
              'password',
              array(PDO::ATTR_EMULATE_PREPARES => false,
              PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION));

Можем ли мы установить атрибуты после построения PDO?

Да , мы также можем установить некоторые атрибуты после построения PDO с setAttribute метода setAttribute :

$db = new PDO('mysql:host=localhost;dbname=testdb;charset=UTF-8', 
              'username', 
              'password');
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

Обработка ошибок

Обработка ошибок в PDO намного проще, чем mysql_* .

Общей практикой при использовании mysql_* является:

//Connected to MySQL
$result = mysql_query("SELECT * FROM table", $link) or die(mysql_error($link));

OR die() не является хорошим способом справиться с ошибкой, так как мы не можем справиться с этой задачей в die . Он просто закончит сценарий внезапно, а затем повторит ошибку на экране, который вы обычно НЕ хотите показывать своим конечным пользователям, и пусть кровавые хакеры обнаруживают вашу схему. Альтернативно, возвращаемые значения функций mysql_* часто могут использоваться вместе с mysql_error() для обработки ошибок.

PDO предлагает лучшее решение: исключения. Все, что мы делаем с PDO должно быть завернуто в блок try catch . Мы можем принудительно PDO в один из трех режимов ошибок, установив атрибут режима ошибки. Ниже приведены три режима обработки ошибок.

  • PDO::ERRMODE_SILENT . Он просто устанавливает коды ошибок и действует почти так же, как mysql_* где вы должны проверять каждый результат, а затем смотреть на $db->errorInfo(); для получения информации об ошибке.
  • PDO::ERRMODE_WARNING Поднять E_WARNING . (Предупреждения во время выполнения (нефатальные ошибки). Выполнение скрипта не останавливается.)
  • PDO::ERRMODE_EXCEPTION : исключить исключения. Он представляет собой ошибку, вызванную PDO. Вы не должны бросать PDOException из своего собственного кода. Дополнительные сведения об исключениях в PHP см. В разделе Исключения . Он очень похож or die(mysql_error()); , когда он не пойман. Но в отличие от or die() , PDOException можно поймать и обработать изящно, если вы решите это сделать.

Хорошо читал :

Подобно:

$stmt->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_SILENT );
$stmt->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING );
$stmt->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );

И вы можете обернуть его в try catch , как показано ниже:

try {
    //Connect as appropriate as above
    $db->query('hi'); //Invalid query!
} 
catch (PDOException $ex) {
    echo "An Error occured!"; //User friendly message/message you want to show to user
    some_logging_function($ex->getMessage());
}

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

function data_fun($db) {
    $stmt = $db->query("SELECT * FROM table");
    return $stmt->fetchAll(PDO::FETCH_ASSOC);
}

//Then later
try {
    data_fun($db);
}
catch(PDOException $ex) {
    //Here you can handle error and show message/perform action you want.
}

Кроме того, вы можете обрабатывать or die() или мы можем сказать, как mysql_* , но он будет очень разнообразным. Вы можете скрыть опасные сообщения об ошибках в процессе производства, отключив display_errors off и просто прочитав свой журнал ошибок.

Теперь, после прочтения всего вышеизложенного, вы, вероятно, думаете: что, черт возьми, это то, что, когда я просто хочу начать использовать простые SELECT , INSERT , UPDATE или DELETE ? Не беспокойтесь, здесь мы идем:

Выбор данных

Итак, что вы делаете в mysql_* :

<?php
$result = mysql_query('SELECT * from table') or die(mysql_error());

$num_rows = mysql_num_rows($result);

while($row = mysql_fetch_assoc($result)) {
    echo $row['field1'];
}

Теперь в PDO вы можете сделать это следующим образом:

<?php
$stmt = $db->query('SELECT * FROM table');

while($row = $stmt->fetch(PDO::FETCH_ASSOC)) {
    echo $row['field1'];
}

Или

<?php
$stmt = $db->query('SELECT * FROM table');
$results = $stmt->fetchAll(PDO::FETCH_ASSOC);

//Use $results

Примечание . Если вы используете метод, подобный ниже ( query() ), этот метод возвращает объект PDOStatement . Поэтому, если вы хотите получить результат, используйте его, как указано выше.

<?php
foreach($db->query('SELECT * FROM table') as $row) {
    echo $row['field1'];
}

В PDO Data он получается через метод ->fetch() , метод дескриптора вашего оператора. Перед вызовом fetch лучшим подходом будет указание PDO, как вы хотите, чтобы данные были извлечены. В следующем разделе я объясняю это.

Режимы извлечения

Обратите внимание на использование PDO::FETCH_ASSOC в приведенных выше PDO::FETCH_ASSOC fetch() и fetchAll() . Это говорит PDO возвращать строки как ассоциативный массив с именами полей в виде ключей. Есть много других режимов выборки, которые я объясню по одному.

Прежде всего, я объясню, как выбрать режим выборки:

 $stmt->fetch(PDO::FETCH_ASSOC)

В приведенном выше примере я использовал fetch() . Вы также можете использовать:

  • PDOStatement::fetchAll() - возвращает массив, содержащий все строки набора результатов
  • PDOStatement::fetchColumn() - возвращает один столбец из следующей строки набора результатов
  • PDOStatement::fetchObject() - выбирает следующую строку и возвращает ее как объект.
  • PDOStatement::setFetchMode() - установка режима выборки по умолчанию для этого оператора

Теперь я пришел в режим выбора:

  • PDO::FETCH_ASSOC : возвращает массив, индексированный по имени столбца, возвращенный в ваш результирующий набор
  • PDO::FETCH_BOTH (по умолчанию): возвращает массив, индексированный как с именем столбца, так и с номером столбца с 0-индексом, возвращаемым в результирующий набор

Есть еще больше вариантов! Читайте о них все в документации PDOStatement Fetch. ,

Получение числа строк :

Вместо того, чтобы использовать mysql_num_rows для получения числа возвращаемых строк, вы можете получить PDOStatement и выполнить rowCount() , например:

<?php
$stmt = $db->query('SELECT * FROM table');
$row_count = $stmt->rowCount();
echo $row_count.' rows selected';

Получение последнего вставленного идентификатора

<?php
$result = $db->exec("INSERT INTO table(firstname, lastname) VAULES('John', 'Doe')");
$insertId = $db->lastInsertId();

Вставка и обновление или удаление операторов

Что мы делаем в функции mysql_* :

<?php
$results = mysql_query("UPDATE table SET field='value'") or die(mysql_error());
echo mysql_affected_rows($result);

И в pdo это то же самое можно сделать:

<?php
$affected_rows = $db->exec("UPDATE table SET field='value'");
echo $affected_rows;

В вышеприведенном запросе PDO::exec выполняет инструкцию SQL и возвращает количество затронутых строк.

Вставка и удаление будут рассмотрены позже.

Вышеуказанный метод полезен только тогда, когда вы не используете переменную в запросе. Но когда вам нужно использовать переменную в запросе, никогда не пытайтесь, как указано выше, и там для подготовленного оператора или параметризованного оператора .

Подготовленные заявления

В. Что такое подготовленное заявление и зачем оно мне нужно?
A. Подготовленный оператор представляет собой предварительно скомпилированный оператор SQL, который может выполняться несколько раз, отправляя только данные на сервер.

Типичный рабочий процесс использования подготовленного оператора выглядит следующим образом ( цитируется из 3-х пунктов из Википедии ):

  1. Подготовьте : шаблон заявления создается приложением и отправляется в систему управления базами данных (СУБД). Определенные значения остаются неуказанными, называемыми параметрами, заполнителями или связующими переменными (помечены как «ниже»):

    INSERT INTO PRODUCT (name, price) VALUES (?, ?)

  2. СУБД анализирует, компилирует и выполняет оптимизацию запросов в шаблоне оператора и сохраняет результат без его выполнения.

  3. Выполнение : позднее приложение прикладывает (или связывает) значения для параметров, а СУБД выполняет оператор (возможно, возвращает результат). Приложение может выполнять оператор столько раз, сколько требуется с разными значениями. В этом примере он может поставить «Хлеб» для первого параметра и 1.00 для второго параметра.

Вы можете использовать подготовленный оператор, включив заполнители в свой SQL. В основном три из них без заполнителей (не пытайтесь это с переменной ее выше), одна с неназванными заполнителями и одна с именованными заполнителями.

В. Итак, что именуются заполнителями и как их использовать?
A. Именованные заполнители. Используйте описательные имена, которым предшествует двоеточие, вместо вопросительных знаков. Мы не заботимся о позиции / порядке стоимости в владельце имен:

 $stmt->bindParam(':bla', $bla);

bindParam(parameter,variable,data_type,length,driver_options)

Вы также можете связывать с помощью массива execute:

<?php
$stmt = $db->prepare("SELECT * FROM table WHERE id=:id AND name=:name");
$stmt->execute(array(':name' => $name, ':id' => $id));
$rows = $stmt->fetchAll(PDO::FETCH_ASSOC);

Еще одна приятная функция для друзей OOP заключается в том, что именованные заполнители имеют возможность вставлять объекты непосредственно в вашу базу данных, предполагая, что свойства соответствуют именованным полям. Например:

class person {
    public $name;
    public $add;
    function __construct($a,$b) {
        $this->name = $a;
        $this->add = $b;
    }

}
$demo = new person('john','29 bla district');
$stmt = $db->prepare("INSERT INTO table (name, add) value (:name, :add)");
$stmt->execute((array)$demo);

Q. Итак, что такое неназванные заполнители и как их использовать?
A. Приведем пример:

<?php
$stmt = $db->prepare("INSERT INTO folks (name, add) values (?, ?)");
$stmt->bindValue(1, $name, PDO::PARAM_STR);
$stmt->bindValue(2, $add, PDO::PARAM_STR);
$stmt->execute();

а также

$stmt = $db->prepare("INSERT INTO folks (name, add) values (?, ?)");
$stmt->execute(array('john', '29 bla district'));

В приведенном выше вы можете видеть их ? вместо имени, как в имени владельца места. Теперь в первом примере мы присваиваем переменные различным заполнителям ( $stmt->bindValue(1, $name, PDO::PARAM_STR); ). Затем мы присваиваем значения этим заполнителям и выполняем оператор. Во втором примере первый элемент массива переходит к первому ? а второй - второй ? ,

ПРИМЕЧАНИЕ . В неназванных заполнителях мы должны позаботиться о правильном порядке элементов в массиве, которые мы PDOStatement::execute() .

SELECT , INSERT , UPDATE , DELETE подготовленные запросы

  1. SELECT :

    $stmt = $db->prepare("SELECT * FROM table WHERE id=:id AND name=:name");
    $stmt->execute(array(':name' => $name, ':id' => $id));
    $rows = $stmt->fetchAll(PDO::FETCH_ASSOC);
    
  2. INSERT :

    $stmt = $db->prepare("INSERT INTO table(field1,field2) VALUES(:field1,:field2)");
    $stmt->execute(array(':field1' => $field1, ':field2' => $field2));
    $affected_rows = $stmt->rowCount();
    
  3. DELETE :

    $stmt = $db->prepare("DELETE FROM table WHERE id=:id");
    $stmt->bindValue(':id', $id, PDO::PARAM_STR);
    $stmt->execute();
    $affected_rows = $stmt->rowCount();
    
  4. UPDATE :

    $stmt = $db->prepare("UPDATE table SET name=? WHERE id=?");
    $stmt->execute(array($name, $id));
    $affected_rows = $stmt->rowCount();
    

ЗАМЕТКА:

Однако PDO и / или MySQLi не полностью безопасны. Проверьте ответ. Готовые заявления PDO достаточны для предотвращения SQL-инъекций? by ircmaxell . Кроме того, я цитирую часть его ответа:

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$pdo->query('SET NAMES GBK');
$stmt = $pdo->prepare("SELECT * FROM test WHERE name = ? LIMIT 1");
$stmt->execute(array(chr(0xbf) . chr(0x27) . " OR 1=1 /*"));
Question

Каковы технические причины того, почему нельзя использовать функции mysql_* ? (например, mysql_query() , mysql_connect() или mysql_real_escape_string() )?

Почему я должен использовать что-то еще, даже если они работают на моем сайте?

Если они не работают на моем сайте, почему я получаю ошибки, такие как

Предупреждение: mysql_connect (): нет такого файла или каталога




Speaking of technical reasons, there are only a few, extremely specific and rarely used. Most likely you will never ever use them in your life.
Maybe I am too ignorant, but I never had an opportunity to use them things like

  • non-blocking, asynchronous queries
  • stored procedures returning multiple resultsets
  • Encryption (SSL)
  • компрессия

If you need them - these are no doubt technical reasons to move away from mysql extension toward something more stylish and modern-looking.

Nevertheless, there are also some non-technical issues, which can make your experience a bit harder

  • further use of these functions with modern PHP versions will raise deprecated-level notices. They simply can be turned off.
  • in a distant future, they can be possibly removed from the default PHP build. Not a big deal too, as mydsql ext will be moved into PECL and every hoster will be happy to compile PHP with it, as they don't want to lose clients whose sites were working for decades.
  • strong resistance from community. Еverytime you mention these honest functions, you being told that they are under strict taboo.
  • being an average PHP user, most likely your idea of using these functions is error-prone and wrong. Just because of all these numerous tutorials and manuals which teach you the wrong way. Not the functions themselves - I have to emphasize it - but the way they are used.

This latter issue is a problem.
But, in my opinion, the proposed solution is no better either.
It seems to me too idealistic a dream that all those PHP users will learn how to handle SQL queries properly at once. Most likely they would just change mysql_* to mysqli_* mechanically, leaving the approach the same . Especially because mysqli makes prepared statements usage incredible painful and troublesome.
Not to mention that native prepared statements aren't enough to protect from SQL injections, and neither mysqli nor PDO offers a solution.

So, instead of fighting this honest extension, I'd prefer to fight wrong practices and educate people in the right ways.

Also, there are some false or non-significant reasons, like

  • Doesn't support Stored Procedures (we were using mysql_query("CALL my_proc"); for ages)
  • Doesn't support Transactions (same as above)
  • Doesn't support Multiple Statements (who need them?)
  • Not under active development (so what? does it affect you in any practical way?)
  • Lacks an OO interface (to create one is a matter of several hours)
  • Doesn't support Prepared Statements or Parametrized Queries

The last one is an interesting point. Although mysql ext do not support native prepared statements, they aren't required for the safety. We can easily fake prepared statements using manually handled placeholders (just like PDO does):

function paraQuery()
{
    $args  = func_get_args();
    $query = array_shift($args);
    $query = str_replace("%s","'%s'",$query); 

    foreach ($args as $key => $val)
    {
        $args[$key] = mysql_real_escape_string($val);
    }

    $query  = vsprintf($query, $args);
    $result = mysql_query($query);
    if (!$result)
    {
        throw new Exception(mysql_error()." [$query]");
    }
    return $result;
}

$query  = "SELECT * FROM table where a=%s AND b LIKE %s LIMIT %d";
$result = paraQuery($query, $a, "%$b%", $limit);

voila , everything is parameterized and safe.

But okay, if you don't like the red box in the manual, a problem of choice arises: mysqli or PDO?

Well, the answer would be as follows:

  • If you understand the necessity of using a database abstraction layer and looking for an API to create one, mysqli is a very good choice, as it indeed supports many mysql-specific features.
  • If, like vast majority of PHP folks, you are using raw API calls right in the application code (which is essentially wrong practice) - PDO is the only choice , as this extension pretends to be not just API but rather a semi-DAL, still incomplete but offers many important features, with two of them makes PDO critically distinguished from mysqli:

    • unlike mysqli, PDO can bind placeholders by value , which makes dynamically built queries feasible without several screens of quite messy code.
    • unlike mysqli, PDO can always return query result in a simple usual array, while mysqli can do it only on mysqlnd installations.

So, if you are an average PHP user and want to save yourself a ton of headaches when using native prepared statements, PDO - again - is the only choice.
However, PDO is not a silver bullet too and has its hardships.
So, I wrote solutions for all the common pitfalls and complex cases in the PDO tag wiki

Nevertheless, everyone talking about extensions always missing the 2 important facts about Mysqli and PDO:

  1. Prepared statement isn't a silver bullet . There are dynamical identifiers which cannot be bound using prepared statements. There are dynamical queries with an unknown number of parameters which makes query building a difficult task.

  2. Neither mysqli_* nor PDO functions should have appeared in the application code.
    There ought to be an abstraction layer between them and application code, which will do all the dirty job of binding, looping, error handling, etc. inside, making application code DRY and clean. Especially for the complex cases like dynamical query building.

So, just switching to PDO or mysqli is not enough. One has to use an ORM, or a query builder, or whatever database abstraction class instead of calling raw API functions in their code.
And contrary - if you have an abstraction layer between your application code and mysql API - it doesn't actually matter which engine is used. You can use mysql ext until it goes deprecated and then easily rewrite your abstraction class to another engine, having all the application code intact.

Here are some examples based on my safemysql class to show how such an abstraction class ought to be:

$city_ids = array(1,2,3);
$cities   = $db->getCol("SELECT name FROM cities WHERE is IN(?a)", $city_ids);

Compare this one single line with amount of code you will need with PDO .
Then compare with crazy amount of code you will need with raw Mysqli prepared statements. Note that error handling, profiling, query logging already built in and running.

$insert = array('name' => 'John', 'surname' => "O'Hara");
$db->query("INSERT INTO users SET ?u", $insert);

Compare it with usual PDO inserts, when every single field name being repeated six to ten times - in all these numerous named placeholders, bindings, and query definitions.

Another example:

$data = $db->getAll("SELECT * FROM goods ORDER BY ?n", $_GET['order']);

You can hardly find an example for PDO to handle such practical case.
And it will be too wordy and most likely unsafe.

So, once more - it is not just raw driver should be your concern but abstraction class, useful not only for silly examples from beginner's manual but to solve whatever real-life problems.




Because (amongst other reasons) it's much harder to ensure the input data is sanitized. If you use parametrized queries, as one does with PDO or mysqli you can entirely avoid the risk.

As an example, someone could use "enhzflep); drop table users" as a username. The old functions will allow executing multiple statements per query, so something like that nasty bugger can delete a whole table.

If one were to use PDO of mysqli, the user-name would end-up being "enhzflep); drop table users" .

See bobby-tables.com .




mysql_* functions were depreciated (as of php 5.5 ) given the fact that better functions and code structures were developed. The fact that the function was depreciated means that no more effort will be placed into improving it in terms of performance and security, which means it is less future proof .

If you need more reasons:

  • mysql_* functions do not support prepared statements.
  • mysql_* functions do not support the binding of parameters.
  • mysql_* functions lack functionality for Object Oriented Programming.
  • the list goes on ...



Простота использования

Уже упоминались аналитические и синтетические причины. Для новичков есть более существенный стимул прекратить использование устаревших функций mysql_.

Современные API баз данных проще в использовании.

Это в основном связанные параметры, которые могут упростить код. И с share переход к PDO не слишком сложный.

Однако переписывание большей базы кода требует времени. Raison d'être для этой промежуточной альтернативы:

Эквивалентные функции pdo_ * вместо mysql_ *

Используя <pdo_mysql.php> вы можете с минимальными усилиями переключиться с старых функций mysql_. Он добавляет pdo_ которые заменяют их mysql_ .

  1. Просто include_once( <pdo_mysql.php> ); в каждом скрипте вызова, который должен взаимодействовать с базой данных.

  2. Удалите mysql_ функции mysql_ всюду и замените его на pdo_ .

    • mysql_ connect() становится pdo_ connect()
    • mysql_ query() становится pdo_ query()
    • mysql_ num_rows() становится pdo_ num_rows()
    • mysql_ insert_id() становится pdo_ insert_id()
    • mysql_ fetch_array() становится pdo_ fetch_array()
    • mysql_ fetch_assoc() становится pdo_ fetch_assoc()
    • mysql_ real_escape_string() становится pdo_ real_escape_string()
    • и так далее...

  3. Ваш код будет работать одинаково и по-прежнему в основном выглядит одинаково:

    include_once("pdo_mysql.php"); 
    
    pdo_connect("localhost", "usrABC", "pw1234567");
    pdo_select_db("test");
    
    $result = pdo_query("SELECT title, html FROM pages");  
    
    while ($row = pdo_fetch_assoc($result)) {
        print "$row[title] - $row[html]";
    }
    

И вуаля.
В вашем коде используется PDO.
Теперь пришло время использовать его.

Связанные параметры могут быть просты в использовании

Вам просто нужен менее громоздкий API.

pdo_query() добавляет очень легкую поддержку связанных параметров. Преобразование старого кода является простым:

Переместите переменные из строки SQL.

  • Добавьте их в качестве параметров функции с разделителями-запятыми в pdo_query() .
  • Разместить вопросительные знаки ? как заполнители, где переменные были раньше.
  • Избавьтесь от одиночных кавычек, которые ранее вставляли строковые значения / переменные.

Преимущество становится более очевидным для более длинного кода.

Часто строковые переменные не просто интерполируются в SQL, а объединены с экранированием вызовов между ними.

pdo_query("SELECT id, links, html, title, user, date FROM articles
   WHERE title='" . pdo_real_escape_string($title) . "' OR id='".
   pdo_real_escape_string($title) . "' AND user <> '" .
   pdo_real_escape_string($root) . "' ORDER BY date")

С ? заполнители заполнить, вам не нужно беспокоиться об этом:

pdo_query("SELECT id, links, html, title, user, date FROM articles
   WHERE title=? OR id=? AND user<>? ORDER BY date", $title, $id, $root)

Помните, что pdo_ * по-прежнему позволяет либо или .
Просто не избегайте переменной и свяжите ее в том же запросе.

  • Функция закладок обеспечивается за счет реального PDO.
  • Таким образом, также разрешено :named позже :named списки закладок.

Что еще более важно, вы можете безопасно передавать переменные $ _REQUEST [] за любой запрос. Когда представленные поля <form> соответствуют структуре базы данных, она еще короче:

pdo_query("INSERT INTO pages VALUES (?,?,?,?,?)", $_POST);

Такая простота. Но давайте вернемся к некоторым рекомендациям по переписыванию и техническим причинам, почему вы можете избавиться от mysql_ и экранирования.

Исправить или удалить любую функцию oldschool sanitize()

После преобразования всех вызовов mysql_ в pdo_query с привязанными параметрами удалите все избыточные вызовы pdo_real_escape_string .

В частности, вы должны исправить любые sanitize или clean или clean_data или clean_data как clean_data в датированных учебниках в той или иной форме:

function sanitize($str) {
   return trim(strip_tags(htmlentities(pdo_real_escape_string($str))));
}

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

  • Правильный порядок был бы: устаревает stripslashes как самый внутренний вызов, затем strip_tags , затем strip_tags , htmlentities для выходного контекста, и, наконец, _escape_string поскольку его приложение должно непосредственно предшествовать SQL-перекрестку.

  • Но как первый шаг просто избавиться от вызова _real_escape_string .

  • Возможно, вам придется сохранить остальную часть вашей функции sanitize() если ваша база данных и поток приложений ожидают строки, совместимые с HTML-контекстом. Добавьте комментарий, который в дальнейшем применяется только для HTML.

  • Обработка строк / значений делегируется PDO и параметризованным операторам.

  • Если было какое-либо упоминание о stripslashes() в вашей функции stripslashes() , это может указывать на более высокий уровень надзора.

    Историческая заметка о magic_quotes. Эта функция по праву устарела. Однако это часто неправильно отображается как неисправная функция безопасности . Но magic_quotes - это такая же неудачная функция безопасности, как и теннисные мячи в качестве источника питания. Это просто не их цель.

    Первоначальная реализация в PHP2 / FI ввела его в явном виде, просто « кавычки будут автоматически экранированы, что упростит передачу данных формы непосредственно в запросы msql ». В частности, это было случайно безопасно использовать с mSQL , поскольку это поддерживало только ASCII.
    Затем PHP3 / Zend повторно включил magic_quotes для MySQL и неправильно документировал его. Но первоначально это была просто удобная функция , а не для обеспечения безопасности.

Как подготовленные заявления различаются

Когда вы вставляете строковые переменные в SQL-запросы, это не просто становится более сложным для вас. Это также посторонние усилия для MySQL, чтобы снова разделить код и данные.

SQL-инъекции просто состоят в том, что данные попадают в контекст кода . Сервер базы данных не может впоследствии определить, где PHP первоначально склеивал переменные между предложениями запроса.

С привязанными параметрами вы разделяете значения кода SQL и SQL-контекста в вашем PHP-коде. Но он не перетасовывается снова за кулисами (кроме PDO :: EMULATE_PREPARES). Ваша база данных получает неизменные команды SQL и значения переменных 1: 1.

Хотя в этом ответе подчеркивается, что вы должны заботиться о преимуществах чтения, связанных с удалением mysql_ . Иногда из-за этого видимого и технического разделения данных / кода иногда появляется преимущество в производительности (повторяющиеся INSERT с только разными значениями).

Помните, что привязка к параметрам по-прежнему не является волшебным универсальным решением против всех SQL-инъекций. Он обрабатывает наиболее распространенное использование данных / значений. Но не может указывать идентификаторы столбцов / таблиц в белый список, помощь в построении динамических предложений или просто списки значений массива.

Использование гибридного PDO

Эти pdo_* обертки pdo_* создают удобный для кодирования API-интерфейс стоп-зазора. (Это в значительной степени то, что могло бы быть MYSQLI , если бы не MYSQLI сдвиг подписи функции). Они также демонстрируют реальный PDO в большинстве случаев.
Переписывание не обязательно останавливается при использовании новых имен функций pdo_. Вы можете по одному переходу каждый pdo_query () в простой вызов $ pdo-> prepare () -> execute ().

Лучше всего начать с упрощения снова. Например, общий результат:

$result = pdo_query("SELECT * FROM tbl");
while ($row = pdo_fetch_assoc($result)) {

Может быть заменен только итерацией foreach:

foreach ($result as $row) {

Или, еще лучше, прямой и полный поиск массива:

$result->fetchAll();

В большинстве случаев вы получите больше полезных предупреждений, чем PDO или mysql_, как правило, после неудачных запросов.

Другие варианты

Таким образом, это, надеюсь, визуализировало некоторые практические причины и достойный путь для удаления mysql_ .

Просто переключение на pdo не совсем сократило его. pdo_query() также является интерфейсом.

Если вы не вводите привязку параметров или не можете использовать что-то еще из более удобного API, это бессмысленный коммутатор. Надеюсь, что это изображено достаточно просто, чтобы не допустить разочарования для новичков. (Образование обычно работает лучше, чем запрет).

Несмотря на то, что он относится к категории простейших вещей, которые могут быть возможными, это также очень экспериментальный код. Я только что написал это в выходные. Однако есть множество альтернатив. Просто google для абстракции базы данных PHP и немного просмотрите. Для таких задач всегда было и будет множество отличных библиотек.

Если вы хотите еще больше упростить взаимодействие с базой данных, вам понадобятся такие устройства, как Paris/Idiorm . Подобно тому, как никто больше не использует мягкую DOM в JavaScript, вам не нужно вначале нянчиться с необработанным интерфейсом базы данных.




It's possible to define almost all mysql_* functions using mysqli or PDO. Just include them on top of your old PHP application, and it will work on PHP7. My solution here .

<?php

define('MYSQL_LINK', 'dbl');
$GLOBALS[MYSQL_LINK] = null;

function mysql_link($link=null) {
    return ($link === null) ? $GLOBALS[MYSQL_LINK] : $link;
}

function mysql_connect($host, $user, $pass) {
    $GLOBALS[MYSQL_LINK] = mysqli_connect($host, $user, $pass);
    return $GLOBALS[MYSQL_LINK];
}

function mysql_pconnect($host, $user, $pass) {
    return mysql_connect($host, $user, $pass);
}

function mysql_select_db($db, $link=null) {
    $link = mysql_link($link);
    return mysqli_select_db($link, $db);
}

function mysql_close($link=null) {
    $link = mysql_link($link);
    return mysqli_close($link);
}

function mysql_error($link=null) {
    $link = mysql_link($link);
    return mysqli_error($link);
}

function mysql_errno($link=null) {
    $link = mysql_link($link);
    return mysqli_errno($link);
}

function mysql_ping($link=null) {
    $link = mysql_link($link);
    return mysqli_ping($link);
}

function mysql_stat($link=null) {
    $link = mysql_link($link);
    return mysqli_stat($link);
}

function mysql_affected_rows($link=null) {
    $link = mysql_link($link);
    return mysqli_affected_rows($link);
}

function mysql_client_encoding($link=null) {
    $link = mysql_link($link);
    return mysqli_character_set_name($link);
}

function mysql_thread_id($link=null) {
    $link = mysql_link($link);
    return mysqli_thread_id($link);
}

function mysql_escape_string($string) {
    return mysql_real_escape_string($string);
}

function mysql_real_escape_string($string, $link=null) {
    $link = mysql_link($link);
    return mysqli_real_escape_string($link, $string);
}

function mysql_query($sql, $link=null) {
    $link = mysql_link($link);
    return mysqli_query($link, $sql);
}

function mysql_unbuffered_query($sql, $link=null) {
    $link = mysql_link($link);
    return mysqli_query($link, $sql, MYSQLI_USE_RESULT);
}

function mysql_set_charset($charset, $link=null){
    $link = mysql_link($link);
    return mysqli_set_charset($link, $charset);
}

function mysql_get_host_info($link=null) {
    $link = mysql_link($link);
    return mysqli_get_host_info($link);
}

function mysql_get_proto_info($link=null) {
    $link = mysql_link($link);
    return mysqli_get_proto_info($link);
}
function mysql_get_server_info($link=null) {
    $link = mysql_link($link);
    return mysqli_get_server_info($link);
}

function mysql_info($link=null) {
    $link = mysql_link($link);
    return mysqli_info($link);
}

function mysql_get_client_info() {
    $link = mysql_link();
    return mysqli_get_client_info($link);
}

function mysql_create_db($db, $link=null) {
    $link = mysql_link($link);
    $db = str_replace('`', '', mysqli_real_escape_string($link, $db));
    return mysqli_query($link, "CREATE DATABASE `$db`");
}

function mysql_drop_db($db, $link=null) {
    $link = mysql_link($link);
    $db = str_replace('`', '', mysqli_real_escape_string($link, $db));
    return mysqli_query($link, "DROP DATABASE `$db`");
}

function mysql_list_dbs($link=null) {
    $link = mysql_link($link);
    return mysqli_query($link, "SHOW DATABASES");
}

function mysql_list_fields($db, $table, $link=null) {
    $link = mysql_link($link);
    $db = str_replace('`', '', mysqli_real_escape_string($link, $db));
    $table = str_replace('`', '', mysqli_real_escape_string($link, $table));
    return mysqli_query($link, "SHOW COLUMNS FROM `$db`.`$table`");
}

function mysql_list_tables($db, $link=null) {
    $link = mysql_link($link);
    $db = str_replace('`', '', mysqli_real_escape_string($link, $db));
    return mysqli_query($link, "SHOW TABLES FROM `$db`");
}

function mysql_db_query($db, $sql, $link=null) {
    $link = mysql_link($link);
    mysqli_select_db($link, $db);
    return mysqli_query($link, $sql);
}

function mysql_fetch_row($qlink) {
    return mysqli_fetch_row($qlink);
}

function mysql_fetch_assoc($qlink) {
    return mysqli_fetch_assoc($qlink);
}

function mysql_fetch_array($qlink, $result=MYSQLI_BOTH) {
    return mysqli_fetch_array($qlink, $result);
}

function mysql_fetch_lengths($qlink) {
    return mysqli_fetch_lengths($qlink);
}

function mysql_insert_id($qlink) {
    return mysqli_insert_id($qlink);
}

function mysql_num_rows($qlink) {
    return mysqli_num_rows($qlink);
}

function mysql_num_fields($qlink) {
    return mysqli_num_fields($qlink);
}

function mysql_data_seek($qlink, $row) {
    return mysqli_data_seek($qlink, $row);
}

function mysql_field_seek($qlink, $offset) {
    return mysqli_field_seek($qlink, $offset);
}

function mysql_fetch_object($qlink, $class="stdClass", array $params=null) {
    return ($params === null)
        ? mysqli_fetch_object($qlink, $class)
        : mysqli_fetch_object($qlink, $class, $params);
}

function mysql_db_name($qlink, $row, $field='Database') {
    mysqli_data_seek($qlink, $row);
    $db = mysqli_fetch_assoc($qlink);
    return $db[$field];
}

function mysql_fetch_field($qlink, $offset=null) {
    if ($offset !== null)
        mysqli_field_seek($qlink, $offset);
    return mysqli_fetch_field($qlink);
}

function mysql_result($qlink, $offset, $field=0) {
    if ($offset !== null)
        mysqli_field_seek($qlink, $offset);
    $row = mysqli_fetch_array($qlink);
    return (!is_array($row) || !isset($row[$field]))
        ? false
        : $row[$field];
}

function mysql_field_len($qlink, $offset) {
    $field = mysqli_fetch_field_direct($qlink, $offset);
    return is_object($field) ? $field->length : false;
}

function mysql_field_name($qlink, $offset) {
    $field = mysqli_fetch_field_direct($qlink, $offset);
    if (!is_object($field))
        return false;
    return empty($field->orgname) ? $field->name : $field->orgname;
}

function mysql_field_table($qlink, $offset) {
    $field = mysqli_fetch_field_direct($qlink, $offset);
    if (!is_object($field))
        return false;
    return empty($field->orgtable) ? $field->table : $field->orgtable;
}

function mysql_field_type($qlink, $offset) {
    $field = mysqli_fetch_field_direct($qlink, $offset);
    return is_object($field) ? $field->type : false;
}

function mysql_free_result($qlink) {
    try {
        mysqli_free_result($qlink);
    } catch (Exception $e) {
        return false;
    }
    return true;
}



The MySQL extension is the oldest of the three and was the original way that developers used to communicate with MySQL. This extension is now being deprecated in favor of the other mysqli_ PDO because of improvements made in newer releases of both PHP and MySQL.

  • mysqli_ is the 'improved' extension for working with MySQL databases. It takes advantage of features that are available in newer versions of the MySQL server, exposes both a function-oriented and an object-oriented interface to the developer and a does few other nifty things.

  • PDO offers an API that consolidates most of the functionality that was previously spread across the major database access extensions, ie MySQL, PostgreSQL, SQLite, MSSQL, etc. The interface exposes high-level objects for the programmer to work with database connections, queries and result sets, and low-level drivers perform communication and resource handling with the database server. A lot of discussion and work is going into PDO and it's considered the appropriate method of working with databases in modern, professional code.




Links