Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #10223 > unrolled thread

Re: is mysqli_real_escape_string bullet proof with binary data?

Back to article view | Back to comp.lang.php

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: is mysqli_real_escape_string bullet proof with binary data? Denis McMahon <denismfmcmahon@gmail.com> - 2013-07-27 18:38 +0000
    Re: is mysqli_real_escape_string bullet proof with binary data? Pierre Jaury <pierre@jaury.eu> - 2013-07-27 22:25 +0200
      Re: is mysqli_real_escape_string bullet proof with binary data? Luuk <luuk@invalid.lan> - 2013-07-27 22:59 +0200
        Re: is mysqli_real_escape_string bullet proof with binary data? The Natural Philosopher <tnp@invalid.invalid> - 2013-07-28 00:50 +0100
          Re: is mysqli_real_escape_string bullet proof with binary data? Luuk <luuk@invalid.lan> - 2013-07-28 17:44 +0200
            Re: is mysqli_real_escape_string bullet proof with binary data? Pierre Jaury <pierre@jaury.eu> - 2013-07-28 18:01 +0200
              Re: is mysqli_real_escape_string bullet proof with binary data? The Natural Philosopher <tnp@invalid.invalid> - 2013-07-28 17:43 +0100
              Re: is mysqli_real_escape_string bullet proof with binary data? Luuk <luuk@invalid.lan> - 2013-07-28 20:31 +0200
            Re: is mysqli_real_escape_string bullet proof with binary data? The Natural Philosopher <tnp@invalid.invalid> - 2013-07-28 17:39 +0100
              Re: is mysqli_real_escape_string bullet proof with binary data? Pierre Jaury <pierre@jaury.eu> - 2013-07-28 19:56 +0200
                Re: is mysqli_real_escape_string bullet proof with binary data? The Natural Philosopher <tnp@invalid.invalid> - 2013-07-28 19:14 +0100
                  Re: is mysqli_real_escape_string bullet proof with binary data? Jerry Stuckle <jstucklex@attglobal.net> - 2013-07-28 15:10 -0400
              Re: is mysqli_real_escape_string bullet proof with binary data? Norman Peelman <npeelman@cfl.rr.com> - 2013-07-28 21:13 -0400
      Re: is mysqli_real_escape_string bullet proof with binary data? The Natural Philosopher <tnp@invalid.invalid> - 2013-07-28 00:46 +0100
      Re: is mysqli_real_escape_string bullet proof with binary data? Jerry Stuckle <jstucklex@attglobal.net> - 2013-07-27 19:56 -0400
        Re: is mysqli_real_escape_string bullet proof with binary data? Pierre Jaury <pierre@jaury.eu> - 2013-07-28 03:55 +0200
          Re: is mysqli_real_escape_string bullet proof with binary data? Jerry Stuckle <jstucklex@attglobal.net> - 2013-07-27 22:11 -0400
    Re: is mysqli_real_escape_string bullet proof with binary data? Jerry Stuckle <jstucklex@attglobal.net> - 2013-07-27 19:58 -0400

#10223 — Re: is mysqli_real_escape_string bullet proof with binary data?

On Sat, 27 Jul 2013 11:45:50 +0200, Luuk wrote:

> On 27-07-2013 11:31, The Natural Philosopher wrote:

>> The target is to create and store thumbnail PNG images in a Mysql
>> table.

> As far as the subject goes, i would say:
> DO NOT TOUCH binary data.....
> Simply store it, or not, in your database.....

Is it trying to store binary data as character data, or does it think it 
needs to string escape binary data types?

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [next] | [standalone]

#10250

[Multipart message — attachments visible in raw view] — view raw

Denis McMahon <denismfmcmahon@gmail.com> writes:

> On Sat, 27 Jul 2013 11:45:50 +0200, Luuk wrote:
>
>> On 27-07-2013 11:31, The Natural Philosopher wrote:
>
>>> The target is to create and store thumbnail PNG images in a Mysql
>>> table.
>
>> As far as the subject goes, i would say:
>> DO NOT TOUCH binary data.....
>> Simply store it, or not, in your database.....
>
> Is it trying to store binary data as character data, or does it think it 
> needs to string escape binary data types?

Escaping strings is a concept only useful when building request strings
that include user supplied data. It does avoid concatenating strings
whith special/control characters that may interfere with the original
language. There is no need to escape strings if you do not embed
them inside your request string (eg. if you use bound parameters).

This is true when dealing with SQL (write prepared statements without
including any user supplied data, then bind the parameters), bash
commands that only require one exec (use exec* instead of system), and
pretty much in any case you construct interpreted code at runtime.

Data sent to MySQL as bound parameters in prepared statements is
shipped as is, it not escaped or processed in any way before the
MySQL API structures are filled with it. Now, for your binary data
to be handled as is by the MySQL server (and skip the charset
processing), the parameter must be bound as MYSQL_TYPE_BLOB, which
you may control when using bind_param.

See http://fr2.php.net/manual/fr/mysqli-stmt.bind-param.php and the
"b" (as in binary) flag for details.

[toc] | [prev] | [next] | [standalone]

#10251

On 27-07-2013 22:25, Pierre Jaury wrote:
> Denis McMahon <denismfmcmahon@gmail.com> writes:
>
>> On Sat, 27 Jul 2013 11:45:50 +0200, Luuk wrote:
>>
>>> On 27-07-2013 11:31, The Natural Philosopher wrote:
>>
>>>> The target is to create and store thumbnail PNG images in a Mysql
>>>> table.
>>
>>> As far as the subject goes, i would say:
>>> DO NOT TOUCH binary data.....
>>> Simply store it, or not, in your database.....
>>
>> Is it trying to store binary data as character data, or does it think it
>> needs to string escape binary data types?
>
> Escaping strings is a concept only useful when building request strings
> that include user supplied data. It does avoid concatenating strings
> whith special/control characters that may interfere with the original
> language. There is no need to escape strings if you do not embed
> them inside your request string (eg. if you use bound parameters).
>
> This is true when dealing with SQL (write prepared statements without
> including any user supplied data, then bind the parameters), bash
> commands that only require one exec (use exec* instead of system), and
> pretty much in any case you construct interpreted code at runtime.
>
> Data sent to MySQL as bound parameters in prepared statements is
> shipped as is, it not escaped or processed in any way before the
> MySQL API structures are filled with it. Now, for your binary data
> to be handled as is by the MySQL server (and skip the charset
> processing), the parameter must be bound as MYSQL_TYPE_BLOB, which
> you may control when using bind_param.
>
> See http://fr2.php.net/manual/fr/mysqli-stmt.bind-param.php and the
> "b" (as in binary) flag for details.
>

