In view of the fact that this error pops up in so many systems I take over, I have often gone down the wrong path following the red herring as it were when in fact the answer to this is very common.
Why?
Bespoke systems are the usual suspects. Developers will have told the system what to do when newline, carriage returns and tab characters are entered in the data. Those who are security-conscious will also make their system escape apostrophes (') and double-quotes ("). But who can honestly build a system that thinks of everything from day one?
How?
Check all required values to escape have been escaped. In all my cases this has been the percent sign (%) but I'm listing what needs to be escaped in SQL for future use:
| Character | Description |
|---|---|
| \0 | An ASCII NUL (0x00) character. |
| \' | A single quote (“'”) character. |
| \" | A double quote (“"”) character. |
| \b | A backspace character. |
| \n | A newline (linefeed) character. |
| \r | A carriage return character. |
| \t | A tab character. |
| \Z | ASCII 26 (Control+Z). |
| \\ | A backslash (“\”) character. |
| \% | A “%” character. |
| \_ | A “_” character. |
Additional
An alternative in SQL to escape apostrophes is to change these to paired apostrophes, so:
copyraw
Bear this in mind when you're implementing anti-injection security features.INSERT INTO myTable VALUES ('1', 'It\'s amazing!');
-- equally valid
INSERT INTO myTable VALUES ('1', 'It''s amazing!');
- INSERT INTO myTable VALUES ('1', 'It\'s amazing!');
- -- equally valid
- INSERT INTO myTable VALUES ('1', 'It''s amazing!');
Category: MySQL :: Article: 462
