Perl DBI(MySQL)在预准备语句中放置单引号而不是实际参数

发布时间：2020-12-15 21:49:57 所属栏目：大数据来源：网络整理

导读：我正在尝试做一个简单的查询作为准备好的声明,但没有成功.这是代码： package sqltest;use DBI;DBI-trace(2);my $dbh = DBI-connect('dbi:mysql:database=test;host=***;port=3306','the_username','****');my $prep = 'SELECT me.id,me.session_data,me.exp

我正在尝试做一个简单的查询作为准备好的声明,但没有成功.这是代码：

package sqltest;
use DBI;

DBI->trace(2);

my $dbh = DBI->connect('dbi:mysql:database=test;host=***;port=3306','the_username','****');
my $prep = 'SELECT me.id,me.session_data,me.expires FROM sys_session me WHERE me.id = ?';
$dbh->{RaiseError} = 1;
my $sth = $dbh->prepare($prep);
$sth->bind_param(1,'session:06b6d2138df949524092eefc066ee5ab3598bf96');
$sth->execute;
DBI::dump_results($sth);

MySQL服务器响应”’附近的语法错误.

DBI跟踪的输出显示

-> bind_param for DBD::mysql::st (DBI::st=HASH(0x21e35cc)~0x21e34f4 1 'session:06b6d2138df949524092eefc066ee5ab3598bf96') thr#3ccdb4
 Called: dbd_bind_ph
  <- bind_param= ( 1 ) [1 items] at perl_test_dbi_params.pl line 10
[...]
>parse_params statement SELECT me.id,me.expires FROM sys_session me WHERE me.id = ?
Binding parameters: SELECT me.id,me.expires FROM sys_session me WHERE me.id = '
[...]
DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''' at line 1

所以对我而言,看起来声明并没有得到应有的准备.
当我发送没有参数的查询时,它按预期工作.

我在这里想念什么？

DBI版本是DBI 1.637-ithread,MySQL版本是5.5.57-0 deb8u1

使用针对MSWin32-x86-multi-thread-64int构建的Windows perl 5,版本26,subversion 1(v5.26.1)进行测试
和Ubuntu perl 5,版本22,颠覆1(v5.22.1)为x86_64-linux-gnu-thread-multi构建

EDIT1：
for context：我在使用Catalyst和Catalyst::Plugin::Session::Store::DBIC时注意到了这个问题.这里,id-column是一个Varchar(72)类型,它包含一个session-id.

EDIT2：

> DBD :: mysql版本是4.043
>通过$sth->执行绑定(‘session：foo’);导致同样的问题
>通过$sth-> bind_param绑定(‘session：foo’,SQL_VARCHAR);导致同样的问题
>绑定数字字段确实有效,但只能使用显式类型定义$sth-> bind_param(1,1512407082,SQL_INTEGER);

EDIT3：
我找到了做更多测试的时间,但没有令人满意的结果：

>我能够使用较旧的服务器进行测试并且有效. DBI和DBD :: mysql的版本是相同的,但我发现服务器使用的是MySQL 5.5客户端,在DBI-trace中报告为MYSQL_VERSION_ID 50557,而我的两个原始测试服务器都使用MySQL 5.7 MYSQL_VERSION_ID 50720和MYSQL_VERSION_ID 50716
>使用$dbh-> {mysql_server_prepare} = 1;它有效！也许这有助于找到这个问题的人,但我现在更愿意找到问题的真正原因

解决方法

从您的跟踪日志可以看出,问号占位符(？)被DBD :: mysql替换为一个撇号(‘).所以它是纯DBD :: mysql的bug.乍一看它完全没有意义……因为占位符被放入两个撇号的参数替换.

可以在那里找到执行此占位符替换的相关代码：https://metacpan.org/source/MICHIELB/DBD-mysql-4.043/dbdimp.c#L784-786

*ptr++ = ''';
          ptr += mysql_real_escape_string(sock,ptr,valbuf,vallen);
          *ptr++ = ''';

所以问题是,上面的C代码可以在* ptr缓冲区中产生一个撇号吗？答案是肯定的,当mysql_real_escape_string()返回相同值的整数作为指针大小减去1 – 当两个撇号被写入* ptr缓冲区中的相同位置时,模拟递减1的数值运算.

这会发生吗？是的,它可以,因为Oracle在MySQL 5.7.6客户端库中更改了mysql_real_escape_string()C函数的API：

https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-6.html#mysqld-5-7-6-feature

Incompatible Change: A new C API function,mysql_real_escape_string_quote(),has been implemented as a replacement for mysql_real_escape_string() because the latter function can fail to properly encode characters when the NO_BACKSLASH_ESCAPES SQL mode is enabled. In this case,mysql_real_escape_string() cannot escape quote characters except by doubling them,and to do this properly,it must know more information about the quoting context than is available. mysql_real_escape_string_quote() takes an extra argument for specifying the quoting context. For usage details,see mysql_real_escape_string_quote().

MySQL 5.7.6版本的mysql_real_escape_string()文档说：

https://dev.mysql.com/doc/refman/5.7/en/mysql-real-escape-string.html

Return Values: The length of the encoded string that is placed into the to argument,not including the terminating null byte,or -1 if an error occurs.

因此,如果在MySQL服务器上启用NO_BACKSLASH_ESCAPES SQL模式,则MySQL 5.7.6客户端的mysql_real_escape_string()无法正常工作并返回错误,因此-1会转换为unsigned long. unsigned long在32bit和64bit x86平台上都与指针大小相同,因此在DBD :: mysql驱动程序的C代码之上产生一个撇号字符.

现在我在下面的pull请求中修复了DBD::MariaDB驱动程序(DBD :: mysql的fork)的这个问题：https://github.com/gooddata/DBD-MariaDB/pull/77

所以当使用MySQL 5.7客户端库编译时,DBD :: MariaDB也是兼容的.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!