MySQL 5.0 FAQ: MySQL Chinese, Japanese, and Korean Character Sets
2898
We encourage the use of the newer
mysqli
extension, rather than
mysql
. Using
mysqli
, the
previous example could be rewritten as shown here:
<?php
$link = new mysqli($host, $usr, $pwd, $db);
if( mysqli_connect_errno() )
{
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
}
$link->query("SET NAMES 'utf8'");
?>
Another issue often encountered in PHP applications has to do with assumptions made by the
browser. Sometimes adding or changing a
<meta>
tag suffices to correct the problem: for example,
to insure that the user agent interprets page content as
UTF-8
, you should include
<meta http-
equiv="Content-Type" content="text/html; charset=utf-8">
in the
<head>
of the
HTML page.
If you are using Connector/J, see
Section 20.3.5.4, “Using Character Sets and Unicode”
.
B.11.11: I've upgraded to MySQL 5.0. How can I revert to behavior like that in MySQL 4.0 with
regard to character sets?
In MySQL Version 4.0, there was a single “global” character set for both server and client, and the
decision as to which character to use was made by the server administrator. This changed starting with
MySQL Version 4.1. What happens now is a “handshake”, as described in
Section 10.1.4, “Connection
Character Sets and Collations”
:
When a client connects, it sends to the server the name of the character set that it
wants to use. The server uses the name to set the
character_set_client
[441]
,
character_set_results
[443]
, and
character_set_connection
[442]
system
variables. In effect, the server performs a
SET NAMES
operation using the character
set name.
The effect of this is that you cannot control the client character set by starting
mysqld
with
--
character-set-server=utf8
[403]
. However, some of our Asian customers have said that they
prefer the MySQL 4.0 behavior. To make it possible to retain this behavior, we added a
mysqld
switch,
--character-set-client-handshake
[402]
, which can be turned off with
--skip-character-
set-client-handshake
[402]
. If you start
mysqld
with
--skip-character-set-client-
handshake
[402]
, then, when a client connects, it sends to the server the name of the character set
that it wants to use—however, the server ignores this request from the client.
By way of example, suppose that your favorite server character set is
latin1
(unlikely in a CJK area,
but this is the default value). Suppose further that the client uses
utf8
because this is what the client's
operating system supports. Now, start the server with
latin1
as its default character set:
mysqld --character-set-server=latin1
And then start the client with the default character set
utf8
:
mysql --default-character-set=utf8
The current settings can be seen by viewing the output of
SHOW VARIABLES
:
mysql>
SHOW VARIABLES LIKE 'char%';
+--------------------------+----------------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
Summary of Contents for 5.0
Page 1: ...MySQL 5 0 Reference Manual ...
Page 18: ...xviii ...
Page 60: ...40 ...
Page 396: ...376 ...
Page 578: ...558 ...
Page 636: ...616 ...
Page 844: ...824 ...
Page 1234: ...1214 ...
Page 1427: ...MySQL Proxy Scripting 1407 ...
Page 1734: ...1714 ...
Page 1752: ...1732 ...
Page 1783: ...Configuring Connector ODBC 1763 ...
Page 1793: ...Connector ODBC Examples 1773 ...
Page 1839: ...Connector Net Installation 1819 2 You must choose the type of installation to perform ...
Page 2850: ...2830 ...
Page 2854: ...2834 ...
Page 2928: ...2908 ...
Page 3000: ...2980 ...
Page 3122: ...3102 ...
Page 3126: ...3106 ...
Page 3174: ...3154 ...
Page 3232: ...3212 ...