Ok, the code i posted earlier in this thread is also posted here:
http://pastebin.com/5D8ZGEhy

Whn using 'bind_param' i choose to use 's' as in string, and not 'b' for 
blob/binary.

The code stores an exact (binary) copy of the file in a MySQL database.

When the 's' in bind_param is changed to 'b', it does not store an exact 
binary copy of the file....

[root@test]> select id, left(hex(image),64) from testpng where id=1;
+----+------------------------------------------------------------------+
| id | left(hex(image),64)                                              |
+----+------------------------------------------------------------------+
|  1 | 89504E470D0A1A0A0000000D49484452000000090000000A0806000000660574 |
+----+------------------------------------------------------------------+
1 row in set (0.00 sec)

[root@test]> \! hexdump -C upArrow.png | head -2
00000000  89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52 
|.PNG........IHDR|
00000010  00 00 00 09 00 00 00 0a  08 06 00 00 00 66 05 74 
|.............f.t|
[root@test]>

I'm not sure how
"Data sent to MySQL as bound parameters in prepared statements is 
shipped as is, it not escaped or processed in any way before the
MySQL API structures are filled with it."
and
"Now, for your binary data to be handled as is by the MySQL server (and 
skip the charset processing), the parameter must be bound as 
MYSQL_TYPE_BLOB, which you may control when using bind_param."
relate to each other...

But I'm stuck in colder weather,
Maybe tomorrow will be better

[toc] | [prev] | [next] | [standalone]

#10254

On 27/07/13 21:59, Luuk wrote:
> On 27-07-2013 22:25, Pierre Jaury wrote:
>> Denis McMahon <denismfmcmahon@gmail.com> writes:
>>
>>> On Sat, 27 Jul 2013 11:45:50 +0200, Luuk wrote:
>>>
>>>> On 27-07-2013 11:31, The Natural Philosopher wrote:
>>>
>>>>> The target is to create and store thumbnail PNG images in a Mysql
>>>>> table.
>>>
>>>> As far as the subject goes, i would say:
>>>> DO NOT TOUCH binary data.....
>>>> Simply store it, or not, in your database.....
>>>
>>> Is it trying to store binary data as character data, or does it 
>>> think it
>>> needs to string escape binary data types?
>>
>> Escaping strings is a concept only useful when building request strings
>> that include user supplied data. It does avoid concatenating strings
>> whith special/control characters that may interfere with the original
>> language. There is no need to escape strings if you do not embed
>> them inside your request string (eg. if you use bound parameters).
>>
>> This is true when dealing with SQL (write prepared statements without
>> including any user supplied data, then bind the parameters), bash
>> commands that only require one exec (use exec* instead of system), and
>> pretty much in any case you construct interpreted code at runtime.
>>
>> Data sent to MySQL as bound parameters in prepared statements is
>> shipped as is, it not escaped or processed in any way before the
>> MySQL API structures are filled with it. Now, for your binary data
>> to be handled as is by the MySQL server (and skip the charset
>> processing), the parameter must be bound as MYSQL_TYPE_BLOB, which
>> you may control when using bind_param.
>>
>> See http://fr2.php.net/manual/fr/mysqli-stmt.bind-param.php and the
>> "b" (as in binary) flag for details.
>>
>
> Ok, the code i posted earlier in this thread is also posted here:
> http://pastebin.com/5D8ZGEhy
>
> Whn using 'bind_param' i choose to use 's' as in string, and not 'b' 
> for blob/binary.
>
> The code stores an exact (binary) copy of the file in a MySQL database.
>
> When the 's' in bind_param is changed to 'b', it does not store an 
> exact binary copy of the file....
>
Why not?

> [root@test]> select id, left(hex(image),64) from testpng where id=1;
> +----+------------------------------------------------------------------+
> | id | left(hex(image),64)                                              |
> +----+------------------------------------------------------------------+
> |  1 | 89504E470D0A1A0A0000000D49484452000000090000000A0806000000660574 |
> +----+------------------------------------------------------------------+
> 1 row in set (0.00 sec)
>
> [root@test]> \! hexdump -C upArrow.png | head -2
> 00000000  89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52 
> |.PNG........IHDR|
> 00000010  00 00 00 09 00 00 00 0a  08 06 00 00 00 66 05 74 
> |.............f.t|
> [root@test]>
>
> I'm not sure how
> "Data sent to MySQL as bound parameters in prepared statements is 
> shipped as is, it not escaped or processed in any way before the
> MySQL API structures are filled with it."
> and
> "Now, for your binary data to be handled as is by the MySQL server 
> (and skip the charset processing), the parameter must be bound as 
> MYSQL_TYPE_BLOB, which you may control when using bind_param."
> relate to each other...
>
The meaning is clear: provided you tell the API what it is to expect, it 
will not be processed in ways that do not apply to the object type.

But you contradict that, by saying that binding it as binary  does in 
fact get processed and only as a string will it be passed unaltered.

I'd really like to know why..



> But I'm stuck in colder weather,
> Maybe tomorrow will be better
>


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#10278

