CJK 文字セットのリストは、MySQL のバージョンによって異なることがあります。 たとえば、gb18030 文字セットは MySQL 5.7.4 より前はサポートされていません。 ただし、INFORMATION_SCHEMA.CHARACTER_SETS 表のすべてのエントリの DESCRIPTION カラムには適用可能な言語の名前が表示されるため、次のクエリーを使用して Unicode 以外のすべての CJK 文字セットの最新のリストを取得できます。

mysql> SELECT CHARACTER_SET_NAME, DESCRIPTION
       FROM INFORMATION_SCHEMA.CHARACTER_SETS
       WHERE DESCRIPTION LIKE '%Chin%'
       OR DESCRIPTION LIKE '%Japanese%'
       OR DESCRIPTION LIKE '%Korean%'
       ORDER BY CHARACTER_SET_NAME;
+--------------------+---------------------------------+
| CHARACTER_SET_NAME | DESCRIPTION                     |
+--------------------+---------------------------------+
| big5               | Big5 Traditional Chinese        |
| cp932              | SJIS for Windows Japanese       |
| eucjpms            | UJIS for Windows Japanese       |
| euckr              | EUC-KR Korean                   |
| gb18030            | China National Standard GB18030 |
| gb2312             | GB2312 Simplified Chinese       |
| gbk                | GBK Simplified Chinese          |
| sjis               | Shift-JIS Japanese              |
| ujis               | EUC-JP Japanese                 |
+--------------------+---------------------------------+

(詳細はセクション26.4「INFORMATION_SCHEMA CHARACTER_SETS テーブル」を参照してください。)

MySQL では、中国人民共和国で正式な GB (Guojia Biaozhun、国民標準または簡体字中国語) 文字セットの 3 つのバリアントがサポートされています: gb2312、gbk および (MySQL 5.7.4 の時点) gb18030。

