Offline data migration fails for BLOB field from MySQL 5.0 to 11g

Question

I tried to use standalone Data Migration several years ago to move a database from MySQL to Oracle. At that time it was unable to migrate blob fields. I am trying again, hoping this issue might have been fixed in the mean time. That does not appear to be the case. The rows in question have a single BLOB field (it is a binary encoding of a serialized Java object, containing on the order of 1-2K bytes, a mixture of plain text and a small amount of non-ASCII data which is presumably part of the structure of the Java object). The mysqldump appears to correctly store the data, surrounded by the expected <EOFD> and <EORD> separators. The data as imported consists of a small (roughly 1-200) ASCII characters, apparently hex encoded, because if I do a hex dump of the mysqldump I can recognized some of the character pairs that appear in the blob field after import. However, they are apparently flipped within the word or otherwise displaced from each other (although both source and destinations machines are x86 family), and the imported record stops long before all the data is encoded.
For example, here is a portion of the record as imported:
ACED0005737200136A6
and here is a hex dump of the input
0000000 3633 3838 3037 3c39 4f45 4446 303e 3131
0000020 3036 3830 3836 453c 464f 3e44 312d 453c
0000040 464f 3e44 6e49 7473 7469 7475 6f69 446e
0000060 7461 3c61 4f45 4446 ac3e 00ed 7305 0072
0000100 6a13 7661 2e61 7475 6c69 482e 7361 7468
0000120 6261 656c bb13 250f 4a21 b8e4 0003 4602
0000140 0a00 6f6c 6461 6146 7463 726f 0049 7409
0000160 7268 7365 6f68 646c 7078 403f 0000 0000
AC ED appears in the 5th and 6th word of the 4th line, 00 05 in the 6th and 7th words, etc.
I see explicit references to using hex encoding for MS SQL and other source DB's, but not for mysql.
I suspect the encoder is hitting some character within the binary data that is aborting the encoding process, because so far the records I've looked at contain the same data (roughly 150 characters) for every record, and when I look at the binary input, it appears to be part of the Java object structure which may repeat for every record.
Here is the ctl code:
load data
infile 'user_data_ext.txt' "str '<EORD>'"
into table userinfo.user_data_ext
fields terminated by '<EOFD>'
trailing nullcols
internal_id NULLIF internal_id = 'NULL',
rt_number "DECODE(:rt_number, 'NULL', NULL, NULL, ' ', :rt_number)",
member_number "DECODE(:member_number, 'NULL', NULL, NULL, ' ', :member_number)",
object_type "DECODE(:object_type, 'NULL', NULL, NULL, ' ', :object_type)",
object_data CHAR(2000000) NULLIF object_data = 'NULL'
)

Answer 1

It looks like the data is actually being converted correctly. What threw me off was the fact that the mysql client displays the actual blob bytes, while sqlplus automatically converts them to hex for display, but only shows about 2 lines of the hex data. When I check field lengths they are correct.