Hmm. Have you tried "SET NAMES charset" in your application? Also many (ruby) ORM frameworks support 'encoding' option that will change the default encoding.

Thank you for your answer Michal.

Actually I do not use any framework or any ORM for my DB... my application is written from scratch in Java but I found a solution for UTF8 encoding.
I changed the connection parameters for DriveManager, it was 

DriverManager.getConnection("jdbc:mysql://mySql_IP:3306/myDatabase", "someUsername", "somePassword");

and now I have put ?useUnicode=true&characterEncoding=UTF-8 in the end of the first parameter so it became:

DriverManager.getConnection("jdbc:mysql://mySql_IP:3306/myDatabase?useUnicode=true&characterEncoding=UTF-8", "someUsername", "somePassword");

Now it seems to work fine!
But I think it might be good if we could change the character-set variables for MySQL just like OPENSHIFT_MYSQL_LOWER_CASE_TABLE_NAMES, sometimes it's easier to change these variables than change things in the code.

These are potentially treacherous waters to tread; if the character set values (and a related variable, 'collation-server') are incorrect, MySQL server fails to start. And it could be difficult to troubleshoot.

We would like to avoid this situations altogether if we can.

As you noted, these values are dynamic, so that configuration via my.cnf is not necessary. You can use the driver to set it (as you showed above), or issue a MySQL command equivalent, like so:

mysql> SET GLOBAL character_set_server=utf8, collation_server=utf8_general_ci;                                                                                                    
Query OK, 0 rows affected (0.00 sec)

Do you agree?

(In reply to Hiro Asari from comment #3)
> These are potentially treacherous waters to tread; if the character set
> values (and a related variable, 'collation-server') are incorrect, MySQL
> server fails to start. And it could be difficult to troubleshoot.
> 
> We would like to avoid this situations altogether if we can.
> 
> As you noted, these values are dynamic, so that configuration via my.cnf is
> not necessary. You can use the driver to set it (as you showed above), or
> issue a MySQL command equivalent, like so:
> 
> mysql> SET GLOBAL character_set_server=utf8,
> collation_server=utf8_general_ci;                                           
> 
> Query OK, 0 rows affected (0.00 sec)
> 
> Do you agree?

Thank you for your explanation, yes these two solutions (DriveManager and SET GLOBAL values for mysql) worked perfectly for me.

In that case, then, I am closing this ticket as WONTFIX.

Thank you.

*** Bug 1022964 has been marked as a duplicate of this bug. ***

Well! Just one question please!
logging in ssh mode and executing the MySQL command :
mysql> SET GLOBAL character_set_server=utf8, collation_server=utf8_general_ci; 
does indeed change the server character set and collation to UTF8, yet does the change persist!
Whenever there is a git push, a cartridge upgrade or a cartridge startup, the charset is back to latin.

Does it mean that I have to issue the above MySQL command each time I git push?

Thanks in advance.

In essence, yes, you'd need to run that command on each MySQL startup.

However, you can automate this with the action hook (say, 'post_start_mysql' or 'deploy'):

#!/bin/bash

/usr/bin/mysql -h $OPENSHIFT_MYSQL_DB_HOST -u $OPENSHIFT_MYSQL_DB_USERNAME \
 --password=$OPENSHIFT_MYSQL_DB_PASSWORD -P $OPENSHIFT_MYSQL_DB_PORT \
 -e 'SET GLOBAL character_set_server=utf8, collation_server=utf8_general_ci;'

See http://openshift.github.io/documentation/oo_user_guide.html#action-hooks for more details on action hooks.

Sorry for being annoying.
Afte sevral checks, it seems the above command is not useful when using a Java EE application that connects to MySQL through a DataSource.

At first I tried appending the charset variables values in my.cnf :

pathtofile="/var/lib/openshift/xxxxxxxxxxxxxxxxxxxxxxxx/mysql/conf/my.cnf"
sed -i '/mysqld]/ a\collation-server=utf8_general_ci' $pathtofile
sed -i '/mysqld]/ a\character-set-server=utf8' $pathtofile

but since, it was protected, permission to write was denied of course, whether using deploy or post-deploy hooks.

Adding phpmyadmin 4.0 cartridge and setting global charset values to utf8, did not help neither.

At last, the solution was inspired from the previous user (KonstantinAn):

I added to property nodes to persistence.xml :

<property name="hibernate.connection.useUnicode" value="true" />
            <property name="hibernate.connection.characterEncoding" value="UTF-8" />  

and under: MY_APPLICATION/.openshift/config/standalone.xml:

 <datasource jndi-name="java:jboss/datasources/MysqlDS" pool-name="MysqlDS" use-java-context="true" use-ccm="true">
                    <connection-url>jdbc:mysql://xxx.x.xxx.xxx:xxxx/databaseName?useUnicode=yes&amp;characterEncoding=UTF-8</connection-url>
                    <driver>mysql</driver>
                    <pool>
                        <flush-strategy>IdleConnections</flush-strategy>
                    </pool>
                    <security>
                        <user-name>myDBusername</user-name>
                        <password>myDBpassword</password>
                    </security>
                    <validation>
                        <check-valid-connection-sql>SELECT 1</check-valid-connection-sql>
                        <background-validation>true</background-validation>
                    </validation>
                </datasource>

Restarting the application or performing a git push does not affect charset anymore.

If you believe this is a solution, then it should be mentioned in OpenShift Documentation (Java EE profile) that the user is responsible for forcing the use of a specific CHARSET like UTF8.

Thanks in advance.

Thank you for your input. I created Bug 1023944 for documenting this.