Starting from version 6.0 SQLyog offers complete support for all (single-byte and multi-byte unicode and non-unicode) character sets supported by the MySQL server.

Also starting from version 6.0 SQLyog uses UTF8 internally. Whenever communicating with MySQL SQLyog and whenever possible SQLyog will let the MySQL server do any character conversion from how data are stored to UTF8. Whenever possible means when the MySQL server is version 4.1 or higher.

And whenever communicating with Windows all strings are converted to the native Windows Unicode implementation (UTF16) from UTF8 (or opposite)

set NAMES = {your chosen character set};

{your chosen character set} will - when connected to MySQL 4.1 or higher be UTF8 for both the 'utf8' and the '[default]' selection in the connections manager (and that even if server default charset is not UTF8). You can force another character set to be used if you need for some special purpose (but that would be very rare!). When working with MySQL 4.1 and higher, users will normally not need to bother. Everything is handled and communicated transparently by the MySQL server and SQLyog.

This will work for all types of connections (direct, SSH and HTTP) connections.

When connecting to MySQL, the MySQL server will transform between the character set used for storing of data (whether Unicode or not) and UTF8 (or any other specified character set of the client) 'on the fly'.

Also most users connecting to a MySQL server with a version lower than 4.1 will not need to bother about character sets. In this situation the MySQL server cannot do the conversion as sit does not support UTF8. However SQLyog will then do the conversion.

If you want to work with localized data from a MySQL 4.0 or 3.23 server using characters that differ from the server default, you must select the charset in the connections dialogue correspondingly. This is the only way to tell SQLyog and Windows that this is data where strings use a special encoding and must be given a special treatment when converted to SQLyog UTF8 and Windows UTF16 Unicode.

To take full advantage of the Unicode abilities of SQLyog you should (if you need to use unicode character sets and non-unicode character sets not based on latin) install support for Far-Eastern (Chinese, Japanese and Korean) languages and for 'complex scripts' (Arabic, Thai, Indic etc languages) in your Windows copy. this option is available from Control Panel... Regional and language settings.

You must of course also use fonts that have glyphs for the language that you want to use. Font settings in SQLyog is available from the menu .. tools .. preferences. And of course you will need use a keyboard with that language support too!

The attentive user may want to ask: Why use UTF8 internally and have all the trouble with the conversions to UTF16 when communicating with Windows. Converting between UCS2 and UTF16 would be much easier (actually for the subset of Unicode currently supported by MySQL they are identical!), so why not use UCS2 internally? Shortly the answer is that there are two many issues with the MySQL UCS2 implementation on the client side.

A concluding note on the term 'Character Set'. What in MySQL terminology in named a Unicode 'Character Set' is really an encoding. The Character Set itself is Unicode - encodings are for instance UTF-8 and UCS-2 (or utf8 and ucs2 in MySQL terminology). The MySQL terminology on Unicode is a non-standard terminology. If you want to study this the Wikipedia has some good articles. You may start here.