[peterlaursen]

@ritesh

I think you are mistaken to one point! It is about the native Windows UNICODE implementation. Win NT/2K/XP does not use UCS-2 but UTF-16 internally. The help file on my system reads (in Danish):

Quote

En tegnkodningsstandard udviklet af Unicode Consortium, der kan gengive næsten alle skriftssprog i verden. De tilgængelige tegn i Unicode kan repræsenteres i forskellige formater, herunder UTF-8, UTF-16 og UTF-32. I de fleste Windows-grænseflader benyttes UTF-16.

Last paragraph translates to 'In most Windows interfaces UTF-16 is used.' I don't know about the 'unicode layer' in Win98SE. It could be UCS-2. But UCS-2 is mostly considered depreciated.

Read: http://en.wikipedia.org/wiki/UTF-16:

Quote

UTF-16 is the native internal representation of text in the Microsoft Windows NT, Windows CE, Qualcomm BREW, and Symbian operating systems; the Java and .NET bytecode environments; Mac OS X's Cocoa and Core Foundation frameworks; and the Qt cross-platform graphical widget toolkit.

I don't know if it makes any difference as far as SQLyog 5.2 goes!

[Nick]

Just to let you know that 5.1 Beta 6 seems to have sorted all the issues out and I can now do Turkish perfectly both locally and via http tunnelling.

Thanks very much for working to fix the problems I was having.

Nick

[Ritesh]

BETA 7 will be even better as we have implemented user defined CHARSET selection in HTTP Tunneling. I think we are now done with one byte data handling. v5.2 will have complete support for all kinds of languages.

[peterlaursen]

 I think we are now done with one byte data handling.

1) I think that as long with wont need to display and be able to read and manipulate from GUI data we are done with all data if MySQL is >= 4.1. SET NAMES = utf8 converts data to a stream of bytes that SQLyog/SJA can handle internally. That goes for copy, export/backup, sync etc. But not for display and for keyboard manipulation.

2) But we can also handle all data (even with the GUI - display and keyboard) from multibyte-storage (possibly mixed with single-byte storage) as long as all characters used are convertible to one single byte charset. That is: if data are stored as utf8, ucs2 etc., SET NAMES = latin1/2/5/7 etc will load them into the client in a readable and manipulate-able way as long as this client has support for the Windows parallel for the charset that was specified with SET NAMES - and as long as this SET NAMES makes sense with the data.

But we cannot handle multibyte data where some characters must be converted to different one-byte character set (some latin2 and others to latin5 for instance) to be presented as single-byte. As SQLyog uses one byte internally there is no way to have a Polish l-with-an-accent and a Turkish i-without-a-dot at the same time! Unless there is some strange single byte charset supported by MySQL as well as Windows that has both.

And of course we cannot either handle multibyte characters with the GUI that cannot be represented in a single-byte charset. But we can copy, backup/restore and sync etc if server allows for SET NAMES = utf8.


@ritesh - actually I'd like your comment on whether you agree to this ...

[peterlaursen]

This posting is only additional info for those interested!

I may not be 100% correct what I wrote last. I overlooked one link in the chain, and that is XML-encoding! So for conversion of characters from a multibyte-storage to a single byte representation in the SQLyog workspace the XML encoding scheme must support those characters where XML-encoding applies (that is SJA operations). However it should still work as I described above it should still work with most latin-based charset and even cyrillic. But Arabic, Hebrew, Greek, Armenian etc. ... well, I really don't know!

For those functionalities that do not use XML representation of data (export/import, copy to other host) I still believe that is is correct what I wrote.