On 28-07-2013 01:50, The Natural Philosopher wrote:
> On 27/07/13 21:59, Luuk wrote:
>> On 27-07-2013 22:25, Pierre Jaury wrote:
>>> Denis McMahon <denismfmcmahon@gmail.com> writes:
>>>
>>>> On Sat, 27 Jul 2013 11:45:50 +0200, Luuk wrote:
>>>>
>>>>> On 27-07-2013 11:31, The Natural Philosopher wrote:
>>>>
>>>>>> The target is to create and store thumbnail PNG images in a Mysql
>>>>>> table.
>>>>
>>>>> As far as the subject goes, i would say:
>>>>> DO NOT TOUCH binary data.....
>>>>> Simply store it, or not, in your database.....
>>>>
>>>> Is it trying to store binary data as character data, or does it
>>>> think it
>>>> needs to string escape binary data types?
>>>
>>> Escaping strings is a concept only useful when building request strings
>>> that include user supplied data. It does avoid concatenating strings
>>> whith special/control characters that may interfere with the original
>>> language. There is no need to escape strings if you do not embed
>>> them inside your request string (eg. if you use bound parameters).
>>>
>>> This is true when dealing with SQL (write prepared statements without
>>> including any user supplied data, then bind the parameters), bash
>>> commands that only require one exec (use exec* instead of system), and
>>> pretty much in any case you construct interpreted code at runtime.
>>>
>>> Data sent to MySQL as bound parameters in prepared statements is
>>> shipped as is, it not escaped or processed in any way before the
>>> MySQL API structures are filled with it. Now, for your binary data
>>> to be handled as is by the MySQL server (and skip the charset
>>> processing), the parameter must be bound as MYSQL_TYPE_BLOB, which
>>> you may control when using bind_param.
>>>
>>> See http://fr2.php.net/manual/fr/mysqli-stmt.bind-param.php and the
>>> "b" (as in binary) flag for details.
>>>
>>
>> Ok, the code i posted earlier in this thread is also posted here:
>> http://pastebin.com/5D8ZGEhy
>>
>> Whn using 'bind_param' i choose to use 's' as in string, and not 'b'
>> for blob/binary.
>>
>> The code stores an exact (binary) copy of the file in a MySQL database.
>>
>> When the 's' in bind_param is changed to 'b', it does not store an
>> exact binary copy of the file....
>>
> Why not?
>
>> [root@test]> select id, left(hex(image),64) from testpng where id=1;
>> +----+------------------------------------------------------------------+
>> | id | left(hex(image),64)                                              |
>> +----+------------------------------------------------------------------+
>> |  1 | 89504E470D0A1A0A0000000D49484452000000090000000A0806000000660574 |
>> +----+------------------------------------------------------------------+
>> 1 row in set (0.00 sec)
>>
>> [root@test]> \! hexdump -C upArrow.png | head -2
>> 00000000  89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52
>> |.PNG........IHDR|
>> 00000010  00 00 00 09 00 00 00 0a  08 06 00 00 00 66 05 74
>> |.............f.t|
>> [root@test]>
>>
>> I'm not sure how
>> "Data sent to MySQL as bound parameters in prepared statements is
>> shipped as is, it not escaped or processed in any way before the
>> MySQL API structures are filled with it."
>> and
>> "Now, for your binary data to be handled as is by the MySQL server
>> (and skip the charset processing), the parameter must be bound as
>> MYSQL_TYPE_BLOB, which you may control when using bind_param."
>> relate to each other...
>>
> The meaning is clear: provided you tell the API what it is to expect, it
> will not be processed in ways that do not apply to the object type.
>
> But you contradict that, by saying that binding it as binary  does in
> fact get processed and only as a string will it be passed unaltered.
>

I was not trying to contradict anything. I was reading the post (from 
Pierre) and was under the impression that i SHOULD use 'b' in bind_param.

I was using 's' in bind_param, and my testprog works ok

These 2 lines made /me confused ;)

> I'd really like to know why..
>

Me likes to know why to

[toc] | [prev] | [next] | [standalone]

#10280

[Multipart message — attachments visible in raw view] — view raw

Luuk <luuk@invalid.lan> writes:

> On 28-07-2013 01:50, The Natural Philosopher wrote:
>> On 27/07/13 21:59, Luuk wrote:
>>> On 27-07-2013 22:25, Pierre Jaury wrote:
>>>> Denis McMahon <denismfmcmahon@gmail.com> writes:
>>>>
>>>>> On Sat, 27 Jul 2013 11:45:50 +0200, Luuk wrote:
>>>>>
>>>>>> On 27-07-2013 11:31, The Natural Philosopher wrote:
>>>>>
>>>>>>> The target is to create and store thumbnail PNG images in a Mysql
>>>>>>> table.
>>>>>
>>>>>> As far as the subject goes, i would say:
>>>>>> DO NOT TOUCH binary data.....
>>>>>> Simply store it, or not, in your database.....
>>>>>
>>>>> Is it trying to store binary data as character data, or does it
>>>>> think it
>>>>> needs to string escape binary data types?
>>>>
>>>> Escaping strings is a concept only useful when building request strings
>>>> that include user supplied data. It does avoid concatenating strings
>>>> whith special/control characters that may interfere with the original
>>>> language. There is no need to escape strings if you do not embed
>>>> them inside your request string (eg. if you use bound parameters).
>>>>
>>>> This is true when dealing with SQL (write prepared statements without
>>>> including any user supplied data, then bind the parameters), bash
>>>> commands that only require one exec (use exec* instead of system), and
>>>> pretty much in any case you construct interpreted code at runtime.
>>>>
>>>> Data sent to MySQL as bound parameters in prepared statements is
>>>> shipped as is, it not escaped or processed in any way before the
>>>> MySQL API structures are filled with it. Now, for your binary data
>>>> to be handled as is by the MySQL server (and skip the charset
>>>> processing), the parameter must be bound as MYSQL_TYPE_BLOB, which
>>>> you may control when using bind_param.
>>>>
>>>> See http://fr2.php.net/manual/fr/mysqli-stmt.bind-param.php and the
>>>> "b" (as in binary) flag for details.
>>>>
>>>
>>> Ok, the code i posted earlier in this thread is also posted here:
>>> http://pastebin.com/5D8ZGEhy
>>>
>>> Whn using 'bind_param' i choose to use 's' as in string, and not 'b'
>>> for blob/binary.
>>>
>>> The code stores an exact (binary) copy of the file in a MySQL database.
>>>
>>> When the 's' in bind_param is changed to 'b', it does not store an
>>> exact binary copy of the file....
>>>
>> Why not?
>>
>>> [root@test]> select id, left(hex(image),64) from testpng where id=1;
>>> +----+------------------------------------------------------------------+
>>> | id | left(hex(image),64)                                              |
>>> +----+------------------------------------------------------------------+
>>> |  1 | 89504E470D0A1A0A0000000D49484452000000090000000A0806000000660574 |
>>> +----+------------------------------------------------------------------+
>>> 1 row in set (0.00 sec)
>>>
>>> [root@test]> \! hexdump -C upArrow.png | head -2
>>> 00000000  89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52
>>> |.PNG........IHDR|
>>> 00000010  00 00 00 09 00 00 00 0a  08 06 00 00 00 66 05 74
>>> |.............f.t|
>>> [root@test]>
>>>
>>> I'm not sure how
>>> "Data sent to MySQL as bound parameters in prepared statements is
>>> shipped as is, it not escaped or processed in any way before the
>>> MySQL API structures are filled with it."
>>> and
>>> "Now, for your binary data to be handled as is by the MySQL server
>>> (and skip the charset processing), the parameter must be bound as
>>> MYSQL_TYPE_BLOB, which you may control when using bind_param."
>>> relate to each other...
>>>
>> The meaning is clear: provided you tell the API what it is to expect, it
>> will not be processed in ways that do not apply to the object type.
>>
>> But you contradict that, by saying that binding it as binary  does in
>> fact get processed and only as a string will it be passed unaltered.
>>
>
> I was not trying to contradict anything. I was reading the post (from
> Pierre) and was under the impression that i SHOULD use 'b' in
> bind_param.
>
> I was using 's' in bind_param, and my testprog works ok
>
> These 2 lines made /me confused ;)
>

