I promise I don't make this stuff up. Here is a brief explanation by Chris Shiflett on why "addslashes()" isn't safe.

In GBK (chinese character encoding supported by many databases), 0xbf27 is not a valid multi-byte character, but 0xbf5c is. Interpreted as single-byte characters, 0xbf27 is 0xbf (¿) followed by 0x27 ('), and 0xbf5c is 0xbf (¿) followed by 0x5c (\).

How does this help? If I want to attempt an SQL injection attack against a MySQL database, having single quotes escaped with a backslash is a bummer. If you're using addslashes(), however, I'm in luck. All I need to do is inject something like 0xbf27, and addslashes() modifies this to become 0xbf5c27, a valid multi-byte character followed by a single quote. In other words, I can successfully inject a single quote despite your escaping. That's because 0xbf5c is considered to be a single character, not two. Oops, there goes the backslash.
The article discussing that is located here:
http://shiflett.org/archive/184

What you really need to use is:
mysql_real_escape_string()

The reason I suggest against this approach is simply that you can avoid all this hassle AND be database agnostic by simply using parameterized queries. On top of that, you will get a significant performance increase. Most people using PHP don't care about database portability but in other languages it's important and code is often considered sloppy if it isn't database agnostic.

Either way, server-side validation is still a must at all times. Many other vulnerablies are exposed if you don't use good server-side validation.