MySQL 5.6 リファレンスマニュアル  /  ...  /  接続文字セットおよび照合順序

10.1.4 接続文字セットおよび照合順序

複数の文字セットおよび照合順序のシステム変数は、サーバーとのクライアントの通信に関係しています。これらのいくつかは、これまでのセクションですでに説明されています。

  • サーバー文字セットおよび照合順序は、character_set_server および collation_server システム変数の値です。

  • デフォルトのデータベースの文字セットおよび照合順序は、character_set_database および collation_database システム変数の値です。

その他の文字セットおよび照合順序システム変数は、クライアントとサーバー間の接続のトラフィックの処理に関わっています。どのクライアントも接続関連の文字セットおよび照合順序システム変数を持っています。

接続は、サーバーに接続するときに作成するものです。クライアントは接続を介して、SQL ステートメント (クエリーなど) をサーバーに送信します。サーバーは接続を介して、結果セットやエラーメッセージなどの応答をクライアントに送信します。これによって、次のようなクライアント接続を扱う文字セットおよび照合順序に関する疑問が生じますが、これらはシステム変数の点から回答できます。

  • クライアントから送信されるときに、ステートメントはどの文字セットで送信されますか。

    サーバーは、character_set_client システム変数値を、クライアントが送信するステートメントの文字セットにします。

  • ステートメントを受信したあとで、サーバーはこれをどの文字セットに変換しますか。

    これには、サーバーは character_set_connection および collation_connection システム変数値を使用します。クライアントから送信されたステートメントは、character_set_client から character_set_connection に変換されます (_latin1_utf8 などのイントロデューサがある文字列リテラルを除きます)。collation_connection はリテラル文字列の比較で重要です。カラム値のある文字列の比較には、collation_connection は重要視されません。なぜなら、カラムには独自の照合順序があり、この照合順序が優先されるからです。

  • 結果セットまたはエラーメッセージをクライアントに返送する前に、サーバーはこれらをどの文字セットに変換しますか。

    character_set_results システム変数値は、サーバーがクライアントにクエリー結果を返信するときに使用する文字セットを示します。これには、カラム値などの結果データと、カラム名やエラーメッセージなどの結果メタデータが含まれます。

クライアントは、これらの変数の設定を微調整することも、デフォルトに従うこともできます (この場合は、このセクションの残りをスキップできます)。デフォルトを使用しない場合、サーバーへの接続ごとに文字設定を変更する必要があります。

2 つのステートメントは、接続関連の文字セット変数にグループとして影響します。

  • SET NAMES 'charset_name' [COLLATE 'collation_name']

    SET NAMES は、クライアントからサーバーへの SQL ステートメントの送信に使用される文字セットを示します。したがって、SET NAMES 'cp1251' は、このクライアントから今後受信するメッセージが文字セット cp1251 で送信されることを、サーバーに知らせます。また、クライアントに結果を返信するときにサーバーが使用する文字セットも指定します。(たとえば、SELECT ステートメントを使用する場合に、カラム値に使用する文字セットを指定します。)

    SET NAMES 'charset_name' ステートメントは次の 3 つのステートメントと同等です。

    SET character_set_client = charset_name;
    SET character_set_results = charset_name;
    SET character_set_connection = charset_name;
    

    character_set_connectioncharset_name に設定すると、collation_connection も暗黙的に charset_name のデフォルト照合順序に設定されます。この照合順序を明示的に設定する必要はありません。特定の照合順序を指定するには、オプションの COLLATE 句を使用します。

    SET NAMES 'charset_name' COLLATE 'collation_name'
    
  • SET CHARACTER SET charset_name

    SET CHARACTER SETSET NAMES に似ていますが、character_set_connectioncollation_connectioncharacter_set_databasecollation_database に設定します。SET CHARACTER SET charset_name ステートメントは次の 3 つのステートメントと同等です。

    SET character_set_client = charset_name;
    SET character_set_results = charset_name;
    SET collation_connection = @@collation_database;
    

    collation_connection を設定すると、character_set_connection も、関連付けられた文字セットに暗黙的に設定されます (SET character_set_connection = @@character_set_database の実行と同等です)。character_set_connection を明示的に設定する必要はありません。

注記

ucs2utf16utf16le、および utf32 をクライアント文字セットとして使用することはできません。つまり、これらは SET NAMES または SET CHARACTER SET には機能しません。

MySQL クライアントプログラム mysqlmysqladminmysqlcheckmysqlimport、および mysqlshow は、次のように、使用するデフォルトの文字セットを特定します。

  • ほかの情報が欠如している場合、プログラムは、コンパイル時のデフォルトの文字セット (通常は latin1) を使用します。

  • プログラムは、オペレーティングシステム設定 (たとえば、Unix システムでは LANGLC_ALL ローカル環境変数の値、Windows システムではコードページ設定) に基づいて、使用する文字セットを自動検出できます。ロケールが OS から利用できるシステムの場合、クライアントはコンパイル時のデフォルトを使用するのではなく、このロケールを使用してデフォルトの文字セットを設定します。たとえば、LANGru_RU.KOI8-R に設定すると、koi8r 文字セットが使用されます。したがってユーザーは、MySQL クライアントが使用できるように、自身の環境内でロケールを構成できます。

    OS 文字セットは、正確に一致するものがない場合は、もっとも近い MySQL 文字セットにマップされます。一致した文字セットをサポートしていない場合、クライアントはコンパイルイ時のデフォルトを使用します。たとえば、ucs2 は接続文字セットとしてはサポートされていません。

    C アプリケーションは、サーバーに接続する前に次のように mysql_options() を呼び出すことによって、OS 設定に基づいて文字セットの自動検出を使用できます。

    mysql_options(mysql,
                  MYSQL_SET_CHARSET_NAME,
                  MYSQL_AUTODETECT_CHARSET_NAME);
    
  • プログラムは --default-character-set オプションをサポートしており、ユーザーはこのオプションを使用すると文字セットを明示的に指定でき、クライアントがそれ以外のどのデフォルトを指定していても、それをオーバーライドできます。

クライアントはサーバーに接続するときに、使用する文字セットの名前を送信します。サーバーはこの名前を使用して、character_set_clientcharacter_set_results、および character_set_connection システム変数を設定します。実際には、サーバーは文字セット名を使用して SET NAMES 操作を実行します。

mysql クライアントの場合、デフォルトとは別の文字セットを使用するには、起動するたびに、SET NAMES を明示的に実行できます。より簡単に同じ結果を得るには、--default-character-set オプション設定を mysql コマンド行またはオプションファイルに追加します。たとえば、次のオプションファイル設定は、mysql を呼び出すたびに、koi8r に設定された 3 つの接続関連の文字セット変数を変更します。

[mysql]
default-character-set=koi8r

自動再接続を有効にして mysql クライアントを使用している場合は (推奨しません)、SET NAMES ではなく charset コマンドを使用することをお勧めします。例:

mysql> charset utf8
Charset changed

charset コマンドは、SET NAMES ステートメントを発行し、接続の切断後に再接続するときに mysql が使用するデフォルトの文字セットも変更します。

例: column1CHAR(5) CHARACTER SET latin2 として定義されているとします。SET NAMES または SET CHARACTER SET を指定しない場合、SELECT column1 FROM t に対して、サーバーは、接続時にクライアントが指定した文字セットを使用して、column1 のすべての値を送り返します。反対に、SET NAMES 'latin1' または SET CHARACTER SET latin1SELECT ステートメントを発行する前に指定した場合、サーバーは結果を返信する直前に、latin2 の値を latin1 に変換します。両方の文字セットに存在しない文字がある場合、変換の損失が大きくなる可能性があります。

サーバーに結果セットまたはエラーメッセージの変換を実行させない場合は、character_set_resultsNULL または binary に設定してください。

SET character_set_results = NULL;

接続に適用する文字セットおよび照合順序システム変数の値を確認するには、次のステートメントを使用してください。

SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';

MySQL アプリケーションを実行する環境も考慮する必要があります。セクション10.1.5「アプリケーションの文字セットおよび照合順序の構成」を参照してください。

文字セットおよびエラーメッセージの詳細は、セクション10.1.6「エラーメッセージの文字セット」を参照してください。


User Comments
  Posted by Peter Didenko on April 23, 2004
This example are usable for russian users who want to have windows-1251 encoding on the site and koi8-r encoding into the database:

set CHARACTER SET cp1251_koi8
  Posted by Hendri Hondorp on September 7, 2006
If you are wondering why -despite all UTF8 settings- you still don't get non-ASCII characters right, it might be the case that:
1. you are using mysqlimport to insert data from files with utf8 characters;
AND
2. you have created a Database with character set latin1 (this is the default!) and not with character set utf8.
3. You have created a Table with character set utf8.

Even if you use the --default-character-set=utf8 option for mysqlimport this doesn't work! Mysqlimport is only using the value of 'character_set_database' as character set and in this case it is 'latin1'.
  Posted by Yuri Tsarev on October 4, 2006
This example shows how to configure mysqld server to use pure utf8 for server's character set and collation instead of default latin1. This will help to correctly store non-latin character data in db (cyrillic сharacters for example and russian language in particularly).

Go to the [mysqld] section in my.cnf and add two strings:

collation_server=utf8_unicode_ci
character_set_server=utf8

You can also add

skip-character-set-client-handshake

to enforce using of utf8 encoding in db.

  Posted by Bruno Longo on February 8, 2007
I tried all the above hints but still couldn´t get it to work (using mySql and PHP 5 server)... ´till I found and tried also this:

add to the .htaccess file this single line:

AddDefaultCharset UTF-8

Still not sure why this was important to the whole, but now it works as planned! Thanks!
  Posted by Charly R on March 29, 2007
I've spent quite a lot of time trying to make MySQL 4.1 and PHP working with my tables in cp1251 charset.

Adding on my local PC the following line to the my.ini solved the problem but unfortunately I can't do the same on my hosting provider space
default-character-set=cp1251

So after trying quite a lot of combinations finally I've found that I need to add only one query set just after connecting to the database in my php script
mysql_query ('SET NAMES CP1251');

Please note if you run another query like
mysql_query ('SET CHARACTER SET CP1251');
just after first one it will reset character_set_connection option and all your symbols most likely will be converted to the question marks as it happens for me many times before.

  Posted by aaron wu on March 21, 2008
In my process of adjusting the charset variables to correctly display the Chinese characters,I found client and server not only interact with each other, but also interact with windows OS,although I don't know how and when. When I use java application to write Chinese characters in utf8 charset to the database, even if I set all charset variables to utf8, the characters can not display correctly. Only after I set some charset to gb2312, the standard national Chinese charset, the display is right. I guess that is because the default charset of Windows OS in Chinese version is gb2312, and in between the interaction of client and server, Windows also make some charset translations in the process.

Thus when you still fail to display the correct characters after trying various combinations of charset variables, try the code below:

SET NAMES the_default_charset_of_your_local_OS

Hope this can do some help!
  Posted by David Tonhofer on April 9, 2008
I have prepared a little hand-drawn diagram on this (while debugging problems with xplanner) which might be of some use. It's been scanned into a 850KB PDF:

http://public.m-plify.net/mysql/MySQL_Charset_Handling.pdf

  Posted by Eliram on August 6, 2008
Working in Windows environment, I had a problem submitting unicode data from ASP pages to the MySQL server while everything was set to utf8 .

It turns out the problem was that my ODBC driver was version 3.5.1 and that's what caused the problem. Installing version 5.1 solved the problem.

http://dev.mysql.com/downloads/connector/odbc/
  Posted by Rajesh K on June 30, 2011
Here is an update to the documentation taken from http://bugs.mysql.com/bug.php?id=35372

Updated the description for character_set_client:

The character set for statements that arrive from the client. The
session value of this variable is set using the character set
requested by the client when the client connects to the server. (Many
clients support a --default-character-set option to enable this
character set to be specified explicitly.) The global
value of the variable is used to set the session value in cases when
the client-requested value is unknown or not available, or the server
is configured to ignore client requests:

* The client is from a version of MySQL older than MySQL 4.1, and thus
does not request a character set.

* The client requests a character set not known to the server. For
example, a Japanese-enabled client requests sjis when connecting to a
server not configured with sjis support.

* mysqld was started with the --skip-character-set-client-handshake
option, which causes it to ignore client character set configuration.
This reproduces MySQL 4.0 behavior and is useful should you wish to
upgrade the server without upgrading all the clients.
Sign Up Login You must be logged in to post a comment.