I think you're trying to say that content neutralization (turning ' into ", for instance) stops SQLI. It might or it might not, depending on the vector (tablespace injection doesn't care about metacharacters, for instance). It's at least more accurate than saying "if you make sure that the web app doesn't spit out [!@#$%^&*(){}:"<>?] you're safe".
http://www.reddit.com/r/programming/comments/86kgp/xss_cross...
which is the context of my quote of larholm above and is a discussion about this page
http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Pr...
Perhaps this is not common usage, but within this context I believe I am correct in saying output normalization is what prevents SQL injection.
larholm goes on to say:
"The lack of output normalization IS the security vulnerability."
"You can either normalize your output for each specific location as you encounter it, or normalize your input once in advance for all current and future output locations."
"The former beats the latter, as it is impossible for you to know how the data will be output in the future."
which also seems correct.
What is "tablespace injection"? I just googled it and there are no references to it anywhere.
http://www.google.com/search?q=%22tablespace+injection%22...
I did not explain very clearly. What I was trying to say was that output normalisation will prevent SQL injection attacks.
I am considering the components of the SQL statement, such as the string O'Beirne, to be things that have to be normalised before being output to the database in the SQL statement. This output normalisation, as the other replies to my post have correctly said, is best done for you by a library. It cannot be done properly by restricting the inputs, as my O'Beirne example shows, only by output normalisation of the SQL.