I think that "probably" the mistake is in the way you are inserting the blob. 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. Carlos Proal 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:namez...@afim.info] Sent: Tuesday, August 24, 2010 2:48 PM To: mysql@lists.mysql.com 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 encoded. My insert statement (simplified) does this: INSERT INTO _table_ (Desc, Data) VALUES ('...', '_blobdata_'); I have also tried the _binary introducer (http://dev.mysql.com/doc/refman/5.1/en/string-syntax.html) 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 set. 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=namez...@afim.info
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