Those two lines may sound contradictory, yet they are not. When sent by
the client (wether PHP or any library using the MySQL C API), data is
shipped as is using MySQL binary protocol after being flagged with a
type constant and some other fields (see
http://dev.mysql.com/doc/refman/5.0/en/c-api-prepared-statement-data-structures.html
for details).

Nevertheless, depending on the type you sent data as and your column
types, the MySQL server may process your request content. For instance,
a string argument stored in a char column will go through the encoding
process, based on the client connection encoding and column charset
and collation.

I still feel weird about your example, I am guessing some of the
client-side process your wrote is wrong, but I cannot figure what part.

[toc] | [prev] | [next] | [standalone]

#10283

On 28/07/13 17:01, Pierre Jaury wrote:
> Luuk <luuk@invalid.lan> writes:
>
>
> These 2 lines made /me confused ;)
>
> Those two lines may sound contradictory, yet they are not. When sent by
> the client (wether PHP or any library using the MySQL C API), data is
> shipped as is using MySQL binary protocol after being flagged with a
> type constant and some other fields (see
> http://dev.mysql.com/doc/refman/5.0/en/c-api-prepared-statement-data-structures.html
> for details).
I'll read that. Thank you

> Nevertheless, depending on the type you sent data as and your column
> types, the MySQL server may process your request content. For instance,
> a string argument stored in a char column will go through the encoding
> process, based on the client connection encoding and column charset
> and collation.
Ah. At last the detail I was after. THANK YOU.
Do I take it that data intended fora BLOB column is NOT pre processed, 
and data flagged as binary is not pre processed, either.
> I still feel weird about your example, I am guessing some of the
> client-side process your wrote is wrong, but I cannot figure what part.
time will tell.

In the end this whole question is about how to get binary data into a 
blob object using php in the most efficient and reliable way possible.

Its a fairly common problem that I found the documentation did not 
adequately handle.

-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#10287

