On 28 Sep 2004 12:02:02 -0700,
lkrubner@geocities.com (lawrence) wrote:
[color=blue]
>A user writes this sentence: "It was the New Urbanist's nightmare of
>sprawl run amok."
>
>They input that and my PHP script hits it with addslashes() and then
>the sentence gets put in the database. A slash is likely inserted in
>front of the quote mark in "Urbanist's".[/color]
If it is, it should only be for databases that stuff values into SQL (a poor
design choice). For example, MySQL.
The idea is that this then results in the original value being inserted into
the database - the addslashes() is only to encode it as being suitable for the
SQL statement, the slashes should not be stored. If they are, it's been
addslashed too many times.
[color=blue]
>Later the user runs a search of the database for "New Urbanist's
>nightmare".
>
>Even if I run this query using LIKE, nothing will come back?[/color]
Only if you've mangled the data by escaping too many times.
[color=blue]
>Should I hit the text with addslashes before I run the search?[/color]
It depends on your database. Maybe you would, but only so that the un-slashed
version gets searched. This can get complicated further because LIKE may
support escapes as well - so this may become database specific.
[color=blue]
>How do most coders handle this?[/color]
<rant>
Hopefully by using a database or database abstraction layer that supports
placeholders and binding data separately from the SQL statement, avoiding the
whole issue entirely and reducing the risk of making a mistake and leaving
yourself open to SQL injection, and depending on database, severe performance
issues.
</rant>
--
Andy Hassall / <andy@andyh.co.uk> / <http://www.andyh.co.uk>
<http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool