FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » is mysqli_real_escape_string bullet proof with binary data?
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Re: is mysqli_real_escape_string bullet proof with binary data? [message #182297 is a reply to message #182281] Sat, 27 July 2013 18:10 Go to previous messageGo to previous message
Pierre Jaury is currently offline  Pierre Jaury
Messages: 5
Registered: July 2013
Karma:
Junior Member
Jerry Stuckle <jstucklex(at)attglobal(dot)net> writes:

> On 7/27/2013 5:45 AM, 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. Also any tips on actually getting the thumbnail data into a
>>> variable - which package is recommended? I've always used GD, but
>>> never been 100% happy with it
>>>
>>
>> As far as the subject goes, i would say: DO NOT TOUCH binary
>> data.....
>>
>> Simply store it, or not, in your database.....
>
> Bull. Binary data works fine in a database - and storing it there has
> many advantages. Easy backup and improved data integrity are just two
> of them.
>
> A file system is just a database with a different means of access.
> They both store bytes.

Well, there is no harm in *storing* binary data. However, binary data is
no text string and should not be handled as text (first of all, most of
text processing relies on encoding standards, which binary data
obviously do not comply with).

Storing binary data inside a database is perfectly fine. You should not,
however:
* use blobs or large text fields as table indexes, even if text indexing
techniques have been improved
* as a consequence, use them as key for selecting/sorting
* embed them directly in a text request.

Prepared statement have multiple advantages when dealing with
parameters:
* there is no known database-related security issue when dealing with
user supplied parameters as prepared statements bound parameters
(whatever the data encoding or contents)
* the php overhead is reduced when dealing with large or numerous
parameters (no complex/long string is concatenated inside php)
* the database processing is also usually faster because the lexer is
released of most of the request length.

Prepared statements are a best practice, both for performance and
security reasons, go for them ;)
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Major trouble with PhpDocumentor
Next Topic: Education Path to become a PHP developer using free online courses
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Thu Nov 28 21:10:25 GMT 2024

Total time taken to generate the page: 0.04801 seconds