On 28-07-2013 18:01, Pierre Jaury wrote:
> Luuk <luuk@invalid.lan> writes:
>
>> On 28-07-2013 01:50, The Natural Philosopher wrote:
>>> On 27/07/13 21:59, Luuk wrote:
>>>> On 27-07-2013 22:25, Pierre Jaury wrote:
>>>>> Denis McMahon <denismfmcmahon@gmail.com> writes:
>>>>>
>>>>>> On Sat, 27 Jul 2013 11:45:50 +0200, Luuk wrote:
>>>>>>
>>>>>>> On 27-07-2013 11:31, The Natural Philosopher wrote:
>>>>>>
>>>>>>>> The target is to create and store thumbnail PNG images in a Mysql
>>>>>>>> table.
>>>>>>
>>>>>>> As far as the subject goes, i would say:
>>>>>>> DO NOT TOUCH binary data.....
>>>>>>> Simply store it, or not, in your database.....
>>>>>>
>>>>>> Is it trying to store binary data as character data, or does it
>>>>>> think it
>>>>>> needs to string escape binary data types?
>>>>>
>>>>> Escaping strings is a concept only useful when building request strings
>>>>> that include user supplied data. It does avoid concatenating strings
>>>>> whith special/control characters that may interfere with the original
>>>>> language. There is no need to escape strings if you do not embed
>>>>> them inside your request string (eg. if you use bound parameters).
>>>>>
>>>>> This is true when dealing with SQL (write prepared statements without
>>>>> including any user supplied data, then bind the parameters), bash
>>>>> commands that only require one exec (use exec* instead of system), and
>>>>> pretty much in any case you construct interpreted code at runtime.
>>>>>
>>>>> Data sent to MySQL as bound parameters in prepared statements is
>>>>> shipped as is, it not escaped or processed in any way before the
>>>>> MySQL API structures are filled with it. Now, for your binary data
>>>>> to be handled as is by the MySQL server (and skip the charset
>>>>> processing), the parameter must be bound as MYSQL_TYPE_BLOB, which
>>>>> you may control when using bind_param.
>>>>>
>>>>> See http://fr2.php.net/manual/fr/mysqli-stmt.bind-param.php and the
>>>>> "b" (as in binary) flag for details.
>>>>>
>>>>
>>>> Ok, the code i posted earlier in this thread is also posted here:
>>>> http://pastebin.com/5D8ZGEhy
>>>>
>>>> Whn using 'bind_param' i choose to use 's' as in string, and not 'b'
>>>> for blob/binary.
>>>>
>>>> The code stores an exact (binary) copy of the file in a MySQL database.
>>>>
>>>> When the 's' in bind_param is changed to 'b', it does not store an
>>>> exact binary copy of the file....
>>>>
>>> Why not?
>>>
>>>> [root@test]> select id, left(hex(image),64) from testpng where id=1;
>>>> +----+------------------------------------------------------------------+
>>>> | id | left(hex(image),64)                                              |
>>>> +----+------------------------------------------------------------------+
>>>> |  1 | 89504E470D0A1A0A0000000D49484452000000090000000A0806000000660574 |
>>>> +----+------------------------------------------------------------------+
>>>> 1 row in set (0.00 sec)
>>>>
>>>> [root@test]> \! hexdump -C upArrow.png | head -2
>>>> 00000000  89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52
>>>> |.PNG........IHDR|
>>>> 00000010  00 00 00 09 00 00 00 0a  08 06 00 00 00 66 05 74
>>>> |.............f.t|
>>>> [root@test]>
>>>>
>>>> I'm not sure how
>>>> "Data sent to MySQL as bound parameters in prepared statements is
>>>> shipped as is, it not escaped or processed in any way before the
>>>> MySQL API structures are filled with it."
>>>> and
>>>> "Now, for your binary data to be handled as is by the MySQL server
>>>> (and skip the charset processing), the parameter must be bound as
>>>> MYSQL_TYPE_BLOB, which you may control when using bind_param."
>>>> relate to each other...
>>>>
>>> The meaning is clear: provided you tell the API what it is to expect, it
>>> will not be processed in ways that do not apply to the object type.
>>>
>>> But you contradict that, by saying that binding it as binary  does in
>>> fact get processed and only as a string will it be passed unaltered.
>>>
>>
>> I was not trying to contradict anything. I was reading the post (from
>> Pierre) and was under the impression that i SHOULD use 'b' in
>> bind_param.
>>
>> I was using 's' in bind_param, and my testprog works ok
>>
>> These 2 lines made /me confused ;)
>>
>
> Those two lines may sound contradictory, yet they are not. When sent by
> the client (wether PHP or any library using the MySQL C API), data is
> shipped as is using MySQL binary protocol after being flagged with a
> type constant and some other fields (see
> http://dev.mysql.com/doc/refman/5.0/en/c-api-prepared-statement-data-structures.html
> for details).
>
> Nevertheless, depending on the type you sent data as and your column
> types, the MySQL server may process your request content. For instance,
> a string argument stored in a char column will go through the encoding
> process, based on the client connection encoding and column charset
> and collation.
>

ok, so i'm lucky that the encoding process did not change my png-file ;)

> I still feel weird about your example, I am guessing some of the
> client-side process your wrote is wrong, but I cannot figure what part.
>

thanks for that too ;)

it's a weird example, and of no use for any other thing than being an 
example ;)

[toc] | [prev] | [next] | [standalone]

#10282

On 28/07/13 16:44, Luuk wrote:
>
> I was not trying to contradict anything. I was reading the post (from 
> Pierre) and was under the impression that i SHOULD use 'b' in bind_param.
>
> I was using 's' in bind_param, and my testprog works ok
>
> These 2 lines made /me confused ;)
>
>> I'd really like to know why..
>>
>
> Me likes to know why to
>
Ok. Lets take a step back and summarise - and feel free to correct me if 
I am wrong.

1/. Mysql can store anything in a BLOB.
2/. Using prepared statements binary  data in a 'string' variable will 
be stored correctly via the PHP API.
3/. What about un-prepared statements  like:

(getting data out is not a major issue)

$blob=file_get_contents('mygraffix.png')

mysqli_query($link, sprintf("insert into mytable set myblob='%s'",$blob));

Presumably that will barf at some point because the PHP itself will get 
confused about where the string begins and ends?

Or does it? I suppose its down to the way PHP parses the query string 
and sends it.

Which is why the 'prepared' statement or 'Load_file()' options are 
preferred?

i.e. the problem is not with mysql per se, but with PHPs way of handling 
strings..

In C of course you simply use mysql_real_query() and specify the query 
length..

But I can't actually see how even that will work.. OK you now how long 
the total statement has to be, but
at some level you are going to have a statement like 'update mytable, 
set bmyblob=randombinarydatapossibly_containing,set 
something_else=somethingelse'

That is, simply knowing the completed query LENGTH does not remove 
ambiguity.

Where this leaves me is essentially that methods (1) and (2) above are 
the only reliable ways to do this job.

I'd like that confirmed or denied..

In the past I have always used load_file with no real issues, but in the 
new application security is of major concern. I don't want the average 
uploader of images to have general  FILE access.


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#10284

[Multipart message — attachments visible in raw view] — view raw

The Natural Philosopher <tnp@invalid.invalid> writes:

