Display Problems in utf-8 : part of text are displayed as latin1 into encoded page utf-8.

• Error

phenomenon :

On a particular configuration, not identified yet, pieces of text are displayed as latin1 in a pagecode identified as utf-8 encoded.

test and facts :

1. From a database well encoded utf8 and used with 5.0 on windows : export sql and look at encoding in hexa editor.
2. Create from sql file two new database one on a windows installation, the other on Linux (OVH)
3. Copy 5.3 to both installations.
4. Run install and uses upgrade and convert
5. Export databases to sql
6. Compare the sql file : identical main data
7. On loading the same page from the two servers we obtain two different displays :
   1. - Locally the delivered html page is clean and well displayed (sourcepage save and edited in hexa and firebug)
   2. - From the OVH server all the data from database are converted to latin1(where ?, probably served by mysql converted to latin1) while the text form system (language file) are displayed in utf8.
8. __ - The behaviour of the OVH installation is completely erratic (because the data are served converted and all indexes request and keys with accents become wrong)
9. The Administrator general display says : "database error"__

question :

Why the data served to tikiwiki, with exactly the same parameters and data, are right on my server and converted into latin1 on the OVH configuration ?
I have not yet searched into the product, and I don't know, previously, how tikiwiki holds the encoding.

I think that who have developed these piece of product is able to tell me where the encoding to serve by mysql to the product is defined and which parameter can have an effect on the linux server and not on the one on windows.

Partial éléments of solution :

1- if $tiki-api is not set into local.php the default MYSQL (mysql.ini of the server) connection parameters are used and tiki-db-pdo is not run at init session. So as on the concerned server the default CHARSET was latin1 the installation was unavailable.
The fact that the local.php parameter $client_charset='utf8' has no effect if $api_tiki='pdo'; is not set.
This is a not consistency problem.

2- It remain some curious problem : Found lack of resources not bug, solved

1. into listpages the categories are still displayed as latin1
2. some option can't be run (button without effect) even by administrator. This comes from wrong commands (probably caused by latin1 values sent to ajax)

Remark : with all latin1 database request answers nothing can function.

3-I developed a module which checks (partially) and displays some system variables and those of mysql with "show variables" (as a "listpages" with warning messages). Some variables-flags have been set into the "major key init functions" so, if the flags- vars and the system-vars generated are not consistent, the module is launched with warning messages.
I think to have began, with this module, to put apart, the check of all parameters and the consistency from the system behavior at launch

Solution for 5.3 :

If the mysql server is not set to utf8 for all transactions, the local.php must be checked :
1- Set $api_tiki='pdo';
2- Set $client_charset='utf8';

This bug has been demonstrated on show2.tiki.org

Please demonstrate your bug on show2.tiki.org

This bug has been demonstrated on show.tikiwiki.org

Please demonstrate your bug on show.tikiwiki.org