Page 1 of 1

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

Posted: Wed Dec 31, 2008 10:45 am
by 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 ! :-o

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...

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

Posted: Wed Dec 31, 2008 11:06 am
by svergeylen
I've uninstall and re-install the news module but the problem is still there.... :-( Any idea ??? Thanks !

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

Posted: Thu Jan 01, 2009 2:40 am
by Dr.CSS
New install with old content, how is that possible?...

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

Posted: Fri Jan 02, 2009 9:21 am
by 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 !

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

Posted: Fri Jan 02, 2009 7:20 pm
by Dr.CSS
Sounds like a DB problem, when you moved the DB did it have the same settings in both?...

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

Posted: Fri Jan 02, 2009 10:22 pm
by 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.