after todays database errors,

http://climateapps2.oucs.ox.ac.uk/cpdnboinc/team_display.php?teamid=188

Добро пожаловать в Украинскую Команду Распределенных Вычислений!

Заходите на наш командный форум по проекту ClimatePrediction.net !

---

The CPDN programmers have been informed. Thank you for reporting this problem.

---

Cpdn news

Thanks, this should now be fixed:

Добро пожаловать в Украинскую Команду Распределенных Вычислений!

If any more examples of incorrect encoding appear please let me know.

Milo, I\'m afraid that profiles still don\'t all display properly. For example, Chinese characters display in this member\'s name here but not in his profile.

Similarly with a Russian member here in the list and in his profile

---

Cpdn news

Milo, I\'m afraid that profiles still don\'t all display properly.

To fix the last one I had to track down the particular table/column at fault and convert from latin1->binary->utf8. Apparently there were around 500 records there that needed converting. I\'ll track down and convert these ones as well.

Edit: Hmmm... It seems that this Russian one is corrupted by some other means, although the Chinese was convertable.

To fix the last one I had to track down the particular table/column at fault and convert from latin1->binary->utf8. Apparently there were around 500 records there that needed converting. I\'ll track down and convert these ones as well.
Edit: Hmmm... It seems that this Russian one is corrupted by some other means, although the Chinese was convertable.

Milo:
UTF-8 should work. Did you see this article? I hope it helps you.
http://www.oreillynet.com/onlamp/blog/2006/01/turning_mysql_data_in_latin1_t.html

UTF-8 should work. Did you see this article? I hope it helps you.
http://www.oreillynet.com/onlamp/blog/2006/01/turning_mysql_data_in_latin1_t.html

There\'s a problem with that article\'s method - it would involve another complete dump of the database which would require shutting it down overnight. So, if I can find a way to change the few remaining entries without doing that it would be greatly preferable. I haven\'t found it yet.

There\'s a problem with that article\'s method - it would involve another complete dump of the database which would require shutting it down overnight. So, if I can find a way to change the few remaining entries without doing that it would be greatly preferable. I haven\'t found it yet.

I think that it would be crazy to dump the DB again. The only way I would know how to fix them would be to have the old database up (isolated of course), and then re-convert the affected records individually with a custom SQL script.

Hopefully, if the moderators can find a good sample of the people affected, you\'ll be able to find a perfect WHERE clause to identify them. Then, hopefully, you\'ll be able to write One Script To fix Them All.

There were some additional user comments on that article, such as configuration for the php.ini, httpd.conf, etc that would be good to verify, so this shouldn\'t be an issue going forward.

I\'m sure this was many, many hours to pull off an encoding change, so I congratulate you on only having these minor issues.

It also depends on the web browser encoding someone uses, for example some of those links work if I select \"Cyrillic - Windows\" on my Mac Safari browser, but the \"Default\" encoding (unicode I guess) it is gibberish.

It also depends on the web browser encoding someone uses, for example some of those links work if I select \"Cyrillic - Windows\" on my Mac Safari browser, but the \"Default\" encoding (unicode I guess) it is gibberish.

Indeed - it looks like some entries have gone in in CP1251 (or others) and been re-encoded into latin1 by MySQL. The ideal solution would be to track these down and convert them individually, which I have done for some entries. The ones that remain are ones that I have not been able to successfully convert yet. The particular Russian one discussed here seems resistant to being corrected within the database, although it may be viewed in the browser as you describe.