Change character set of mysql server on webmin

Question

I'm running MySQL server, started from Webmin, and I have a problem with charset. I have changed and checked a charset of database, tables and fields to utf16 and collation to utf16_bin. But here is the problem, when I add new rows in table using webmin and use some special characters like č, ć, š, these characters are shown correctly in table, but when I read it with my backend I get some weird characters. I do not have this problem when I tested it locally with phpmyadmin. More than 6 hours I change configuration of everything, but it does not work. Is there some character set of mysql server, so maybe it is problem, I also tried to change it using this: http://allabout2know.blogspot.com/2013/11/webmin-change-default-charset-encoding.html

But I get an error message, only when I want to change to UTF16 or UTF32: The MySQL client program /usr/bin/mysql does not accept passwords passed using the MYSQL_PWD environment variable. To ensure that Webmin is able to fully communicate with MySQL, this option should be turned off on the module configuration page. Alternately, you can remove any password set in the root user's .my.cnf file.

So, please help, this really frustrate me. Thanks in advance. I'm not sure where actually the problem is...

Answer 1

Short answer: Don't use UTF16 or UTF32. If you have some reason to use either of them, please explain. I don't remember hearing of anyone using them.

Please provide SHOW CREATE TABLE fok at least one table, so I can see that in action.

The preferred encoding is UTF-8 as the outside world's calls it. MySQL's name is utf8mb4.

This may help with "weird characters": Trouble with UTF-8 characters; what I see is not what I stored , though it is mostly talking about the mixing up of latin1 and utf8mb4.

In theory, MySQL will gracefully handle character sets utf16 and utf32.

Be aware that the encoding in the client does not have to be the same as in the server.

The connection parameters specify the client's encoding; the table definitions specify the server's encoding. Characters are transcoded as needed.

If possible, please provide a short hex dump that involves any of č, ć, š in whatever context is handy.

(Sorry, I see the issue with the password needing to be sent before the charset can be established, but I don't have an answer.)