I think that "probably" the mistake is in the way you are inserting the
If i understand right, you are inserting the blob with a traditional
insert statement ??, in my experience i always use prepared statements
to insert blobs, in that way the text goes exactly as the source without
any utf-8 conversion.
Besides this, using the insert can truncate your blob / statement,
because some drivers/connectors limit the size of the sql statement, so
if you are uploading a huge file the statement will not work (I dont
know if this happens with the mysql driver or if there is a limit), so i
strongly recommend using prepared statements for blobs with any database.
Hope this helps.
On 8/28/2010 1:04 AM, Andreas Iwanowski wrote:
> Has no one encountered this before? There has got to be a solution, and
> I still haven't found it... So if you have any input please let me know!
> -----Original Message-----
> From: Andreas Iwanowski [mailto:namezero@stripped]
> Sent: Tuesday, August 24, 2010 2:48 PM
> To: mysql@stripped
> Subject: BLOB data gets encoded as utf8!
> Hello everyone!
> I am using an MFC unicode project that uses ODBC to access a MySQL
> 5.1.50 database via the MySQL ODBC 5.1.6 driver.
> character_set_connection is set to utf8 (Which I believe is the default
> for the driver) One of the tables contains two LONGBLOB columns, and the
> table default charset is utf-8 (since the application is unicode).
> However, when inserting into the LONGBLOB columns via an INSERT
> statement, the data gets corrupted/modified because is incorrectly UTF-8
> My insert statement (simplified) does this:
> INSERT INTO _table_ (Desc, Data) VALUES ('...', '_blobdata_');
> I have also tried the _binary introducer
> INSERT INTO _table_ (Desc, Data) VALUES ('...', _binary'_blobdata_');
> I'm escaping 0x00, 0x22, 0x27, and 0x5C, which are the only four that
> MySQL requires to be escaped per documentation for BLOB fields, and
> according to the MySQL docs columns of any BLOB type use no character
> Here is the problem: I found that, for example, 0xFF gets modified to
> 0xC3BF, which is in fact the UTF8 encoding for ASCII/Binary 0xFF.
> Needless to say the data becomes useless. I did, however, determine that
> the data is already "corrupted" in the myodbc.log file that the driver
> outputs if the option is set, so there is likely a problem with the
> driver settings or with the statement itself.
> I cannot be the first one to encounter this issue, so maybe if you have
> an idea (or a solution would be even better! :) then please let me know.
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql?unsub=1