Part of website in utf8 and other part in Occidental ???

[svergeylen]

Hello,

I've got a probmem with a new install of Cmsms 1.5, filled with old content.

I've got the display of the date in the news module which is in Occidental encoding, in place of Utf-8.

I can display correctly the "é" and "è" when I select Occidental but when I do that, all the rest is displyed with strange caracters !

My conclusion is that my website is correctly in utf-8 but the date is not. How can I resolve that ?

Thank you !

ps : see the printscreen in attach for more understanding...

[svergeylen]

I've uninstall and re-install the news module but the problem is still there.... Any idea Thanks !

[Dr.CSS]

New install with old content, how is that possible?...

[svergeylen]

I've inserted all the tables which have content of my old cmsms into the database of the new cmsms (1.5)

Perhaps is there a conflict in the encoding ? But I don't see the link between content in database and the fact that dates are display in Occidental.. Any idea ?

Thanks !

[Dr.CSS]

Sounds like a DB problem, when you moved the DB did it have the same settings in both?...

[nhaack]

Doesn't have to be a DB problem ... (though could well be)... an example:

I imported a UTF8 encoded table with 3rd party data into my CMS. I got encoding problems on the front-end as the script I used to access the DB was improperly encoded.

Here are some common sources of conflict I encountered with encoding:

1) Own scripts improperly encoding
2) Core files modified with editor not set th UTF8 (changed files were saved in wrong encoding)
3) On DB roll-back encoding for import was improperly set (mySQL was not explicitly set to utf8)
4) Encoding settings not stated in template
5) Wrong use of uf8_encode and utf8_decode in PHP

Probably these can help you to nail down the problem

What does your DB say? What encoding is it using?

I use the string "Iñtërnâtiônàližætiøn" to check for proper encoding. What happens with this string in regular content?

Best
Nils


edit:
however, the string mentioned above only covers Latin-1 range... if you want to check for double byte character-support, check this string "Ādam", the first character is U+0100 (or copy paste some Kanji from Google Japan).

not a real solution I know... but may be helpful for future testing.