Bug #62361 [Ana]: SQLite3::escapeString is not binary safe
| From: | cmb@php.net | Date: | Mon, 27 Jun 2016 14:05:09 +0000 |
| Subject: | Bug #62361 [Ana]: SQLite3::escapeString is not binary safe | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-201868@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=62361&edit=1
ID: 62361
Updated by: cmb@php.net
Reported by: lgynove at 163 dot com
-Summary: SQLite3::escapeString
+Summary: SQLite3::escapeString is not binary safe
Status: Analyzed
Type: Bug
Package: SQLite related
Operating System: *
PHP Version: 5.3.14
-Assigned To:
+Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
> Even if we made "escape"/"quote" binary safe, it may not work as
> expected. I think SQLite3 users should use bind blob.
ACK
> Is anyone verified manual escaping/quoting works for blob?
Do mean escaping by SQLite3::escapeString()? This is not binary
safe[1], what has to be documented, so I'm changing to doc bug.
[1] <https://3v4l.org/hPH7B>
Previous Comments:
------------------------------------------------------------------------
[2013-10-26 01:58:35] yohgaki@php.net
I've made bug 63419 'feedback'.
Even if we made "escape"/"quote" binary safe, it may not work as expected. I
think SQLite3 users should use bind blob.
Is anyone verified manual escaping/quoting works for blob?
------------------------------------------------------------------------
[2012-11-02 11:26:59] daniel dot kinzler at wikimedia dot de
The same problem exists with the SQLite driver for PDO, see bug 63419
------------------------------------------------------------------------
[2012-06-27 16:44:54] ab@php.net
Ok, after digging into the subject i've found sqlite3_bind_blob() here http://www.sqlite.org/c3ref/bind_blob.html .
This functionality fully replaces sqlite2's sqlite_encode_binary() in sqlite3. As I can see,
it's also implemented and available in PHP http://de2.php.net/manual/de/sqlite3stmt.bindparam.php
.
It looks pretty much like if we want to have the old behaviour, we should take encode.c from PECL. A
sticky point here - I'm not sure that the encoding algorithms are equivalent in both 2 and 3.
So we would need also something like ->unescapeString() to get the data back. That could be
useful in some cases but anyway redundant in sqlite3.
What do you think?
------------------------------------------------------------------------
[2012-06-27 14:41:49] ab@php.net
Ah, now I see what you mean. php_sqlite_encode_binary in the PECL code, strange it wasn't moved
into sqlite3.
------------------------------------------------------------------------
[2012-06-27 13:57:55] felipe@php.net
But we have implemented an auxiliar escaping routine to escape the binary ones, as pointed out by
the reporter.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=62361
--
Edit this bug report at https://bugs.php.net/bug.php?id=62361&edit=1