gbk は gb2312 のスーパーセットであるため、ユーザーが gbk 文字を gb2312 に挿入しようとする場合があります。 ただし、最終的には、まれな中国語の文字を挿入しようとしましたが、機能しません。 (例は、Bug #16072 を参照してください)。

ここでは、gb2312 または gbk で正当な文字を明らかにして、正式なドキュメントへの参照を示します。 gb2312 または gbk のバグを報告する前に、次のリファレンスを確認してください:

また、CJK 文字を Unicode 文字セットで格納することもできますが、使用可能な照合順序では文字が予期したとおりにソートされない場合があります:

Unicode 文字セットに使用される照合順序によって、セット内の文字をソート (区別) する機能が決まります:

さらに、文字の区別は、特定の CJK 言語の表記規則に従って文字を順序付けすることと同じではありません。 現在、MySQL には CJK 固有の UCA 照合順序である gb18030_unicode_520_ci のみがあります (Unicode 以外の gb18030 文字セットを使用する必要があります)。

Unicode 照合およびそれらの区別プロパティ (補助文字の照合プロパティを含む) の詳細は、セクション10.10.1「Unicode 文字セット」 を参照してください。

この問題は通常、MySQL の設定がアプリケーションプログラムまたはオペレーティングシステムの設定と一致しないことが原因です。 これらのタイプの問題を修正するための一般的な手順を次に示します。

MySQL は、香港および台湾 (中華民国) で一般的な Big5 文字セットをサポートしています。 MySQL big5 文字セットは、実際には元の big5 文字セットと非常によく似た Microsoft コードページ 950 にあります。

HKSCS 拡張を追加する機能要求は申請されています。 この拡張を必要とするユーザーの場合、Bug #13577 のための推奨パッチが役に立つことがあります。

MySQL は、sjis、ujis、cp932、および eucjpms 文字セットと Unicode をサポートしています。 一般的なニーズは文字セット間で変換を行うことです。 たとえば、Unix のサーバー (通常は sjis または ujis が使用されます) と Windows のクライアント (通常は cp932 が使用されます) を使用している場合があります。

次の変換テーブルでは、ucs2 カラムはソースを表し、sjis, cp932, ujis および eucjpms カラムは宛先を表します。つまり、CONVERT(ucs2) を使用するか、値を含む ucs2 カラムを sjis, cp932, ujis または eucjpms カラムに割り当てると、最後の 4 カラムは 16 進数の結果を提供します。

では、この表の次の部分について考えてみましょう。

つまり、MySQL は NOT SIGN (Unicode U+00AC) を sjis コードポイント 0x81CA および cp932 コードポイント 3F に変換します。(3F は疑問符 (「?」) です。 これは、変換を実行できない場合に常に使用されるものです。)

答えは「?」です。 これにはデメリットがあり、多くのユーザーが「「ルーズ」」変換を希望するため、sjis の 81CA (NOT SIGN) は cp932 の 81CA (FULLWIDTH NOT SIGN) になります。

一部のバージョンの日本語文字セット (sjis と euc) では 5C が逆斜線 (\、バックスラッシュとも呼ばれる) として扱われ、他のバージョンでは円記号 (¥) として扱われるため、問題が発生します。

MySQL は JIS (Japanese Industrial Standards) 標準に記述されている 1 つのバージョンのみに従っています。 MySQL では 5C は常にリバースソリダス (\) です。

理論的には、複数のバージョンの euckr (Extended Unix Code Korea) 文字セットがありますが、認識されている問題は 1 つだけです。 コードポイント 0x5c がウォン記号 (₩) である EUC-KR の「KS-Roman」バリアントではなく、コードポイント 0x5c がリバースソリダス (つまり、\) である EUC-KR の「ASCII」バリアントが使用されています。 これは、Unicode の U+20A9 を euckr に変換できないことを意味します。

mysql> SELECT
           CONVERT('₩' USING euckr) AS euckr,
           HEX(CONVERT('₩' USING euckr)) AS hexeuckr;
+-------+----------+
| euckr | hexeuckr |
+-------+----------+
| ?     | 3F       |
+-------+----------+

この問題を確認するには、Unicode (ucs2) カラムと中国語 (gb2312) カラムを含むテーブルを作成します。

mysql> CREATE TABLE ch
       (ucs2 CHAR(3) CHARACTER SET ucs2,
       gb2312 CHAR(3) CHARACTER SET gb2312);

非厳密 SQL モードでは、両方のカラムにまれな文字汌を配置してみてください。

mysql> SET sql_mode = '';
mysql> INSERT INTO ch VALUES ('A汌B','A汌B');
Query OK, 1 row affected, 1 warning (0.00 sec)

INSERT によって警告が生成されます。 次のステートメントを使用してその内容を確認します。

mysql> SHOW WARNINGS\G
*************************** 1. row ***************************
  Level: Warning
   Code: 1366
Message: Incorrect string value: '\xE6\xB1\x8CB' for column 'gb2312' at row 1

gb2312 カラムのみに関する警告でした。

mysql> SELECT ucs2,HEX(ucs2),gb2312,HEX(gb2312) FROM ch;
+-------+--------------+--------+-------------+
| ucs2  | HEX(ucs2)    | gb2312 | HEX(gb2312) |
+-------+--------------+--------+-------------+
| A汌B | 00416C4C0042 | A?B    | 413F42      |
+-------+--------------+--------+-------------+

いくつかのことを説明する必要があります。

mysql クライアントを使用してサーバーへの直接接続を取得し、そこで同じクエリーを試行します。 mysql が正しく応答する場合、問題はアプリケーションインタフェースの初期化が必要である可能性があります。 mysql で SHOW VARIABLES LIKE 'char%'; ステートメント使用して、使用される文字セットを確認します。 Access を使用している場合、コネクタ/ODBC を使用して接続している可能性があります。 この場合は、Configuring Connector/ODBCを確認してください。 たとえば、big5 を使用する場合は、SET NAMES 'big5'と入力します。 (この場合、;文字は必要ありません。) ASP を使用している場合は、コードに SET NAMES を追加する必要があることがあります。 過去に作成された例を次に示します。

<%
Session.CodePage=0
Dim strConnection
Dim Conn
strConnection="driver={MySQL ODBC 3.51 Driver};server=server;uid=username;" \
               & "pwd=password;database=database;stmt=SET NAMES 'big5';"
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open strConnection
%>

ほぼ同様に、Connector/NET で latin1 以外の文字セットを使用している場合は、接続文字列に文字セットを指定する必要があります。 詳細は、Connector/NET Connectionsを参照してください。

PHP を使用している場合は、次のコードを試してください。

<?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'");
?>

この場合、SET NAMES を使用して character_set_client、character_set_connection および character_set_results を変更しました。

PHP アプリケーションで頻繁に発生する別の問題は、ブラウザによって行われる想定に関連しています。 問題を修正するために <meta> タグの追加または変更で十分な場合があります: たとえば、ユーザーエージェントがページコンテンツを UTF-8 として解釈するようにするには、HTML ページの <head> セクションに <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> を含めます。

Connector/J を使用している場合は、Using Character Sets and Unicodeを参照してください。

MySQL バージョン 4.0 では、サーバーおよびクライアントの両方のための単一の「グローバル」文字セットがあり、使用する文字の決定はサーバー管理者が行なっていました。 これは MySQL バージョン 4.1 以降で変更されました。 現在行われるのは、セクション10.4「接続文字セットおよび照合順序」に説明されているように、「ハンドシェイク」です。

このことの影響は、--character-set-server=utf8 を指定して mysqld を開始することによって、クライアントの文字セットを制御できないことです。 ただし、アジアの顧客の中には、MySQL 4.0 の動作を好むものもあります。 この動作を維持できるように、--skip-character-set-client-handshake を使用してオフにできる mysqld スイッチ --character-set-client-handshake が追加されました。 --skip-character-set-client-handshake を使用して mysqld を起動すると、クライアントは接続時に、使用する文字セットの名前をサーバーに送信します。 ただし、サーバーはクライアントからのこのリクエストを無視。

たとえば、お気に入りのサーバー文字セットが latin1 であるとします。 クライアントのオペレーティングシステムでサポートされている文字セットであるため、クライアントが utf8 を使用しているとします。 デフォルトの文字セットとして latin1 を使用してサーバーを起動します:

mysqld --character-set-server=latin1

そのあと、クライアントをデフォルトの文字セット utf8 で起動します。

mysql --default-character-set=utf8

結果の設定は、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                                 |
| character_set_results    | utf8                                   |
| character_set_server     | latin1                                 |
| character_set_system     | utf8                                   |
| character_sets_dir       | /usr/local/mysql/share/mysql/charsets/ |
+--------------------------+----------------------------------------+

次に、クライアントを停止し、mysqladmin を使用してサーバーを停止します。 今度はハンドシェイクをスキップするように通知して、サーバーをふたたび起動します。

mysqld --character-set-server=utf8 --skip-character-set-client-handshake

utf8 をデフォルトの文字セットとして再度使用してクライアントを起動し、結果の設定を表示します:

mysql> SHOW VARIABLES LIKE 'char%';
+--------------------------+----------------------------------------+
| Variable_name            | Value                                  |
+--------------------------+----------------------------------------+
| character_set_client     | latin1                                 |
| character_set_connection | latin1                                 |
| character_set_database   | latin1                                 |
| character_set_filesystem | binary                                 |
| character_set_results    | latin1                                 |
| character_set_server     | latin1                                 |
| character_set_system     | utf8                                   |
| character_sets_dir       | /usr/local/mysql/share/mysql/charsets/ |
+--------------------------+----------------------------------------+

SHOW VARIABLES とは異なる結果を比較することでわかるように、--skip-character-set-client-handshake オプションが使用されている場合、サーバーはクライアントの初期設定を無視します。

LIKE 検索では、BINARY や BLOB などのバイナリ文字列カラム型に非常に単純な問題があります: 文字の終わりを知っている必要があります。 マルチバイト文字セットでは、各文字のオクテット長が異なることがあります。 たとえば、utf8 の場合、次に示すように A は 1 バイトを必要としますが、ペ は 3 バイトを必要とします。

+-------------------------+---------------------------+
| OCTET_LENGTH(_utf8 'A') | OCTET_LENGTH(_utf8 'ペ') |
+-------------------------+---------------------------+
|                       1 |                         3 |
+-------------------------+---------------------------+

文字列の最初の文字がどこで終わるかわからない場合は、2 番目の文字がどこで始まるかわからないため、LIKE '_A%'などの非常に単純な検索も失敗します。 解決策は、適切な CJK 文字セットを持つように定義された非バイナリ文字列カラム型を使用することです。 次に例を示します: mycol TEXT CHARACTER SET sjis。 または、比較する前に CJK 文字セットに変換してください。

これは、MySQL が存在しない文字のエンコーディングを許可できない理由の 1 つです。 不正な入力の拒否に厳密でない場合は、文字の終わりを知る方法はありません。

FULLTEXT の検索では、単語の開始位置と終了位置を知る必要があります。 西欧言語では、ほとんど (すべてではない) が識別しやすい単語境界: スペース文字を使用するため、これはほとんど問題ではありません。 ただし、通常、アジアの言語ではこれは異なります。 独自の判断で不完全な方法を使用して、すべての漢字が単語を表すと想定したり、(日本語の場合) 文法的な終わりに従ったカタカナからひらがなへの変化に応じるようにしたりすることもできます。 ただし、唯一の確実な解決策では、包括的な単語のリストが必要となります。これは、サポートされる各アジア言語のサーバーに辞書を含める必要があることを意味します。 これは簡単に言って実現可能ではありません。

簡体字中国語および半角ではない基本的な日本語のかな文字のほとんどは、すべての CJK 文字セットで表示されます。 次のストアドプロシージャは、UCS-2 Unicode 文字を受け入れて他の文字セットに変換し、結果を 16 進数で表示します。

DELIMITER //

CREATE PROCEDURE p_convert(ucs2_char CHAR(1) CHARACTER SET ucs2)
BEGIN

CREATE TABLE tj
             (ucs2 CHAR(1) character set ucs2,
              utf8 CHAR(1) character set utf8,
              big5 CHAR(1) character set big5,
              cp932 CHAR(1) character set cp932,
              eucjpms CHAR(1) character set eucjpms,
              euckr CHAR(1) character set euckr,
              gb2312 CHAR(1) character set gb2312,
              gbk CHAR(1) character set gbk,
              sjis CHAR(1) character set sjis,
              ujis CHAR(1) character set ujis);

INSERT INTO tj (ucs2) VALUES (ucs2_char);

UPDATE tj SET utf8=ucs2,
              big5=ucs2,
              cp932=ucs2,
              eucjpms=ucs2,
              euckr=ucs2,
              gb2312=ucs2,
              gbk=ucs2,
              sjis=ucs2,
              ujis=ucs2;

/* If there are conversion problems, UPDATE produces warnings. */

SELECT hex(ucs2) AS ucs2,
       hex(utf8) AS utf8,
       hex(big5) AS big5,
       hex(cp932) AS cp932,
       hex(eucjpms) AS eucjpms,
       hex(euckr) AS euckr,
       hex(gb2312) AS gb2312,
       hex(gbk) AS gbk,
       hex(sjis) AS sjis,
       hex(ujis) AS ujis
FROM tj;

DROP TABLE tj;

END//

DELIMITER ;

入力には、単一の ucs2 文字を使用することも、その文字のコード値 (16 進表記) を使用することもできます。 たとえば、ucs2 エンコーディングおよび名前 (http://www.unicode.org/Public/UNIDATA/UnicodeData.txt) の Unicode リストから、Katakana 文字 Pe がすべての CJK 文字セットに表示され、そのコード値が X'30DA'であることがわかります。 この値を p_convert() の引数として使用すると、次のような結果となります。

mysql> CALL p_convert(X'30DA');
+------+--------+------+-------+---------+-------+--------+------+------+------+
| ucs2 | utf8   | big5 | cp932 | eucjpms | euckr | gb2312 | gbk  | sjis | ujis |
+------+--------+------+-------+---------+-------+--------+------+------+------+
| 30DA | E3839A | C772 | 8379  | A5DA    | ABDA  | A5DA   | A5DA | 8379 | A5DA |
+------+--------+------+-------+---------+-------+--------+------+------+------+

いずれのカラム値も 3F (疑問符文字、?) ではないため、すべての変換が機能したことがわかります。

古い MySQL バージョンで発生した CJK ソートの問題は、utf8mb4 文字セットおよび utf8mb4_ja_0900_as_cs 照合順序を使用して、MySQL 8.0 の時点で解決できます。

古い MySQL バージョンで発生した CJK ソートの問題は、utf8mb4 文字セットおよび utf8mb4_ja_0900_as_cs 照合順序を使用して、MySQL 8.0 の時点で解決できます。

補助文字は Unicode 基本多言語面 / 平面 0の外部にあります。 BMP 文字には、U+0000 と U+FFFF の間のコードポイント値があります。 補助文字には、U+10000 と U+10FFFF の間のコードポイント値があります。

補助文字を格納するには、それらを許可する文字セットを使用する必要があります:

いいえ。用語「CJKV」(Chinese Japanese Korean Vietnamese) は漢字 (もともとは中国語) が含まれているベトナム文字セットを指しています。 MySQL は、西部文字を含む最新のベトナム語スクリプトをサポートしていますが、ハン文字を使用した古いベトナム語スクリプトはサポートしていません。

MySQL 5.6 の時点では、セクション10.10.1「Unicode 文字セット」で説明しているように、Unicode 文字セットにベトナム語の照合順序があります。

はい。

MySQL 5.6 マニュアルの日本語版は、https://dev.mysql.com/doc/ からダウンロードできます。

次のリソースを利用できます。