|
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 |
+--------------------+---------------------------------+
(詳細はセクション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 文字セットで格納することもできますが、使用可能な照合順序では文字が予期したとおりにソートされない場合があります:
utf8 および ucs2 文字セットでは、Unicode Basic Multilingual Plane (BMP) の文字がサポートされています。 これらの文字には、U+0000 と U+FFFF の間のコードポイント値があります。
utf8mb4, utf16, utf16le および utf32 の文字セットでは、BMP 文字と BMP の外部にある補助文字がサポートされています。 補助文字には、U+10000 と U+10FFFF の間のコードポイント値があります。
Unicode 文字セットに使用される照合順序によって、セット内の文字をソート (区別) する機能が決まります:
Unicode 照合アルゴリズム (UCA) に基づく照合では、4.0.0 は BMP 文字のみを区別します。
UCA 5.2.0 または 9.0.0 に基づく照合では、BMP と補助文字が区別されます。
UCA 以外の照合順序では、すべての Unicode 文字が区別されない場合があります。 たとえば、utf8mb4 のデフォルトの照合は utf8mb4_general_ci で、BMP 文字のみが区別されます。
さらに、文字の区別は、特定の CJK 言語の表記規則に従って文字を順序付けすることと同じではありません。 現在、MySQL には CJK 固有の UCA 照合順序である gb18030_unicode_520_ci のみがあります (Unicode 以外の gb18030 文字セットを使用する必要があります)。
Unicode 照合およびそれらの区別プロパティ (補助文字の照合プロパティを含む) の詳細は、セクション10.10.1「Unicode 文字セット」 を参照してください。
|
|
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 は ? 文字のエンコードです。これは、? が実際にカラムに格納される文字であることを意味します。 これは、ほとんどの場合、特定の文字をクライアントの文字セットからターゲットの文字セットに変換するときの問題のために発生します。
-
Make では、ラウンドトリップが可能であることを確認します。 literal (または_introducer hexadecimal-value) を選択した場合、literal を result として取得しますか。
たとえば、日本語のカタカナ文字 Pe (ペ) はすべての CJK 文字セットに存在し、コードポイント値 (16 進コーディング) は 0x30da です。 この文字のラウンドトリップをテストするには、次のクエリーを使用します。
SELECT 'ペ' AS `ペ`; /* or SELECT _ucs2 0x30da; */
結果がペでもない場合、ラウンドトリップは失敗します。
そのような失敗に関するバグレポートの場合は、SELECT HEX('ペ'); も試すように要請されることがあります。 これにより、クライアントのエンコードが正しいかどうかを判断できます。
-
問題が MySQL 以外のブラウザまたはほかのアプリケーションの問題ではないことを確認します。
このタスクを実行するには、mysql クライアントプログラムを使用します。 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/ |
+--------------------------+----------------------------------------+
これらは、West (latin1 は西ヨーロッパ言語の文字セット) のサーバーに接続された国際指向クライアント (utf8 Unicode の使用に注意) の一般的な文字セット設定です。
Latin よりも Unicode (通常、Unix での utf8 バリアント、および Windows での ucs2 バリアント) の方が望ましいですが、オペレーティングシステムのユーティリティーで最適にサポートされる文字セットではないことがあります。 多くの Windows ユーザーは、Microsoft の文字セット (日本語 Windows 用の cp932 など) が適当であると判断します。
サーバー設定を制御できず、基礎となるコンピュータで使用される設定がわからない場合は、使用している国に共通の文字セット (euckr = Korea、gb18030、gb2312 または gbk = People Republic of China; big5 = Taiwan; sjis, ujis, cp932、または eucjpms = Japan; ucs2 または utf8 = anywhere) に変更してみてください。 通常、クライアント、接続、および結果の設定のみを変更する必要があります。 SET NAMES. ステートメントは、3 つすべてを一度に変更します。 例:
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 にあります。
HKSCS 拡張を追加する機能要求は申請されています。 この拡張を必要とするユーザーの場合、Bug #13577 のための推奨パッチが役に立つことがあります。
|
|
A.11.4.
|
日本語文字セットの変換が失敗するのはなぜですか。
|
|
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 は疑問符 (「?」) です。 これは、変換を実行できない場合に常に使用されるものです。)
|
|
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 |
+-------+----------+
|
|
A.11.8.
|
なぜ「Incorrect string value」というエラーメッセージが表示されるのですか。
|
|
この問題を確認するには、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 |
+-------+--------------+--------+-------------+
いくつかのことを説明する必要があります。
前述のように、汌文字は gb2312 文字セットに含まれていません。
古いバージョンの MySQL を使用している場合は、別のメッセージが表示されることがあります。
MySQL は厳密な SQL モードを使用するように設定されていないため、エラーではなく警告が発生します。 非厳密モードでは、MySQL は放棄するのではなく、最良の適合を得るために実行しようとします。 厳密な SQL モードでは、「不正な文字列値」メッセージは警告ではなくエラーとして発生し、INSERT は失敗します。
|
|
A.11.9.
|
Access、PHP または別の API を使用して、アプリケーションで GUI フロントエンドまたはブラウザに CJK 文字が正しく表示されないのはなぜですか。
|
|
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を参照してください。
|
|
A.11.10.
|
MySQL 8.0 にアップグレードしました。 文字セットに関して、MySQL 4.0 の動作に戻すにはどうすればよいですか。
|
|
MySQL バージョン 4.0 では、サーバーおよびクライアントの両方のための単一の「グローバル」文字セットがあり、使用する文字の決定はサーバー管理者が行なっていました。 これは MySQL バージョン 4.1 以降で変更されました。 現在行われるのは、セクション10.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 であるとします。 クライアントのオペレーティングシステムでサポートされている文字セットであるため、クライアントが 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 オプションが使用されている場合、サーバーはクライアントの初期設定を無視します。
|
|
A.11.11.
|
CJK 文字での LIKE 検索および FULLTEXT 検索が失敗することがあるのはなぜですか。
|
|
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 の検索では、単語の開始位置と終了位置を知る必要があります。 西欧言語では、ほとんど (すべてではない) が識別しやすい単語境界: スペース文字を使用するため、これはほとんど問題ではありません。 ただし、通常、アジアの言語ではこれは異なります。 独自の判断で不完全な方法を使用して、すべての漢字が単語を表すと想定したり、(日本語の場合) 文法的な終わりに従ったカタカナからひらがなへの変化に応じるようにしたりすることもできます。 ただし、唯一の確実な解決策では、包括的な単語のリストが必要となります。これは、サポートされる各アジア言語のサーバーに辞書を含める必要があることを意味します。 これは簡単に言って実現可能ではありません。
|
|
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 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 (疑問符文字、?) ではないため、すべての変換が機能したことがわかります。
|
|
A.11.13.
|
CJK 文字列が Unicode で間違ってソートされるのはなぜですか。 (I)
|
|
古い MySQL バージョンで発生した CJK ソートの問題は、utf8mb4 文字セットおよび utf8mb4_ja_0900_as_cs 照合順序を使用して、MySQL 8.0 の時点で解決できます。
|
|
A.11.14.
|
CJK 文字列が Unicode で間違ってソートされるのはなぜですか。 (II)
|
|
古い MySQL バージョンで発生した CJK ソートの問題は、utf8mb4 文字セットおよび utf8mb4_ja_0900_as_cs 照合順序を使用して、MySQL 8.0 の時点で解決できます。
|
|
A.11.15.
|
補助文字が MySQL で拒否されるのはなぜですか。
|
|
補助文字は Unicode 基本多言語面 / 平面 0の外部にあります。 BMP 文字には、U+0000 と U+FFFF の間のコードポイント値があります。 補助文字には、U+10000 と U+10FFFF の間のコードポイント値があります。
補助文字を格納するには、それらを許可する文字セットを使用する必要があります:
-
utf8 および ucs2 文字セットでは BMP 文字のみがサポートされます。
utf8 文字セットでは、最大 3 バイトを超える UTF-8 文字のみが許可されます。 このことが Bug #12600 などで報告され、「バグではありません」として拒否されました。 utf8 では、認識できないバイトが検出された場合、MySQL は入力文字列を切り捨てる必要があります。 それ以外の場合、不正なマルチバイト文字の長さは不明です。
考えられる回避策の 1 つは、utf8 のかわりに ucs2 を使用することです。この場合、「bad」 文字は疑問符に変更されます。 ただし、切捨ては行われません。 妥当性チェックが行われない BLOB または BINARY にデータ型を変更することもできます。
utf8mb4, utf16, utf16le および utf32 文字セットでは、BMP 文字と BMP 外の補助文字がサポートされています。
|
|
A.11.16.
|
「CJK」 は 「CJKV」 である必要がありますか。
|
|
いいえ。用語「CJKV」(Chinese Japanese Korean Vietnamese) は漢字 (もともとは中国語) が含まれているベトナム文字セットを指しています。 MySQL は、西部文字を含む最新のベトナム語スクリプトをサポートしていますが、ハン文字を使用した古いベトナム語スクリプトはサポートしていません。
MySQL 5.6 の時点では、セクション10.10.1「Unicode 文字セット」で説明しているように、Unicode 文字セットにベトナム語の照合順序があります。
|
|
A.11.17.
|
MySQL では、CJK 文字をデータベース名およびテーブル名で使用できますか。
|
|
はい。
|
|
A.11.18.
|
MySQL マニュアルの中国語版、日本語版、および韓国語版はどこにありますか。
|
|
MySQL 5.6 マニュアルの日本語版は、https://dev.mysql.com/doc/ からダウンロードできます。
|
|
A.11.19.
|
MySQL での CJK および関連する問題についての支援はどこで受けることができますか。
|
|
次のリソースを利用できます。
|