> On 28/07/13 16:44, Luuk wrote:
>>
>> I was not trying to contradict anything. I was reading the post
>> (from Pierre) and was under the impression that i SHOULD use 'b' in
>> bind_param.
>>
>> I was using 's' in bind_param, and my testprog works ok
>>
>> These 2 lines made /me confused ;)
>>
>>> I'd really like to know why..
>>>
>>
>> Me likes to know why to
>>
> Ok. Lets take a step back and summarise - and feel free to correct me
> if I am wrong.
>
> 1/. Mysql can store anything in a BLOB.
> 2/. Using prepared statements binary  data in a 'string' variable will
> be stored correctly via the PHP API.
> 3/. What about un-prepared statements  like:
>
> (getting data out is not a major issue)
>
> $blob=file_get_contents('mygraffix.png')
>
> mysqli_query($link, sprintf("insert into mytable set
> myblob='%s'",$blob));

This were string escaping is required
(eg. mysqli_real_escape_string($blob)). Rule of thumb: if you are using
uncontrolled data, and more generally any string that is not explicitely
declared in the current scope and that might, for one reason or another,
interfere with the MySQL query language, you MUST escape it before
constructing your text query.

> Presumably that will barf at some point because the PHP itself will
> get confused about where the string begins and ends?
>
> Or does it? I suppose its down to the way PHP parses the query string
> and sends it.

PHP does not parse anything, in that very case, PHP simply builds the
query string by running sprintf then sends the result to the MySQL C
API, as a string. I am not sure how PHP will handle or how the API will
react if you pass a query containing null bytes for instance, but that
is out of the question because you did things properly and did escape
every piece of data that required escaping.

I think you are confusing many notions here, even more than I do
according to Jerry :) As long as you escape your strings when building
text queries, PHP will pass them to the MySQL API, which will send them
to the server, which won't bother parsing and executing your query.

You may, on the other hand, use bound parameters, which simply do not
require you to escape the parameter string because it is processed
completely separately from the sql syntax.

[toc] | [prev] | [next] | [standalone]

#10285

On 28/07/13 18:56, Pierre Jaury wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>
>> On 28/07/13 16:44, Luuk wrote:
>>> I was not trying to contradict anything. I was reading the post
>>> (from Pierre) and was under the impression that i SHOULD use 'b' in
>>> bind_param.
>>>
>>> I was using 's' in bind_param, and my testprog works ok
>>>
>>> These 2 lines made /me confused ;)
>>>
>>>> I'd really like to know why..
>>>>
>>> Me likes to know why to
>>>
>> Ok. Lets take a step back and summarise - and feel free to correct me
>> if I am wrong.
>>
>> 1/. Mysql can store anything in a BLOB.
>> 2/. Using prepared statements binary  data in a 'string' variable will
>> be stored correctly via the PHP API.
>> 3/. What about un-prepared statements  like:
>>
>> (getting data out is not a major issue)
>>
>> $blob=file_get_contents('mygraffix.png')
>>
>> mysqli_query($link, sprintf("insert into mytable set
>> myblob='%s'",$blob));
> This were string escaping is required
> (eg. mysqli_real_escape_string($blob)). Rule of thumb: if you are using
> uncontrolled data, and more generally any string that is not explicitely
> declared in the current scope and that might, for one reason or another,
> interfere with the MySQL query language, you MUST escape it before
> constructing your text query.
>
>> Presumably that will barf at some point because the PHP itself will
>> get confused about where the string begins and ends?
>>
>> Or does it? I suppose its down to the way PHP parses the query string
>> and sends it.
> PHP does not parse anything, in that very case, PHP simply builds the
> query string by running sprintf then sends the result to the MySQL C
> API, as a string. I am not sure how PHP will handle or how the API will
> react if you pass a query containing null bytes for instance, but that
> is out of the question because you did things properly and did escape
> every piece of data that required escaping.
>
> I think you are confusing many notions here, even more than I do
> according to Jerry :) As long as you escape your strings when building
> text queries, PHP will pass them to the MySQL API, which will send them
> to the server, which won't bother parsing and executing your query.
I think in the end it boils down to the basic issue that if you pass a 
non text string AS a text string, you have to escape it, and the effects 
of doing that into a binary target are not necessarily guranteed
And there are only two ways to pass pure binary data AS pure binary 
data,  - using the prepare-statement way or load_file()

(I never pay attention to Jerry. He is far more concerned with his own 
ego than actually providing anything of any value.)

> You may, on the other hand, use bound parameters, which simply do not
> require you to escape the parameter string because it is processed
> completely separately from the sql syntax.
Exactly so.

And that is in fact the way I will go in this instance, since it matches 
the nature of the problems most closely.


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#10290

On 7/28/2013 2:14 PM, The Natural Philosopher wrote:
>
> (I never pay attention to Jerry. He is far more concerned with his own
> ego than actually providing anything of any value.)
>

Nobody ever pays attention to you, either, just like with any anonymous 
troll.  You won't use a real name or email because you're so afraid 
people will find out you're neither a programmer nor the EE you claim to be.

Don't worry - we all know that anyway.

As for ego - you're the one who's ego is so weak you're afraid to use 
your real name.  But you have to blast anyone who is more knowledgeable 
than you (not hard to find in these newsgroups).
-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#10293

On 07/28/2013 12:39 PM, The Natural Philosopher wrote:
> On 28/07/13 16:44, Luuk wrote:
>>
>> I was not trying to contradict anything. I was reading the post (from
>> Pierre) and was under the impression that i SHOULD use 'b' in bind_param.
>>
>> I was using 's' in bind_param, and my testprog works ok
>>
>> These 2 lines made /me confused ;)
>>
>>> I'd really like to know why..
>>>
>>
>> Me likes to know why to
>>
> Ok. Lets take a step back and summarise - and feel free to correct me if
> I am wrong.
>
> 1/. Mysql can store anything in a BLOB.
> 2/. Using prepared statements binary  data in a 'string' variable will
> be stored correctly via the PHP API.
> 3/. What about un-prepared statements  like:
>
> (getting data out is not a major issue)
>
> $blob=file_get_contents('mygraffix.png')
>
> mysqli_query($link, sprintf("insert into mytable set myblob='%s'",$blob));
>
> Presumably that will barf at some point because the PHP itself will get
> confused about where the string begins and ends?
>
> Or does it? I suppose its down to the way PHP parses the query string
> and sends it.
>
> Which is why the 'prepared' statement or 'Load_file()' options are
> preferred?
>
> i.e. the problem is not with mysql per se, but with PHPs way of handling
> strings..
>
> In C of course you simply use mysql_real_query() and specify the query
> length..
>
> But I can't actually see how even that will work.. OK you now how long
> the total statement has to be, but
> at some level you are going to have a statement like 'update mytable,
> set bmyblob=randombinarydatapossibly_containing,set
> something_else=somethingelse'
>
> That is, simply knowing the completed query LENGTH does not remove
> ambiguity.
>
> Where this leaves me is essentially that methods (1) and (2) above are
> the only reliable ways to do this job.
>
> I'd like that confirmed or denied..
>
> In the past I have always used load_file with no real issues, but in the
> new application security is of major concern. I don't want the average
> uploader of images to have general  FILE access.
>
>

http://dev.mysql.com/doc/refman/5.0/en/blob.html

-- 
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-

[toc] | [prev] | [next] | [standalone]

#10253

