Originally posted by sgtpepper
Well, I feel alittle embaressed to be telling you all this...but...
Apparently, most of the issues have been because somehow, the code I am using to transfer the database from the ODBC to my mysql database, placed the blobs in HEX format.
Obviously, this is causing me issues 🙂
Can anyone recommend a way I can convert HEX to BINARY?
Wellllllll.... I think it might be time for a bit of a lesson in character representation. There is actually no such thing as blobs in hex format, but you can display blobs formatted as hex, or binary, or octal, or decimal. It all depends upon how you want to view the basic binary data.
Let us start simple. One byte is 8 bits. The possible range of values is 00000000 to 11111111. Thus 00001000 is a valid byte.
Now, you can use this binary data in a variety of ways. First, you can treat the byte as a numeric integer value. Then
00000001 = 1
00000010 = 2
00000011 = 3
00000100 = 4 all the way up to
11111111 = 255
You can also look at the bit patterns as representing ASCII or ANSI characters.
A few selections from with the ASCII world (which is only the lower 128 possible values in a byte)
00001101 (decimal 13) - carriage return
00111101 (decimal 61) - =
01011010 (decimal 90) - capital Z
The ANSI character set includes the first 128 characters and symbols found in the ASCII character set plus the remaining 128 possible values in a byte. Thus,
10110001 (decimal 177) - the (+/-) symbol.
When you look at a typical text dump of a blob in a mysql record, it is displayed in ANSI. That is why you see characters, special symbols, etc. BUt, you could just as easily display it in decimal values as shown above. So, the following ANSI and decimal displays of a blob field are identical. Note: I have put in slashes so that you can see the individual decimal values...the slashes amy or may not be present in a decimal dump
JAC!45/
074/065/067/033/052/053/047
However, in addition to decimal, you can also display the value of a byte in hexadecimal format. So,
00001000 - dec 8, hex 8
00001001 - dec 9, hex 9
00001010 - dec 10, hex A
00001011 - dec 11, hex B
00001100 - dec 12, hex C
00001101 - dec 13, hex D
00001110 - dec 14, hex E
00001111 - dec 15, hex F
00010000 - dec 16, hex 10
So, a byte in hex format runs from 00 to FF, where FF is equivalent to decimal 255.
Then the contents of the mini blob field above look like this. Note: I have put in slashes so that you can see the individual decimal and values...the slashes amy or may not be present in a dump
JAC!45/
074/065/067/033/052/053/047
4A/41/43/21/34/35/2F
So, there are two points to be made here. First, no matter how you represent the binary data in a dump of a blob field, the underlying pattern of the bits remains the same. And thus, it doesn't mean anything to say that your blobs are in hex format. As long as the binary patterns in the source and destination databases are the same, then you got a good copy.
What you need to do is take an ANSI or hex dump of the blob field and determine if you have the correct header field for the image that you are storing. For example, you should always see 'JFIF' in the first few characters of a jpeg image.
Go to www.wotsit.com for a detailed description of many file formats.
Final note. If you are attempting to export a text blob field from one database and then import it into a mysql database, you must be extremely careful that the end of field, end of line, field delimiters, and escape characters are identical in both the program creating the text for export and the importing program or nothing will work right.
I finally gave up trying to use the command line facilities of mysql (mysqldump) to dump a database that would be read by phpMyAdmin... it would never work. Installing phpMyAdmin on my own machine made it a piece of cake.
BeastRider
aka
066101097115116082105100101115
aka
42656173745269646572