Hi Dr.
The avatars still show fine on 4.18a -- but the problem occurs when I actually do a dump
and reimport the dump file. That's when something goes array.. Kinda weird if you ask
me.. I wish that vBulletin wouldn't actually hard code the binary in a table, lol.. It's
got me totally baffled! :)
In a message dated 1/7/2005 4:02:04 AM Eastern Standard Time, "Dr. Frank Ullrich"
<ful@stripped> writes:
>Hi,
>
>Hurrican19@stripped schrieb:
>
>> Hi Tom,
>> Thanks for the reply! I show the following information for my
> DB,
>> and shows the same for both the 3.23 DB And the 4.18a DB
>>
>> Field ---- Type ----
> Collation
>> avatardata ---- mediumtext ---- latin1_swedish_ci
>>
>> I pasted a data table from the bad avatar and the good avatar
>> to a file differential program, there was no differential at all
>> that the system found..
>
>that seems to point towards a client issue.
>Which client do you use to look at the atachments (I think I have heard
>about problems with php and 4.1.x on this list recently)?
>
>As a further test I would suggest that you take the data table (.myd
>file?) from the 4.1.8 db and copy it into a __test__ 3.23 db replacing
>the data table there (it's myisam isn't it?). See if the avatars are ok
>when you read them from the 3.23 db.
>
>Regards,
> Frank.
>
>
>>
>> I'm not too sure where or what to do to change this information? Do you mean
>> that I recompile MySQL using different ./configure commands?
>>
>> Thanks Tom!
>>
>>
>>
>> Hurrican19@stripped <mailto:Hurrican19@stripped> wrote on Thursday, January
>> 06, 2005 4:57 PM:
>>
>>
>>>Sorry, forgot the attachments. These are the same exact two
>>>avatars from the same user, using my 3.23 backup, for the
>>>good avatar, then the 4.18 bad avatar
>>
>>
>> Looks like a character set issue - what's the column type, BLOB or TEXT or
>> something in between?
>>
>> This could be due to the server converting UTF-8 into a different character
>> set. Characters such as 0x8F (143 decimal) and 0x8D are being converted into
>> 0x3F, which is "?" and often indicates that the character does not exist in
>> the target collation. Basically, MySQL is treating the content as text, and
>> replacing characters which it doesn't understand with "?". Try using a
>> different collation or character set, and importing again?
>>
>> Unfortunately, the conversion is not reversible - a set of characters have
>> been replaced with a single character, so although the image is the same
>> binary size, some of the data has been permanently lost unless you can
>> restore from the backup.
>>
>> cheers,
>>
>> Tom
>>
>>
>> In a message dated 1/6/2005 12:48:28 PM Eastern Standard Time, Tom Molesworth
> <TomM@stripped> writes:
>>
>>
>>>Hurrican19@stripped <mailto:Hurrican19@stripped> wrote on Thursday,
> January
>>>06, 2005 4:57 PM:
>>>
>>>
>>>>Sorry, forgot the attachments. These are the same exact two
>>>>avatars from the same user, using my 3.23 backup, for the
>>>>good avatar, then the 4.18 bad avatar
>>>
>>>Looks like a character set issue - what's the column type, BLOB or TEXT or
>>>something in between?
>>>
>>>This could be due to the server converting UTF-8 into a different character
>>>set. Characters such as 0x8F (143 decimal) and 0x8D are being converted into
>>>0x3F, which is "?" and often indicates that the character does not exist in
>>>the target collation. Basically, MySQL is treating the content as text, and
>>>replacing characters which it doesn't understand with "?". Try using a
>>>different collation or character set, and importing again?
>>>
>>>Unfortunately, the conversion is not reversible - a set of characters have
>>>been replaced with a single character, so although the image is the same
>>>binary size, some of the data has been permanently lost unless you can
>>>restore from the backup.
>>>
>>>cheers,
>>>
>>>Tom
>>>
>>>--
>>>MySQL General Mailing List
>>>For list archives: http://lists.mysql.com/mysql
>>>To unsubscribe: http://lists.mysql.com/mysql?unsub=1
>>>
>>>
>>
>>
>
>--
>Dr. Frank Ullrich, DBA Netzwerkadministration
>Heise Zeitschriften Verlag GmbH & Co KG, Helstorfer Str. 7, D-30625 Hannover
>E-Mail: frank.ullrich@stripped
>Phone: +49 511 5352 587; FAX: +49 511 5352 538
>
>