On 27/07/13 21:25, Pierre Jaury wrote:
> Denis McMahon <denismfmcmahon@gmail.com> writes:
>
>> On Sat, 27 Jul 2013 11:45:50 +0200, Luuk wrote:
>>
>>> On 27-07-2013 11:31, The Natural Philosopher wrote:
>>>> The target is to create and store thumbnail PNG images in a Mysql
>>>> table.
>>> As far as the subject goes, i would say:
>>> DO NOT TOUCH binary data.....
>>> Simply store it, or not, in your database.....
>> Is it trying to store binary data as character data, or does it think it
>> needs to string escape binary data types?
> Escaping strings is a concept only useful when building request strings
> that include user supplied data. It does avoid concatenating strings
> whith special/control characters that may interfere with the original
> language. There is no need to escape strings if you do not embed
> them inside your request string (eg. if you use bound parameters).
>
> This is true when dealing with SQL (write prepared statements without
> including any user supplied data, then bind the parameters), bash
> commands that only require one exec (use exec* instead of system), and
> pretty much in any case you construct interpreted code at runtime.
>
> Data sent to MySQL as bound parameters in prepared statements is
> shipped as is, it not escaped or processed in any way before the
> MySQL API structures are filled with it.
Finally an Answer.

>   Now, for your binary data
> to be handled as is by the MySQL server (and skip the charset
> processing), the parameter must be bound as MYSQL_TYPE_BLOB, which
> you may control when using bind_param.
>
> See http://fr2.php.net/manual/fr/mysqli-stmt.bind-param.php and the
> "b" (as in binary) flag for details.


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#10256

On 7/27/2013 4:25 PM, Pierre Jaury wrote:
> Denis McMahon <denismfmcmahon@gmail.com> writes:
>
>> On Sat, 27 Jul 2013 11:45:50 +0200, Luuk wrote:
>>
>>> On 27-07-2013 11:31, The Natural Philosopher wrote:
>>
>>>> The target is to create and store thumbnail PNG images in a Mysql
>>>> table.
>>
>>> As far as the subject goes, i would say:
>>> DO NOT TOUCH binary data.....
>>> Simply store it, or not, in your database.....
>>
>> Is it trying to store binary data as character data, or does it think it
>> needs to string escape binary data types?
>
> Escaping strings is a concept only useful when building request strings
> that include user supplied data. It does avoid concatenating strings
> whith special/control characters that may interfere with the original
> language. There is no need to escape strings if you do not embed
> them inside your request string (eg. if you use bound parameters).
>

Incorrect.  ALL strings, whether user-supplied or not, need to be 
escaped if you don't use bound values.

> This is true when dealing with SQL (write prepared statements without
> including any user supplied data, then bind the parameters), bash
> commands that only require one exec (use exec* instead of system), and
> pretty much in any case you construct interpreted code at runtime.
>

Additional overhead, as I indicated before.  Additionally, binding 
numeric values greatly increases the overhead (because they do not need 
to be escaped when not using bound variables).  They just need to be 
validated as the appropriate numeric values (which needs to be done in 
either case).

> Data sent to MySQL as bound parameters in prepared statements is
> shipped as is, it not escaped or processed in any way before the
> MySQL API structures are filled with it. Now, for your binary data
> to be handled as is by the MySQL server (and skip the charset
> processing), the parameter must be bound as MYSQL_TYPE_BLOB, which
> you may control when using bind_param.
>
> See http://fr2.php.net/manual/fr/mysqli-stmt.bind-param.php and the
> "b" (as in binary) flag for details.
>

A little knowledge is a dangerous thing.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#10261

[Multipart message — attachments visible in raw view] — view raw

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 7/27/2013 4:25 PM, Pierre Jaury wrote:
>> Denis McMahon <denismfmcmahon@gmail.com> writes:
>>
>>> On Sat, 27 Jul 2013 11:45:50 +0200, Luuk wrote:
>>>
>>>> On 27-07-2013 11:31, The Natural Philosopher wrote:
>>>
>>>>> The target is to create and store thumbnail PNG images in a Mysql
>>>>> table.
>>>
>>>> As far as the subject goes, i would say:
>>>> DO NOT TOUCH binary data.....
>>>> Simply store it, or not, in your database.....
>>>
>>> Is it trying to store binary data as character data, or does it think it
>>> needs to string escape binary data types?
>>
>> Escaping strings is a concept only useful when building request strings
>> that include user supplied data. It does avoid concatenating strings
>> whith special/control characters that may interfere with the original
>> language. There is no need to escape strings if you do not embed
>> them inside your request string (eg. if you use bound parameters).
>>
>
> Incorrect.  ALL strings, whether user-supplied or not, need to be
> escaped if you don't use bound values.

Well, mostly depends on what is meant by "user-supplied". I realize I
was not explicit enough, so: escaping strings is useful when crafting
interpreted code based on values that are not built in the local
scope, ie. parameters to your crafting process (which I mentionned and
will keep mentionning as user-supplied data, wether it is obtained from
a human operator, a file or basically any routine that is external to
the crafting scope).

>> This is true when dealing with SQL (write prepared statements without
>> including any user supplied data, then bind the parameters), bash
>> commands that only require one exec (use exec* instead of system), and
>> pretty much in any case you construct interpreted code at runtime.
>>
>
> Additional overhead, as I indicated before.  Additionally, binding
> numeric values greatly increases the overhead (because they do not
> need to be escaped when not using bound variables).  They just need to
> be validated as the appropriate numeric values (which needs to be done
> in either case).
>

There is, indeed, overhead due to the two-step model (preparation, then
execution). However, on a theorical basis, except that operational
overhead, preparing statements mostly have advantages :

* only the symbolic statement is sent as text, data can be shipped in a
proper binary form (which i believe MySQL does as part of a separate
query protocol),
* as a consequence, no need to build and encode strings on the client
side,
* no need to decode those strings on the server side, the server lexer
may process smaller strings,
* no need to escape text data at any time,
* data-independant statement optimizations may be cached.

Even if prepared statements sound theorically ideal, they still *do*
have a couple of conceptual drawbacks:

