|
A.11.1.
|
MySQL で使用できる CJK
文字セットはどの文字セットですか。
|
|
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 |
+--------------------+---------------------------------+
9 rows in set (0.01 sec)
(詳細は、セクション21.1「INFORMATION_SCHEMA CHARACTER_SETS テーブル」を参照してください。)
MySQL
は中華人民共和国の正式な文字セットである
GB 文字セット (Guojia
Biaozhun、National
Standard、または Simplified
Chinese) の 3 つのバリアント
(gb2312、gbk、および
gb18030 (MySQL 5.7.4
で追加されました)) をサポートしています。
ユーザーが gbk の文字を
gb2312
に挿入しようとすることがありますが、これはほとんどの場合動作します。gbk
は gb2312
のスーパーセットであるためです。ただし、より珍しい漢字を挿入しようとすると動作しません。(例については、Bug
#16072 を参照してください)。
ここでは、gb2312 または
gbk
で正当な文字を明らかにして、正式なドキュメントへの参照を示します。gb2312
または gbk
のバグを報告する前に、これらのリファレンスを確認してください。
|
|
A.11.2.
|
CJK
文字をテーブルに挿入しました。SELECT
でそれらが「?」文字として表示されるのはなぜですか。
|
|
この問題は、通常、アプリケーションプログラムまたはオペレーティングシステムの設定と
MySQL
の設定が一致していないことが原因です。これらのタイプの問題を修正するための一般的な手順を次に示します。
-
使用している MySQL
のバージョンを確認します。
これを判別するには、SELECT
VERSION();
ステートメントを使用します。
-
意図した文字セットがデータベースで実際に使用されていることを確認します。
ユーザーは多くの場合、クライアントの文字セットはサーバーの文字セットまたは表示のために使用される文字セットと常に同じであると考えます。ただし、これらは両方とも間違った想定です。SHOW
CREATE TABLE tablename
の結果をチェックするか、次のステートメントを使用することによって確認できます。
SELECT character_set_name, collation_name
FROM information_schema.columns
WHERE table_schema = your_database_name
AND table_name = your_table_name
AND column_name = your_column_name;
-
正しく表示されない文字の 16
進値を判別します。
テーブル table_name
のカラム column_name
のこの情報を取得するには、次のクエリーを使用します。
SELECT HEX(column_name)
FROM table_name;
3F は ?
文字のエンコードです。これは、?
が実際にカラムに格納される文字であることを意味します。これは、ほとんどの場合、特定の文字をクライアントの文字セットからターゲットの文字セットに変換するときの問題のために発生します。
-
ラウンドトリップが可能であることを確認します
(つまり、literal (または
_introducer hexadecimal-value)
を選択すると、結果として
literal
が取得される)。
たとえば、日本語のカタカナ文字
Pe (ペ)
はすべての CJK
文字セットに存在し、コードポイント値 (16
進コーディング) は 0x30da
です。この文字のラウンドトリップをテストするには、次のクエリーを使用します。
SELECT 'ペ' AS `ペ`; /* or SELECT _ucs2 0x30da; */
結果も「ペ」ではない場合、ラウンドトリップは失敗しました。
そのような失敗に関するバグレポートの場合は、SELECT
HEX('ペ');
も試すように要請されることがあります。これにより、クライアントのエンコードが正しいかどうかを判断できます。
-
問題が MySQL
以外のブラウザまたはほかのアプリケーションの問題ではないことを確認します。
このタスクを行うには、mysql
クライアントプログラム (Windows の場合:
mysql.exe)
を使用します。mysql
では正しく表示されるが、アプリケーションでは表示されない場合、問題はシステム設定が原因である可能性があります。
設定を確認するには、次のような出力が表示される
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/ |
+--------------------------+----------------------------------------+
8 rows in set (0.03 sec)
これらは、西洋諸国のサーバー
(latin1
は西ヨーロッパ文字セットであり、MySQL
のデフォルトです)
に接続される国際業務用のクライアントの典型的な文字セット設定です
(utf8 Unicode
が使用されています)。
Latin よりも Unicode (通常、Unix での
utf8 バリアント、および Windows
での ucs2 バリアント)
の方が望ましいですが、オペレーティングシステムのユーティリティーで最適にサポートされる文字セットではないことがあります。多くの
Windows ユーザーは、Microsoft の文字セット
(日本語 Windows 用の cp932 など)
が適当であると判断します。
サーバーの設定を制御できず、基盤となっているコンピュータがわからない場合は、自分の国の一般的な文字セットに変更することを試してください
(euckr =
韓国、gb18030、gb2312、または
gbk =
中華人民共和国、big5 =
台湾、sjis、ujis、cp932、または
eucjpms =
日本、ucs2 または
utf8 =
すべての国)。通常、クライアント、接続、および結果の設定のみを変更する必要があります。この
3
つを一度にすべて変更する簡単なステートメントがSET
NAMES です。例:
SET NAMES 'big5';
設定が正しい場合は、my.cnf
または my.ini
を編集することによってそれを永続的なものにできます。たとえば、次のような行を追加できます。
[mysqld]
character-set-server=big5
[client]
default-character-set=big5
アプリケーションで使用されている API
構成の設定に問題があることもあります。詳細は、「GUI
フロントエンドまたはブラウザで CJK
文字が正しく表示されないのはなぜですか」を参照してください。
|
|
A.11.3.
|
Big5
中国語文字セットを使用する場合は、どのような問題に注意するべきですか。
|
|
MySQL は、香港および台湾 (中華民国) で一般的な
Big5 文字セットをサポートしています。MySQL の
big5 は、実際には、本来の
big5 文字セットと非常に似ている
Microsoft コードページ 950
です。この文字セットは
MySQL バージョン 4.1.16 / 5.0.16
以降で変更されています (Bug #12476
のため)。たとえば、次のステートメントは最新のバージョンの
MySQL
では動作しますが、古いバージョンでは動作しません。
mysql> CREATE TABLE big5 (BIG5 CHAR(1) CHARACTER SET BIG5);
Query OK, 0 rows affected (0.13 sec)
mysql> INSERT INTO big5 VALUES (0xf9dc);
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM big5;
+------+
| big5 |
+------+
| 嫺 |
+------+
1 row in set (0.02 sec)
HKSCS
拡張を追加する機能要求は申請されています。この拡張を必要とするユーザーの場合、Bug
#13577
のための推奨パッチが役に立つことがあります。
|
|
A.11.4.
|
日本語文字セットの変換が失敗するのはなぜですか。
|
|
MySQL
は、sjis、ujis、cp932、および
eucjpms 文字セットと Unicode
をサポートしています。一般的なニーズは文字セット間で変換を行うことです。たとえば、Unix
のサーバー (通常は sjis または
ujis が使用されます) と Windows
のクライアント (通常は cp932
が使用されます)
を使用している場合があります。
次の変換表で、ucs2
カラムは変換前を表し、sjis、cp932、ujis、および
eucjpms
カラムは変換後を表しています。つまり、後ろの
4
つのカラムは、CONVERT(ucs2)
を使用するか、値が含まれている
ucs2 カラムを
sjis、cp932、ujis、または
eucjpms カラムに割り当てたときの
16 進数の結果を示しています。
では、この表の次の部分について考えてみましょう。
これは、MySQL が NOT SIGN (Unicode の
U+00AC) を sjis
のコードポイント 0x81CA および
cp932 のコードポイント
3F に変換することを意味します
(3F は疑問符 (「?」)
であり、変換を実行できないときに常に使用される文字です)。
|
|
A.11.5.
|
SJIS の 81CA を cp932
に変換する場合はどうすればよいですか。
|
|
答えは「?」です。これについては深刻な苦情が寄せられています。多くのユーザーは、sjis
の 81CA (NOT SIGN) が
cp932 の 81CA (FULLWIDTH NOT
SIGN)
になるような「緩い」変換を望んでいます。この動作に変更することが検討されています。
|
|
A.11.6.
|
MySQL では円 (¥)
記号をどのように表しますか。
|
|
いくつかのバージョンの日本語文字セット
(sjis および euc
の両方) では 5C
がリバースソリダス
(\。バックスラッシュとも呼ばれます)
として扱われ、ほかの文字セットでは円記号
(¥)
として扱われるため、問題が発生します。
MySQL は JIS (Japanese Industrial Standards)
標準に記述されている 1
つのバージョンのみに従っています。MySQL では
5C
は常にリバースソリダス
(\) です。
|
|
A.11.7.
|
MySQL
で韓国語文字セットを使用する場合に注意する問題はありますか。
|
|
理論的には、複数のバージョンの
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 |
+-------+----------+
1 row in set (0.00 sec)
|
|
A.11.8.
|
なぜ「Incorrect string
value」というエラーメッセージが表示されるのですか。
|
|
説明のために、1 つの Unicode (ucs2)
カラムおよび 1 つの中国語 (gb2312)
カラムを持つテーブルを作成します。
mysql> CREATE TABLE ch
-> (ucs2 CHAR(3) CHARACTER SET ucs2,
-> gb2312 CHAR(3) CHARACTER SET gb2312);
Query OK, 0 rows affected (0.05 sec)
両方のカラムに珍しい文字「汌」を挿入することを試みます。
mysql> INSERT INTO ch VALUES ('A汌B','A汌B');
Query OK, 1 row affected, 1 warning (0.00 sec)
警告が報告されました。次のステートメントを使用してその内容を確認します。
mysql> SHOW WARNINGS\G
*************************** 1. row ***************************
Level: Warning
Code: 1366
Message: Incorrect string value: '\xE6\xB1\x8CB' for column 'gb2312' at row 1
1 row in set (0.00 sec)
gb2312
カラムのみに関する警告でした。
mysql> SELECT ucs2,HEX(ucs2),gb2312,HEX(gb2312) FROM ch;
+-------+--------------+--------+-------------+
| ucs2 | HEX(ucs2) | gb2312 | HEX(gb2312) |
+-------+--------------+--------+-------------+
| A汌B | 00416C4C0042 | A?B | 413F42 |
+-------+--------------+--------+-------------+
1 row in set (0.00 sec)
いくつかのことを説明する必要があります。
「エラー」ではなく「警告」であることが
MySQL
の特徴です。あきらめずにできることをして最善の結果を得ることが試みられます。
「汌」という文字は
gb2312
文字セットにありません。この問題については前に説明しました。
古いバージョンの MySQL
を使用している場合は、別のメッセージが表示される可能性があります。
sql_mode=TRADITIONAL
を設定している場合は、警告ではなくエラーメッセージが表示されます。
|
|
A.11.9.
|
Access、PHP、またはその他の API
を使用したアプリケーションの GUI
フロントエンドまたはブラウザで、CJK
文字が正しく表示されないのはなぜですか。
|
|
mysql クライアント (Windows:
mysql.exe)
を使用してサーバーに直接接続し、同じクエリーをそこで試してください。mysql
が正常に応答する場合、問題はアプリケーションインタフェースで初期化が必要であることである可能性があります。mysql
で SHOW VARIABLES LIKE 'char%';
ステートメント使用して、使用される文字セットを確認します。Access
を使用している場合は、Connector/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
以外の文字セットを使用している場合は、接続文字列に文字セットを指定する必要があります。詳細は、Connecting to MySQL Using Connector/NETを参照してください。
PHP
を使用している場合は、次のコードを試してください。
<?php
$link = mysql_connect($host, $usr, $pwd);
mysql_select_db($db);
if( mysql_error() ) { print "Database ERROR: " . mysql_error(); }
mysql_query("SET NAMES 'utf8'", $link);
?>
この場合、SET NAMES を使用して
character_set_client、character_set_connection、および
character_set_results
を変更しています。
mysql ではなく、新しい
mysqli
拡張を使用することをお勧めします。mysqli
を使用する場合は、前の例を次のように書き直すことができます。
<?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'");
?>
PHP
アプリケーションで頻繁に発生する別の問題は、ブラウザによって行われる想定に関連しています。<meta>
タグを追加または変更するだけでこの問題が修正されることがあります。たとえば、ユーザーエージェントがページの内容を
UTF-8
として解釈するようにするには、HTML ページの
<head> に <meta
http-equiv="Content-Type" content="text/html;
charset=utf-8"> を含めてください。
Connector/J
を使用している場合は、Using Character Sets and Unicodeを参照してください。
|
|
A.11.10.
|
MySQL 5.6
にアップグレードしました。文字セットに関して、MySQL
4.0 の動作に戻すにはどうすればよいですか。
|
|
MySQL バージョン 4.0
では、サーバーおよびクライアントの両方のための単一の「グローバル」文字セットがあり、使用する文字の決定はサーバー管理者が行なっていました。これは
MySQL バージョン 4.1
以降で変更されました。現在行われるのは、セクション10.1.4「接続文字セットおよび照合順序」に説明されているように、「ハンドシェイク」です。
クライアントが接続するときに、使用する文字セットの名前をサーバーに送信します。サーバーはこの名前を使用して、character_set_client、character_set_results、および
character_set_connection
システム変数を設定します。実際には、サーバーは文字セット名を使用して
SET NAMES 操作を実行します。
このことの影響は、--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 であるとします (CJK
地域ではあまりないことですが、これはデフォルト値です)。クライアントのオペレーティングシステムでサポートされている文字セットであるため、クライアントが
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/ |
+--------------------------+----------------------------------------+
8 rows in set (0.01 sec)
クライアントを停止し、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/ |
+--------------------------+----------------------------------------+
8 rows in set (0.01 sec)
SHOW VARIABLES
の異なる結果を比較することによって確認できるように、--skip-character-set-client-handshake
が使用された場合、サーバーはクライアントの初期設定を無視します。
|
|
A.11.11.
|
CJK 文字での LIKE
検索および FULLTEXT
検索が失敗することがあるのはなぜですか。
|
|
BINARY カラムおよび
BLOB カラムに対する
LIKE
検索には非常に単純な問題があります。文字の終わりを判別する必要があることです。マルチバイト文字セットでは、各文字のオクテット長が異なることがあります。たとえば、utf8
の場合、次に示すように A は 1
バイトを必要としますが、ペ は 3
バイトを必要とします。
+-------------------------+---------------------------+
| OCTET_LENGTH(_utf8 'A') | OCTET_LENGTH(_utf8 'ペ') |
+-------------------------+---------------------------+
| 1 | 3 |
+-------------------------+---------------------------+
1 row in set (0.00 sec)
最初の文字の終わりを判別できなければ、2
番目の文字が始まる位置を判別できません。この場合、LIKE
'_A%'
などの非常に単純な検索が失敗します。解決策は、通常の
CJK
文字セットを最初から使用するか、比較する前に
CJK 文字を変換することです。
これは、存在しない文字のエンコードを MySQL
が許可できない理由の 1
つです。不正な入力を厳密に拒否しなければ、文字の終わりを判別する方法がありません。
FULLTEXT
検索の場合は、単語の始まりと終わりを判別する必要があります。西洋の言語の場合、それらのほとんど
(すべてでなければ)
が簡単に識別できる単語の境界 (スペース文字)
を使用しているため、これが問題となることはほとんどありません。ただし、通常、アジアの言語ではこれは異なります。独自の判断で不完全な方法を使用して、すべての漢字が単語を表すと想定したり、(日本語の場合)
文法的な終わりに従ったカタカナからひらがなへの変化に応じるようにしたりすることもできます。ただし、唯一の確実な解決策では、包括的な単語のリストが必要となります。これは、サポートされる各アジア言語のサーバーに辞書を含める必要があることを意味します。これは簡単に言って実現可能ではありません。
|
|
A.11.12.
|
文字 X
がすべての文字セットで使用可能であるかどうかを判別するにはどうすればよいですか。
|
|
簡体字中国語および半角ではない基本的な日本語のかな文字のほとんどは、すべての
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 is a conversion problem, UPDATE will produce a warning. */
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//
入力は、単一の ucs2
文字、またはその文字のコードポイント値 (16
進表記) です。たとえば、ucs2
のエンコードおよび名前についての Unicode
のリスト
(http://www.unicode.org/Public/UNIDATA/UnicodeData.txt)
から、カタカナ文字 Pe
はすべての CJK
文字セットにあり、コードポイント値が
0x30da
であることがわかります。この値を
p_convert()
の引数として使用すると、次のような結果となります。
mysql> CALL p_convert(0x30da)//
+------+--------+------+-------+---------+-------+--------+------+------+------+
| ucs2 | utf8 | big5 | cp932 | eucjpms | euckr | gb2312 | gbk | sjis | ujis |
+------+--------+------+-------+---------+-------+--------+------+------+------+
| 30DA | E3839A | C772 | 8379 | A5DA | ABDA | A5DA | A5DA | 8379 | A5DA |
+------+--------+------+-------+---------+-------+--------+------+------+------+
1 row in set (0.04 sec)
カラム値が 3F
(つまり、疑問符文字 (?))
であるカラムがないため、すべての変換が正常に行われたことがわかります。
|
|
A.11.13.
|
CJK 文字列が Unicode
で間違ってソートされるのはなぜですか。(I)
|
|
utf8_unicode_ci 検索や
ucs2_unicode_ci 検索、または
ORDER BY
ソートの結果が、母国語のユーザーが予期する結果ではないことがあります。バグである可能性を除外するわけではありませんが、多くのユーザーは
Unicode Collation Algorithm
の標準表のウェイトを正しく読んでいないことが過去に判明しました。MySQL
は
http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt
にある表を使用しています。これは、unicode.org
のホームページからナビゲートすることによって見つかる最初の表ではありません。MySQL
はより新しい 4.1.0 の 「allkeys」
表ではなく、古い 4.0.0
の表を使用しているためです。(MySQL 5.6
の新しい '520' 照合順序では、5.2
の 「allkeys」
表が使用されています。)これは、次に示した
Bug #16526
で報告されたような状況が発生しないように、インデックスに影響する順序付けの変更に非常に慎重であるためです。
mysql< CREATE TABLE tj (s1 CHAR(1) CHARACTER SET utf8 COLLATE utf8_unicode_ci);
Query OK, 0 rows affected (0.05 sec)
mysql> INSERT INTO tj VALUES ('が'),('か');
Query OK, 2 rows affected (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 0
mysql> SELECT * FROM tj WHERE s1 = 'か';
+------+
| s1 |
+------+
| が |
| か |
+------+
2 rows in set (0.00 sec)
最初の結果行の文字は、検索した文字ではありません。MySQL
でその文字が取得されたのはなぜでしょうか。まず、Unicode
のコードポイント値を確認します。これを行うには、ucs2
バージョンの文字の 16 進数を表示します。
mysql> SELECT s1, HEX(CONVERT(s1 USING ucs2)) FROM tj;
+------+-----------------------------+
| s1 | HEX(CONVERT(s1 USING ucs2)) |
+------+-----------------------------+
| が | 304C |
| か | 304B |
+------+-----------------------------+
2 rows in set (0.03 sec)
4.0.0 allkeys 表で 304B
および 304C
を探すと、これらの行が見つかります。
304B ; [.1E57.0020.000E.304B] # HIRAGANA LETTER KA
304C ; [.1E57.0020.000E.304B][.0000.0140.0002.3099] # HIRAGANA LETTER GA; QQCM
正式な Unicode 名 (「#」
マークの後ろにあります) は、日本語の五十音
(ひらがな)、非公式な区分
(文字、数字、または句読点)、西洋言語での識別子
(KA または
GA。これは、たまたま同じ文字のペアの有声音および無声音となっています)
を示しています。さらに重要なのは、プライマリウェイト
(角括弧の中の最初の 16 進数) が両方の行で
1E57
となっていることです。検索とソートの両方の比較で、MySQL
はプライマリウェイトのみに注意を払って、ほかのすべての数値を無視します。これは、「が」および「か」が
Unicode
の仕様に従って正しくソートされていることを意味します。これらを区別するには、UCA
(Unicode Collation Algorithm) 以外の照合順序
(utf8_bin または
utf8_general_ci)
を使用するか、HEX()
値を比較するか、ORDER BY CONVERT(s1 USING
sjis)
を使用する必要があります。もちろん、「Unicode
に従えば」正しいだけでは十分ではなく、バグを報告したユーザーも同様に正しいと言えます。KA/GA
のような有声音/無声音文字のペアを順序付けのために区別できる、JIS
X 4061
標準に従った別の日本語の照合順序を追加する計画があります。
|
|
A.11.14.
|
CJK 文字列が Unicode
で間違ってソートされるのはなぜですか。(II)
|
|
Unicode (ucs2 または
utf8) を使用していて、Unicode
のソート順がわかっているが
(セクションA.11「MySQL 5.6 FAQ: MySQL の中国語、日本語、および韓国語の文字セット」を参照してください)、MySQL
でテーブルが間違ってソートされているように見える場合は、まずテーブルの文字セットを確認してください。
mysql> SHOW CREATE TABLE t\G
******************** 1. row ******************
Table: t
Create Table: CREATE TABLE `t` (
`s1` char(1) CHARACTER SET ucs2 DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1
1 row in set (0.00 sec)
文字セットは正しいように見えるため、このカラムに関して
INFORMATION_SCHEMA.COLUMNS
テーブルで表示できる情報を確認します。
mysql> SELECT COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME
-> FROM INFORMATION_SCHEMA.COLUMNS
-> WHERE COLUMN_NAME = 's1'
-> AND TABLE_NAME = 't';
+-------------+--------------------+-----------------+
| COLUMN_NAME | CHARACTER_SET_NAME | COLLATION_NAME |
+-------------+--------------------+-----------------+
| s1 | ucs2 | ucs2_general_ci |
+-------------+--------------------+-----------------+
1 row in set (0.01 sec)
(詳細は、セクション21.4「INFORMATION_SCHEMA COLUMNS テーブル」を参照してください。)
照合順序が ucs2_unicode_ci ではなく
ucs2_general_ci
であることがわかります。このようになる理由は、次のように
SHOW CHARSET
を使用して見つけることができます。
mysql> SHOW CHARSET LIKE 'ucs2%';
+---------+---------------+-------------------+--------+
| Charset | Description | Default collation | Maxlen |
+---------+---------------+-------------------+--------+
| ucs2 | UCS-2 Unicode | ucs2_general_ci | 2 |
+---------+---------------+-------------------+--------+
1 row in set (0.00 sec)
ucs2 および utf8
の場合、デフォルトの照合順序は
「general」 です。Unicode
の照合順序を指定するには、COLLATE
ucs2_unicode_ci を使用します。
|
|
A.11.15.
|
補助文字が MySQL で拒否されるのはなぜですか。
|
|
MySQL 5.5.3 より前では、MySQL は補助文字
(つまり、UTF-8 で 3
バイトを超えるサイズを必要とする文字)
をサポートしていません。Unicode
で基本多言語面/第 0
面と呼ばれているもののみがサポートされます。いくつかの非常に珍しい漢字のみが補助文字となっています。それらに対するサポートは一般的ではありません。このことが
Bug #12600
などで報告され、「バグではありません」として拒否されました。utf8
では、理解できないバイトが出現した場合に、入力文字列を切り捨てる必要があります。そうしないと、不正なマルチバイト文字の長さがわかりません。
考えられる 1 つの回避策は、utf8
の代わりに ucs2
を使用することです。この場合、「不正な」文字は疑問符に置き換えられますが、切り捨ては行われません。妥当性チェックが行われない
BLOB または
BINARY
にデータ型を変更することもできます。
MySQL 5.5.3 の時点では、追加の Unicode 文字セット
utf16、utf32、および
4 バイトの utf8mb4 によって Unicode
のサポートが拡張され、補助文字が含まれるようになりました。これらの文字セットでは、基本多言語面
(BMP) の外にある補助 Unicode
文字がサポートされます。
|
|
A.11.16.
|
「CJKV」にするべきではありませんか。
|
|
いいえ。用語「CJKV」(Chinese
Japanese Korean Vietnamese) は漢字
(もともとは中国語)
が含まれているベトナム文字セットを指しています。MySQL
では、漢字を使用した古いベトナム文字をサポートする計画はありません。MySQL
では、西洋文字を使用する現代のベトナム文字はもちろんサポートされます。
MySQL 5.6
の時点では、セクション10.1.14.1「Unicode 文字セット」で説明しているように、Unicode
文字セットにベトナム語の照合順序があります。
|
|
A.11.17.
|
MySQL では CJK
文字をデータベース名およびテーブル名に使用できますか。
|
|
この問題は、対応するディレクトリおよびファイルの名前を自動的に書き換えることによって、MySQL
5.1 で修正されました。
たとえば、オペレーティングシステムでディレクトリ名に
CJK
がサポートされないサーバーに「楮」という名前のデータベースを作成した場合、MySQL
は E6A5AE
(つまり、「楮」文字の Unicode の
16 進表現) を特殊な方法でエンコードした
@0w@00a5@00ae
という名前のディレクトリが作成されます。ただし、SHOW
DATABASES
ステートメントを実行すると、データベースが「楮」として示されます。
|
|
A.11.18.
|
MySQL
マニュアルの中国語版、日本語版、および韓国語版はどこにありますか。
|
|
MySQL 5.1.12
の簡体字中国語版のマニュアルは、http://dev.mysql.com/doc/にあります。MySQL
4.1
マニュアルの日本語版は、http://dev.mysql.com/doc/
からダウンロードできます。
|
|
A.11.19.
|
MySQL での CJK
および関連する問題についての支援はどこで受けることができますか。
|
|
次のリソースを利用できます。
|