Re: utf8 in QB

Hi Mike,


Depending on the platform, different
> transformation formats are used. On Windows QB uses UTF-16 for the UI and
> certain parts of the library. Communication with the server and shared
> library code is done using UTF-8.


Does that mean that when typing queries into the edit pane, the characters
are stored somewhere in memory in UTF-16?

This is what I understand of the parameters pertaining to character sets:

character_set_database: the encoding that is used to store the data in the
database
character_set_results: the encoding used to send the results back to the
client
character_set_connection: the encoding used to send the client's commands
over the connection to the server
character_set_client: the encoding the client is using.

The last one is the one I'm having confusion with. The way I understand this
variable's role is that if a file for example, saved in UCS-2, was piped
into the mysql command line client, this variable would have to be set to
indicate the encoding to mysql. If the connection variable was set as UTF-8,
then a conversion from UCS-2 to UTF-8 would have to take place before
sending the command to mysql.

So the way I view (maybe incorrectly) QB is that the data displayed in the
edit pane has an encoding, and this encoding is indicated by
character_set_client. The client here is query browser. When I press
ctrl-enter this data is transcoded to character_set_connection (if
required), and sent to the DB.

So if character_set_client is set to UTF-8 (which it is in QB), this implies
to me that the client, ie: the edit pane, is sending data to the connection
in UTF-8 encoding. From what you've said it seems like this is UTF-16, which
would not agree with anything that I've thought so far ;). Is my
interpretation correct, or am I going wrong somewhere?


> Having said that, why can I type in characters using MS
> > pinyin editor into query editing area at the top, and even
> > though the characters in the editing pane are stuffed, they
> > get inserted correctly (checked by using HEX())?
>
> I don't understand your question. Why can you do that? Because we have it
> implemented so. That's why you can do that. If your characters are too
> close
> together (which is likely with scripts that have wide [socalled full
> width]
> characters, like chinese) you can set a bigger spacing between the letters
> using the application's option. However note that half width characters as
> well as other scripts like latin1, russian, greek etc. will have a bit too
> wide spacing then. The editors in QB use fixed width fonts, hence all
> characters have the same width, regardless of their actual glyph.


It was a problem with the font - I mustn't have been using a unicode font.


> Although they get inserted correctly, when I execute select
> > *, the chinese characters display correctly but they are
> > rotated to the left 90 degrees (I'm using Arial MS Unicode
> > font) - does anyone else have this problem?
>
> That is strange and I can only assume that you've picked the wrong font.
> Note that chinese originally is a vertical writing system so there were
> attempts to allow vertical writing also on computers. For this to work
> special fonts are installed which usually appear with a leading @ sign.
> These fonts have rotated glyphs.


You were correct. Any font that I chose with a leading @ sign appeared
rotated in both the code and the results sections. Picking a font without an
@ sign resulted in font that was not rotated.

Taras