RE: utf8 in QB

Taras, 

> So the client is the piece of code that sits on the opposite 
> side of the TCP/IP connection (opposite to the server) and 
> communicates with the server?

Yes. It's the piece of code that directly talks to the server.

> So, if I write mysql_query('select * from blah*') in my PHP 
> program, the PHP program itself is not the client, but merely 
> is instructing the (PHP version?) mysql client to tell the server to
execute the statement?

Yes. PHP just uses the mysql client lib (both mysql and mysqli).
 
> So when I type in statements into the mysql command line 
> client, I myself am not the client, but I'm telling the 
> client to execute statements for me (kind of like in the 
> above example the PHP not being the client, but the PHP 
> telling the client to do work)?

Also yes. The mysql.exe application (on Windows) is just a little
commandline tool that uses the client DLL to communicate to the server.
 
> Is the character_set_client the encoding that is coming *out* 
> of the client and into the connection, and the 
> character_set_connection the encoding that is coming *out* of 
> the connection and into the server? 

Please read this page:
http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html. It explains
that very well.

>What would happen if I 
> inputted a UCS-2 file into the command line client and set 
> character_set_client to be UTF8, would the client have to 
> translate into UTF8?
> 
> |FILE|----ucs2---->|command line client|----utf8---->|connection|

This requires that the CLI knows the encoding of the file.

> If this is the case, how does the command line client know 
> the encoding of the input?

It does not. This problem adds another level of complexity. You can tell the
client which default encoding it should use for interaction with the user
(and also files). See here:
http://dev.mysql.com/doc/refman/5.0/en/program-options.html. 

QB always uses UTF-8 for that (it simply makes things easier to handle),
although it is possible to specify the ANSI encoding for a script file.
However this has other problems, mainly because the ANSI encoding uses the
same range of byte values to encode various languages/characters, depending
on which code page you use to encode it (on my private homepage at
http://www.soft-gems.net/UnicodeLibrary.php you can find more info about the
use of Unicode and ANSI (...code pages), particularly this link might be
useful in this context: http://czyborra.com/charsets/codepages.html). 

Since the code page used to encode the file is not stored in the file every
reader must do some guessing (this is one reason why ANSI is not recommended
anymore) or ask the user about it if it allows to change this. Usually the
reader assumes the current system locale is what was used to create the file
(an assumption which is no longer safe with today's document exchanges,
internet, international communication etc.). ANSI totally fails if more than
one language is used in the same document. Only special tricks can help
then, like in Windows resource scripts (*.rc files) which start with default
encoding (that of the system) and allow to specify another code page
anywhere in the file. The reader has then to take care to adjust its decoder
accordingly.  But I stray from the subject...

> How does character_set_connection come into play? What is 
> it's role? The manual isn't very clear..

Hmm, the link above explains this option quite well. The differentiation
between client and connection charset is mainly used to support client apps
that have difficulties to use a UI code page that fits well to a server
charset. Usually, both are set to the same value (SET NAMES does this by the
way). An example for its use would be if your client does (for whatever
reason) only support a fixed code page but you need for your work to compare
values according to a specifc other charset/collation set. Then you let the
client charset be whatever it needs and change the connection charset to the
other charset/collation. As I said, it's a very special application.
 
> Is the command line client essentially the same client 
> (Windows DLLs) that QB uses?

Basically yes, however we have an own copy of libmysql.dll in our tools
folder. This is mainly to have a reliable set of functions we need without
disrupting the the mysql client or other apps that use it.

Mike
--
Mike Lischke, Software Engineer GUI
MySQL AB, www.mysql.com


-- 
MySQL GUI Tools Mailing List
For list archives: http://lists.mysql.com/gui-tools
To unsubscribe:    http://lists.mysql.com/[email protected]