* replicating queries on multiple servers is much more complex (which
i believe mysql works around by building fully formatted queries sent to
binary logs),
* logging queries suffers the same complexity (requires that data is
encoded and a full text or binary query built on the server side),
* obviously many other related issues.

I am not really into benchmarks and I did not write applications big
enough based on recent MySQL versions to provide some actual feedback, I
suspect however that MySQL imlementation of prepared statements is still
sketchy (especially on the logging, replication and caching sides,
apparently). Maybe performance will improve with future versions of the
statement engine.

I would really like to read some real-world performance feedback on the
matter, if you have some interesting links to share :)

> A little knowledge is a dangerous thing.

I do not feel in a trolling mood, please stop these.

[toc] | [prev] | [next] | [standalone]

#10262

On 7/27/2013 9:55 PM, Pierre Jaury wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
>
>> On 7/27/2013 4:25 PM, Pierre Jaury wrote:
>>> Denis McMahon <denismfmcmahon@gmail.com> writes:
>>>
>>>> On Sat, 27 Jul 2013 11:45:50 +0200, Luuk wrote:
>>>>
>>>>> On 27-07-2013 11:31, The Natural Philosopher wrote:
>>>>
>>>>>> The target is to create and store thumbnail PNG images in a Mysql
>>>>>> table.
>>>>
>>>>> As far as the subject goes, i would say:
>>>>> DO NOT TOUCH binary data.....
>>>>> Simply store it, or not, in your database.....
>>>>
>>>> Is it trying to store binary data as character data, or does it think it
>>>> needs to string escape binary data types?
>>>
>>> Escaping strings is a concept only useful when building request strings
>>> that include user supplied data. It does avoid concatenating strings
>>> whith special/control characters that may interfere with the original
>>> language. There is no need to escape strings if you do not embed
>>> them inside your request string (eg. if you use bound parameters).
>>>
>>
>> Incorrect.  ALL strings, whether user-supplied or not, need to be
>> escaped if you don't use bound values.
>
> Well, mostly depends on what is meant by "user-supplied". I realize I
> was not explicit enough, so: escaping strings is useful when crafting
> interpreted code based on values that are not built in the local
> scope, ie. parameters to your crafting process (which I mentionned and
> will keep mentionning as user-supplied data, wether it is obtained from
> a human operator, a file or basically any routine that is external to
> the crafting scope).
>

They are also required when using strings built in the local scope.  In 
fact, ANY strings should be processed by mysql_real_escape_string() if 
not using prepared statements.  You never know, for instance, if someone 
later doesn't add a string with a single quote in it.

>>> This is true when dealing with SQL (write prepared statements without
>>> including any user supplied data, then bind the parameters), bash
>>> commands that only require one exec (use exec* instead of system), and
>>> pretty much in any case you construct interpreted code at runtime.
>>>
>>
>> Additional overhead, as I indicated before.  Additionally, binding
>> numeric values greatly increases the overhead (because they do not
>> need to be escaped when not using bound variables).  They just need to
>> be validated as the appropriate numeric values (which needs to be done
>> in either case).
>>
>
> There is, indeed, overhead due to the two-step model (preparation, then
> execution). However, on a theorical basis, except that operational
> overhead, preparing statements mostly have advantages :
>

Theoretical basis is nice.  But PRACTICAL basis is usable.

> * only the symbolic statement is sent as text, data can be shipped in a
> proper binary form (which i believe MySQL does as part of a separate
> query protocol),

Which means additional calls to the server.

> * as a consequence, no need to build and encode strings on the client
> side,

No.  It just means the strings need to be shipped separately via 
individual calls to the server and assembled there.  If the server is 
busy, this can also add to performance problem.

> * no need to decode those strings on the server side, the server lexer
> may process smaller strings,

No need to decode the strings otherwise, either.  And the server lexer 
will still have to assemble the entire string before processing, or 
process multiple smaller strings.  Another performance hit.

> * no need to escape text data at any time,

No, but escaping strings is not that hard.  And numeric values do not 
require escaping - but will still result in additional calls required to 
bind those parameters in a prepared statement.

> * data-independant statement optimizations may be cached.
>

Using non-prepared statements doesn't change this.

> Even if prepared statements sound theorically ideal, they still *do*
> have a couple of conceptual drawbacks:
>

Nothing is "ideal".

> * replicating queries on multiple servers is much more complex (which
> i believe mysql works around by building fully formatted queries sent to
> binary logs),

Replication is not dependent on whether you use prepared statements or not.

> * logging queries suffers the same complexity (requires that data is
> encoded and a full text or binary query built on the server side),
> * obviously many other related issues.
>

It must be encoded and built to process the statement anyway.

> I am not really into benchmarks and I did not write applications big
> enough based on recent MySQL versions to provide some actual feedback, I
> suspect however that MySQL imlementation of prepared statements is still
> sketchy (especially on the logging, replication and caching sides,
> apparently). Maybe performance will improve with future versions of the
> statement engine.
>

Performance can be critical in some cases.  It is something a good 
programmer ALWAYS takes into consideration when writing code.

> I would really like to read some real-world performance feedback on the
> matter, if you have some interesting links to share :)
>

You can google as well as I can.  Or you can run your own benchmarks, 
like I have.

>> A little knowledge is a dangerous thing.
>
> I do not feel in a trolling mood, please stop these.
>

No trolling.  Just an observation you are obviously aware of only SOME 
of the processing involved, and have made incorrect statements based on 
that limited knowledge.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#10257

On 7/27/2013 2:38 PM, Denis McMahon wrote:
> On Sat, 27 Jul 2013 11:45:50 +0200, Luuk wrote:
>
>> On 27-07-2013 11:31, The Natural Philosopher wrote:
>
>>> The target is to create and store thumbnail PNG images in a Mysql
>>> table.
>
>> As far as the subject goes, i would say:
>> DO NOT TOUCH binary data.....
>> Simply store it, or not, in your database.....
>
> Is it trying to store binary data as character data, or does it think it
> needs to string escape binary data types?
>

Yes.  If you're not using prepared statements, you need to escape the 
binary data (because it is handled as a string in the SQL statement).


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web