17452 Posts in 4473 Topics by 1971 members
|Go to End|
17 September 2008 at 8:45pm Last edited: 17 September 2008 8:46pm
Hello Silverstripe Community and developers,
before I start I have to say that I'm without any knowledge in the different Charsets which makes me kind of crazy solving the following problem. For my Silverstripe Site I imported a lot of Data from a MSSQL Database into the Silverstripe MySQL Database, each record saved into a DataObject-Class. The data I used has alot of German umlaute and are saved in the ISO-8859-1 Charset. As you know Silverstripe uses the UTF-8 Charset as default for showing the pages. That makes my umlaute shown as question marks (white q.m. on black ground). To avoid this I changed the used Charset from UTF-8 to ISO-8859-1 and everything is shown properly, except of the Page Titles I entered in the CMS. A little example:
In phpMyAdmin, the german umlaut "ÃƒÂ¶", after saving it with the CMS, is shown as "ÃƒÆ’Ã‚Â¶", even the phpMyAdmin sites are shown with UTF-8. Changing the Charset with my browser to ISO-8859-1 won't help obviously, the letter is shown as "ÃƒÆ’Ã†â€™Ãƒâ€šÃ‚Â¶". Funnily enough, my imported data is shown correctly when I see the phpMyAdmin pages in UTF-8 and wrong when I set it to ISO-8859-1. Exactly vice-versa as the presentation of my Silverstripe site.
To see the letter shown properly in my Silverstripe site, I need to use the UTF-8 Charset. The only problem is, if I use UTF-8 my imported Data is shown wrong. You see, it's kind of like a vicious circle, and I have absolutely no idea how to get out of it.
I really hope someone is able to help me with that, I'm trying to find a solution for days now, and actually I have not even a clue why this problem really occurs.
Please help me with that one, I'm starting to go insane, thanks in advance.
25 September 2008 at 11:41pm
i know how you feel, character conversions drive me crazy ;) thats why we consistently use utf-8 - as all used tools (php,mysql,browser) deal with utf-8 reasonably well, i think its a fair choice not to go through the major PITA to support custom charactersets.
i would suggest that you convert your data to utf8 during import.
alternatively you could export the data at utf8 in the first place.
|Go to Top|