Hello:

I think Horde is doing the work just fine. You can check it by 
manually echoing the result of, for example, convertToDriver method 
from kronolith/lib/Driver/sql.php. You'll see that the text is 
converted just fine.

What seems to be happening wrong is, for some reason I don't know, 
mysql connection always defaults it's charset to 'latin1' (even if the 
charset is set to utf8 in my.cnf in charset_set_server and 
default_charset_set) and then the text with "special" characters, 
which was converted fine at the php layer, is wrongly recorded into 
the database as 'latin1', and thus the problem of unusable data saved.

I managed to solve this issue by adding:

[mysqld]
init_connect="SET NAMES 'utf8'"

and restarting mysqld. Now the text is just the same on horde and on 
the db, which makes it good to be used from other tools (import/export 
etc.).

Also, the mysql_set_charset function only works for PHP 5 >= 5.2.3. So 
the workaround of editing PEAR's DB may no apply to all installs.

See if the init_connect option in my.cnf works for you. Hope it helps.

No it's you fault because you doesn't set the charset so it's use the 
unchangeable(so far) charset...

The PEAR code we tallk about has changed and you didn't do the 
apropriet change of your code.

PEAR does not set character set on mysql connect anymore (because php 
does not set character set on mysql database connect) so must you...

It's not about what character set my database is using because it's 
about what character set is using the client side. The mysql module in 
php which is default latin1 (UNCHANGEABLE DEFAULT).
It's on application to change it.
I'm telling you that the code that did this right before is doing it 
wrong now because it relays on PEAR functionality that isn't there 
anymore.

Understand ?

And this make this problem a Horde BUG!

1. This code is in the PEAR DB package which has nothing to do with Horde.
2. The conversion is done to the charset that you configured in your 
database settings. If this doesn't match the charset that your 
database is actually using, that's your fault.

I thought about it and I can say NO YOU DO NOT CONVERT ANYTHING!
The data in database are stored as 8bit representation of multi-byte encoding.
If there was any conversion from mysql  default encoding (latin1, 
which is not able to hold multi-byte characters) to some other 
encoding. It would not obviously work for multi-byte characters.

Horde simply stores utf-8 (if sql-charset is utf8) byte stream in 
mysql as latin1
and the same way retrieves it back.

This bug in combination with php inability to change 
default-character-set for mysql. May be considered not beeing a bug, 
but it is one.
And when php becomes able to set mysql default charset Horde brokes.

there should be something like "escrzya" with diacritics

But this way data in database are utf-8 overconverted from latin1 to 
utf8. So instead of "ěščřžýáíéžřč" there is 
"žřčšěščřžýáí"
1. if any other application uses this it is imposible to convert 
"žřčšěščřžýáí" to "ěščřžýáíéžřč" 
because there are ilegal latin1 characters.
2. backup, restoring and moving database is made problematic

I solved this with

         if ($dsn['charset']) {
             if (!@mysql_set_charset($dsn['charset'])) {
                 return $this->mysqlRaiseError();
             }
         }

added to pear/DB/mysql.php connect function after database conect

Which made PEAR function the old way

But this in not a permanent solution. The next "pear upgrade DB" will 
broke it again...

Doesn't matter because we convert the data to the correct charset anyway.

PEAR function DB::connect ignores $dsn['charset'] for mysql.
Database charset defaults to latin1 whatever is set in 
$conf['sql']['charset'].