I am running into a character problem and I am seeking a little advice.

The client is moving his code from one server to another. The destination
server has MySQL 4.0.7 and the host will not upgrade. The source server has
MySql 4.1.22.

On the source server a string with an apostrophe that was written to the
database displays properly. Porting those data to the destination site, and
using the same code, produces strange results. For example, the apostrophe
(value=39) displays as the characters for the sequence with values of 226,
128, 153.

If I put in a new string with an apostrophe via php code on the destination
server, then retrieval of that string displays properly there.

For the old strings I have tried stripslashes, but this had no effect.

This is not the only situation. The word cafe, for example, with the
(whatever-kind-it-is) accent also displays poorly ont the destination
server.

In summary: On the destination system all new data will display properly.
However, old data do not.

Suggestions?

--
Shelly

Shelly wrote:
> I am running into a character problem and I am seeking a little advice.
>
> The client is moving his code from one server to another. The destination
> server has MySQL 4.0.7 and the host will not upgrade. The source server has
> MySql 4.1.22.
>
> On the source server a string with an apostrophe that was written to the
> database displays properly. Porting those data to the destination site, and
> using the same code, produces strange results. For example, the apostrophe
> (value=39) displays as the characters for the sequence with values of 226,
> 128, 153.
>
> If I put in a new string with an apostrophe via php code on the destination
> server, then retrieval of that string displays properly there.
>
> For the old strings I have tried stripslashes, but this had no effect.
>
> This is not the only situation. The word cafe, for example, with the
> (whatever-kind-it-is) accent also displays poorly ont the destination
> server.
>
> In summary: On the destination system all new data will display properly.
> However, old data do not.
>
> Suggestions?
>
I suspect its not the age of the Mysql, but a php/mysql config issue.

Is it magicl sashes?

Stucklehead will probably come along and tell you all you never wanted
to know..

On Nov 13, 9:45 am, "Shelly" <sheldonlg.n...@asap-consult.com> wrote:
>
> The client is moving his code from one server to another.
> The destination server has MySQL 4.0.7 and the host will
> not upgrade. The source server has MySql 4.1.22.

And what are the default character sets on the two servers?

> On the source server a string with an apostrophe that was
> written to the database displays properly. Porting those
> data to the destination site, and using the same code,
> produces strange results. For example, the apostrophe
> (value=39) displays as the characters for the sequence
> with values of 226, 128, 153.

Which is the Unicode rendition of &rsquo;...

> This is not the only situation. The word cafe, for
> example, with the (whatever-kind-it-is) accent also
> displays poorly ont the destination server.

Another reason to suspect a character set problem...

> In summary: On the destination system all new data will
> display properly. However, old data do not.
>
> Suggestions?

Three: (1) character set, (2) character set, and (3) character set. I
would guess that the source server is configured with Latin-1 (or
similar) default encoding, while the destination server is configured
with UTF-8...

Cheers,
NC

The Natural Philosopher wrote:
> Shelly wrote:
>> I am running into a character problem and I am seeking a little
>> advice. The client is moving his code from one server to another. The
>> destination server has MySQL 4.0.7 and the host will not upgrade. The
>> source server has MySql 4.1.22.
>>
>> On the source server a string with an apostrophe that was written to
>> the database displays properly. Porting those data to the
>> destination site, and using the same code, produces strange results.
>> For example, the apostrophe (value=39) displays as the characters
>> for the sequence with values of 226, 128, 153.
>>
>> If I put in a new string with an apostrophe via php code on the
>> destination server, then retrieval of that string displays properly
>> there. For the old strings I have tried stripslashes, but this had no
>> effect. This is not the only situation. The word cafe, for example, with
>> the
>> (whatever-kind-it-is) accent also displays poorly ont the destination
>> server.
>>
>> In summary: On the destination system all new data will display
>> properly. However, old data do not.
>>
>> Suggestions?
>>
> I suspect its not the age of the Mysql, but a php/mysql config issue.
>
> Is it magicl sashes?

When I look at the data via phpMyAdmin, I see an apostrophe. When I expand
the result I fetch via php code, it shows that sequence.

>
> Stucklehead will probably come along and tell you all you never wanted
> to know..

I doubt it. He thinks I am lazy and "stoooopid". Oh, and a performation in
a donkey. But, I'll welcome any and all ful hints.

--
Shelly

NC wrote:
> On Nov 13, 9:45 am, "Shelly" <sheldonlg.n...@asap-consult.com> wrote:
>>
>> The client is moving his code from one server to another.
>> The destination server has MySQL 4.0.7 and the host will
>> not upgrade. The source server has MySql 4.1.22.
>
> And what are the default character sets on the two servers?

On the destination it IS UTF-8. On the source, I guess it is Latin. (It
says en-us)

>
>> On the source server a string with an apostrophe that was
>> written to the database displays properly. Porting those
>> data to the destination site, and using the same code,
>> produces strange results. For example, the apostrophe
>> (value=39) displays as the characters for the sequence
>> with values of 226, 128, 153.
>
> Which is the Unicode rendition of &rsquo;...
>
>> This is not the only situation. The word cafe, for
>> example, with the (whatever-kind-it-is) accent also
>> displays poorly ont the destination server.
>
> Another reason to suspect a character set problem...
>
>> In summary: On the destination system all new data will
>> display properly. However, old data do not.
>>
>> Suggestions?
>
> Three: (1) character set, (2) character set, and (3) character set. I
> would guess that the source server is configured with Latin-1 (or
> similar) default encoding, while the destination server is configured
> with UTF-8...

It seems that you are right on. Now I have to figure out the conversions.

--
Shelly

NC wrote:
> On Nov 13, 9:45 am, "Shelly" <sheldonlg.n...@asap-consult.com> wrote:

>> Suggestions?
>
> Three: (1) character set, (2) character set, and (3) character set. I
> would guess that the source server is configured with Latin-1 (or
> similar) default encoding, while the destination server is configured
> with UTF-8...

I guess the best thing for me to do is convert the column in the table from
Latin1 to UTF-8.

--
Shelly