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

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文字セット(国家标准、国家标准，または简体中文)の3つのバリアント(gb2312、gbk，およびgb18030MySQL 5.7.4で追加されました)をサポートしています。

ユーザーがgbkの文字をgb2312に挿入しようとすることがありますが，これはほとんどの場合動作します。gbkはgb2312のスーパーセットであるためです。ただし，より珍しい漢字を挿入しようとすると動作しません。(例については、Bug #16072 を参照してください)。

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

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

MySQLの繁体は，実際には，本来の繁体文字セットと非常に似ている微软コードページ950です。この文字セットはMySQLバージョン4.1.16 / 5.0.16以降で変更されています(错误# 12476のため)。たとえば,次のステートメントは最新のバージョンのMySQLでは動作しますが,古いバージョンでは動作しません。

创建表big5 (big5 CHAR(1) CHARACTER SET)INSERT INTO big5 VALUES (0xf9dc);mysql> SELECT * FROM big5;+------+ | 繁体  | +------+ | 嫺  | +------+ 1行集(0.02秒)

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

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

次の変換表で，ucs2カラムは変換前を表し，sjis、cp932、里头，およびeucjpmsカラムは変換後を表しています。つまり，後ろの4つのカラムは，转换(ucs2)を使用するか，値が含まれているucs2カラムをsjis、cp932、里头，またはeucjpmsカラムに割り当てたときの16進数の結果を示しています。

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

これは，MySQLが没有信号(UnicodeのU + 00交流)をsjisのコードポイント0 x81caおよびcp932のコードポイント3 fに変換することを意味します(3 fは疑問符(「?」)であり，変換を実行できないときに常に使用される文字です)。

答えは「?」です。これについては深刻な苦情が寄せられています。多くのユーザーは，sjisの81 ca(不签)がcp932の81ca(全宽无符号)になるような「緩い」変換を望んでいます。この動作に変更することが検討されています。

いくつかのバージョンの日本語文字セット(sjisおよびeucの両方)では5度がリバースソリダス（＼.バックスラッシュとも呼ばれます)として扱われ，ほかの文字セットでは円記号(¥)として扱われるため，問題が発生します。

MySQLはJIS(日本工业标准)標準に記述されている1つのバージョンのみに従っています。MySQLでは5度は常にリバースソリダス(＼）です。

理論的には，複数のバージョンのeuckr（扩展Unix代码韩国)文字セットがありますが，認識されている問題は1つだけです。

コードポイント0 x5cがウォン記号（₩であるeuc-krの「KS-Roman」バリアントではなく，コードポイント0 x5cがリバースソリダス(つまり，＼であるeuc-krの「美国信息交换标准代码」バリアントが使用されています。これは，UnicodeのU + 20 a9をeuckrに変換できないことを意味します。

mysql> SELECT -> CONVERT(“创作支援体”USING euckr) AS创作支援体，-> HEX(创作支援体”CONVERT(创作支援体))AS六体;+-------+----------+ | euckr | hexeuckr  | +-------+----------+ | ?| 3 f  | +-------+----------+ 1行集(0.00秒)

説明のために，1つのUnicode (ucs2)カラムおよび1つの中国語(gb2312)カラムを持つテーブルを作成します。

CREATE TABLE ch -> (ucs2 CHAR(3) CHARACTER SET ucs2， -> gb2312 CHAR(3) CHARACTER SET gb2312)查询OK, 0行受影响(0.05秒)

両方のカラムに珍しい文字「汌」を挿入することを試みます。

INSERT INTO ch VALUES ('A汌B'，'A汌B');查询OK, 1行受影响，1警告(0.00秒)

警告が報告されました。次のステートメントを使用してその内容を確認します。

mysql > \ G显示警告  *************************** 1。row ***************************级别:警告代码:1366消息:错误的字符串值:'\xE6\xB1\x8CB'列'gb2312'在行1 1行设置(0.00秒)

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

SELECT ucs2,HEX(ucs2)，gb2312,HEX(gb2312) FROM ch+-------+--------------+--------+-------------+ | ucs2 |十六进制(ucs2) | gb2312 |十六进制(gb2312 ) | +-------+--------------+--------+-------------+ | A汌| 00416 c4c0042 | ?B | 413 f42  | +-------+--------------+--------+-------------+ 1行集(0.00秒)

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

mysqlクライアント(Windows:mysql.exe)を使用してサーバーに直接接続し，同じクエリーをそこで試してください。mysqlが正常に応答する場合,問題はアプリケーションインタフェースで初期化が必要であることである可能性があります。mysqlで显示变量'char%';ステートメント使用して，使用される文字セットを確認します。一个ccess を使用している場合は、Connector/ODBC を使用して接続することがほとんどです。この場合は、配置连接器/ ODBCを確認してください。たとえば，繁体を使用している場合は，设置名称“繁体”と入力します。(この場合「;」は必要ありません)。一个SP を使用している場合は、コードに组名称を追加する必要があることがあります。過去に作成された例を次に示します。

< %会话。CodePage=0 Dim Conn strConnection Dim Conn strConnection="driver={MySQL ODBC 3.51 driver}服务器; uid =用户名" \ & "pwd=密码;数据库=数据库=;支撑集的名字“繁体”;“设置Conn = Server.CreateObject("ADODB.Connection") Conn. open strConnection %>

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

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

<？PHP $link = mysql_connect($host， $usr， $pwd);mysql_select_db ($ db);如果(mysql_error()){打印"数据库错误:"。mysql_error ();} mysql_query("SET NAMES 'utf8'"， $link);? >

この場合，组名称を使用してcharacter_set_client、character_set_connection，およびcharacter_set_resultsを変更しています。

mysqlではなく，新しいmysqli拡張を使用することをお勧めします。mysqliを使用する場合は，前の例を次のように書き直すことができます。

<？mysqli($host， $usr， $pwd， $db);如果(mysqli_connect_errno()) {printf("连接失败:%s\n"， mysqli_connect_error());退出();} $link->查询("SET NAMES 'utf8'");? >

PHPアプリケーションで頻繁に発生する別の問題は，ブラウザによって行われる想定に関連しています。< meta >タグを追加または変更するだけでこの問題が修正されることがあります。たとえば，ユーザーエージェントがページの内容をutf - 8として解釈するようにするには，htmlページの< >头に< meta http-equiv = " - type”内容= " text / html;charset = utf - 8”>を含めてください。

Connector/Jを使用している場合は，使用字符集和Unicodeを参照してください。

MySQLバージョン4.0では，サーバーおよびクライアントの両方のための単一の「グローバル」文字セットがあり，使用する文字の決定はサーバー管理者が行なっていました。これはMySQLバージョン4.1以降で変更されました。現在行われるのは，セクション10.1.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であるとします(cjk地域ではあまりないことですが，これはデフォルト値です)。クライアントのオペレーティングシステムでサポートされている文字セットであるため，クライアントがuse utf8を使用しているとします。latin1をデフォルトの文字セットとしてサーバーを起動します。

mysqld——character-set-server = latin1。中的一个

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

mysql——default-character-set = utf8

現在の設定は，显示变量の出力を表示することによって確認できます。

mysql>显示变量:char%;+--------------------------+----------------------------------------+ | Variable_name |值  | +--------------------------+----------------------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | latin1 |中的一个| character_set_filesystem二进制| | | character_set_results | utf8 | | character_set_server | latin1 |中的一个| character_set_system | utf8 | | character_sets_dir | /usr/local/mysql/share/mysql/charsets/ |+--------------------------+----------------------------------------+ 8行集(0.01秒)

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

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

クライアントをデフォルトの文字セットとしてuse utf8をふたたび指定して起動し，現在の設定を表示します。

mysql>显示变量:char%;+--------------------------+----------------------------------------+ | Variable_name |值  | +--------------------------+----------------------------------------+ | character_set_client | latin1 |中的一个| character_set_connection | latin1 |中的一个| character_set_database | latin1 |中的一个| character_set_filesystem二进制| | | character_set_results | latin1 |中的一个| character_set_server | latin1 |中的一个| character_set_system | utf8 | | character_sets_dir | /usr/local/mysql/share/mysql/charsets/ |+--------------------------+----------------------------------------+ 8行集(0.01秒)

显示变量の異なる結果を比較することによって確認できるように，——skip-character-set-client-handshakeが使用された場合，サーバーはクライアントの初期設定を無視します。

二进制カラムおよび团カラムに対する就像検索には非常に単純な問題があります。文字の終わりを判別する必要があることです。マルチバイト文字セットでは、各文字のオクテット長が異なることがあります。たとえば、use utf8の場合，次に示すように一个は1バイトを必要としますが，ペは3バイトを必要とします。

+-------------------------+---------------------------+ | OCTET_LENGTH (_utf8 A) | OCTET_LENGTH (_utf8ペ ') | +-------------------------+---------------------------+ | 1 | 3  | +-------------------------+---------------------------+ 1行集(0.00秒)

最初の文字の終わりを判別できなければ，2番目の文字が始まる位置を判別できません。この場合，像“_A %”などの非常に単純な検索が失敗します。解決策は,通常のCJK文字セットを最初から使用するか,比較する前にCJK文字を変換することです。

これは，存在しない文字のエンコードをMySQLが許可できない理由の1つです。不正な入力を厳密に拒否しなければ，文字の終わりを判別する方法がありません。

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

簡体字中国語および半角ではない基本的な日本語のかな文字のほとんどは,すべてのCJK文字セットで表示されます。次のストアドプロシージャーは，ucs - 2Unicode文字を受け入れて,それをほかのすべての文字セットに変換し,結果を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;/*如果有一个转换问题，UPDATE将产生一个警告。*/ 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;删除表tj;/ /结束

入力は，単一のucs2文字，またはその文字のコードポイント値(16進表記)です。たとえば，ucs2のエンコードおよび名前についての统一码のリスト(http://www.unicode.org/Public/UNIDATA/UnicodeData.txt)から，カタカナ文字体育はすべてのCJK文字セットにあり，コードポイント値が0 x30daであることがわかります。この値をp_convert ()の引数として使用すると，次のような結果となります。

x30da mysql >调用p_convert (0 )// +------+--------+------+-------+---------+-------+--------+------+------+------+ | ucs2 | utf8 |繁体| cp932 | eucjpms | euckr | gb2312 | gbk | sjis |里头  | +------+--------+------+-------+---------+-------+--------+------+------+------+ | 30 da | E3839A | C772 | 8379 | A5DA为副| | A5DA | A5DA | 8379 | A5DA  | +------+--------+------+-------+---------+-------+--------+------+------+------+ 1行集(0.04秒)

カラム値が3 f(つまり，疑問符文字(?)であるカラムがないため，すべての変換が正常に行われたことがわかります。

utf8_unicode_ci検索やucs2_unicode_ci検索，または命令ソートの結果が，母国語のユーザーが予期する結果ではないことがあります。バグである可能性を除外するわけではありませんが,多くのユーザーはUnicode排序算法の標準表のウェイトを正しく読んでいないことが過去に判明しました。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」表が使用されています)これは,次に示した错误# 16526で報告されたような状況が発生しないように,インデックスに影響する順序付けの変更に非常に慎重であるためです。

CREATE TABLE tj (s1 CHAR(1) CHARACTER SET utf8 COLLATE utf8_unicode_ci)INSERT INTO tj VALUES('が')，('か');SELECT * FROM tj WHERE s1 = 'か';+------+ | s1  | +------+ | が| |か  | +------+ 2行集(0.00秒)

最初の結果行の文字は，検索した文字ではありません。MySQLでその文字が取得されたのはなぜでしょうか。まず，Unicodeのコードポイント値を確認します。これを行うには，ucs2バージョンの文字の16進数を表示します。

SELECT s1, HEX(s1 USING ucs2)) FROM tj;+------+-----------------------------+ | 使用ucs2 s1 |十六进制转换(s1 )) | +------+-----------------------------+ | が| 304 c | |か| 304 b  | +------+-----------------------------+ 2行集(0.03秒)

4.0.0 allkeys表で304 bおよび304 cを探すと，これらの行が見つかります。

304 b;[.1E57.0020.000E。304 b] # HIRAGANA LETTER KA 304C ; [.1E57.0020.000E.304B][.0000.0140.0002.3099] # HIRAGANA LETTER GA; QQCM

正式な统一码名(「＃」マークの後ろにあります)は,日本語の五十音(ひらがな),非公式な区分(文字,数字,または句読点),西洋言語での識別子(卡または遗传算法.これは，たまたま同じ文字のペアの有声音および無声音となっています)を示しています。さらに重要なのは，プライマリウェイト(角括弧の中の最初の16進数)が両方の行で1 e57となっていることです。検索とソートの両方の比較で,MySQLはプライマリウェイトのみに注意を払って,ほかのすべての数値を無視します。これは，“が”および“か”がUnicodeの仕様に従って正しくソートされていることを意味します。これらを区別するには,UCA (Unicode排序算法)以外の照合順序(utf8_binまたはutf8_general_ci)を使用するか，十六进制()値を比較するか，顺序转换(s1使用sjis)を使用する必要があります。もちろん，「Unicodeに従えば」正しいだけでは十分ではなく，バグを報告したユーザーも同様に正しいと言えます。卡/遗传算法のような有声音/無声音文字のペアを順序付けのために区別できる,JIS X 4061標準に従った別の日本語の照合順序を追加する計画があります。

Unicode (ucs2またはuse utf8)を使用していて，统一码のソート順がわかっているが(セクションa。11「MySQL 5.6 FAQ: MySQLの中国語，日本語，および韓国語の文字セット」を参照してください),MySQLでテーブルが間違ってソートされているように見える場合は,まずテーブルの文字セットを確認してください。

mysql >显示创建表t \ G  ******************** 1。row ****************** Table: t Create Table: Create Table ' t ' (' s1 ' char(1) CHARACTER SET ucs2 DEFAULT NULL) ENGINE=MyISAM DEFAULT CHARSET=latin1 row in SET (0.00 sec)

文字セットは正しいように見えるため，このカラムに関してINFORMATION_SCHEMA。列テーブルで表示できる情報を確認します。

从INFORMATION_SCHEMA中选择COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME ->。WHERE COLUMN_NAME = 's1' -> AND TABLE_NAME = 't';+-------------+--------------------+-----------------+ | COLUMN_NAME | CHARACTER_SET_NAME | COLLATION_NAME  | +-------------+--------------------+-----------------+ | s1 | ucs2 | ucs2_general_ci  | +-------------+--------------------+-----------------+ 1行集(0.01秒)

(詳細は，セクション21.4 " information_schema列テーブル"を参照してください.)

照合順序がucs2_unicode_ciではなくucs2_general_ciであることがわかります。このようになる理由は，次のように显示字符集を使用して見つけることができます。

mysql> SHOW CHARSET LIKE 'ucs2%'+---------+---------------+-------------------+--------+ | 字符集| |描述默认排序| Maxlen  | +---------+---------------+-------------------+--------+ | ucs2 | ucs - 2 Unicode | ucs2_general_ci | 2  | +---------+---------------+-------------------+--------+ 1行集(0.00秒)

ucs2およびuse utf8の場合，デフォルトの照合順序は「一般」です。Unicodeの照合順序を指定するには，核对ucs2_unicode_ciを使用します。

MySQL 5.5.3より前では，MySQLは補助文字(つまり，utf - 8で3バイトを超えるサイズを必要とする文字)をサポートしていません。Unicodeで基本多言語面/第 0 面と呼ばれているもののみがサポートされます。いくつかの非常に珍しい漢字のみが補助文字となっています。それらに対するサポートは一般的ではありません。このことがBug #12600などで報告され，「バグではありません」として拒否されました。use utf8では，理解できないバイトが出現した場合に，入力文字列を切り捨てる必要があります。そうしないと，不正なマルチバイト文字の長さがわかりません。

考えられる1つの回避策は，use utf8の代わりにucs2を使用することです。この場合，「不正な」文字は疑問符に置き換えられますが，切り捨ては行われません。妥当性チェックが行われない团または二进制にデータ型を変更することもできます。

MySQL 5.5.3の時点では，追加のUnicode文字セットutf16、utf32，および4バイトのutf8mb4によってUnicodeのサポートが拡張され，補助文字が含まれるようになりました。これらの文字セットでは,基本多言語面(BMP)の外にある補助Unicode文字がサポートされます。

いいえ。用語「CJKV」（中国，日本，朝鲜，越南)は漢字(もともとは中国語)が含まれているベトナム文字セットを指しています。MySQLでは，漢字を使用した古いベトナム文字をサポートする計画はありません。MySQLでは、西洋文字を使用する現代のベトナム文字はもちろんサポートされます。

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

この問題は,対応するディレクトリおよびファイルの名前を自動的に書き換えることによって,MySQL 5.1で修正されました。

たとえば，オペレーティングシステムでディレクトリ名にCJKがサポートされないサーバーに「楮」という名前のデータベースを作成した場合，MySQLはE6A5AE(つまり，「楮」文字のUnicodeの16進表現)を特殊な方法でエンコードした@0w@00a5@00aeという名前のディレクトリが作成されます。ただし，显示数据库ステートメントを実行すると，データベースが「楮」として示されます。

MySQL 5.1.12の簡体字中国語版のマニュアルは，10bet网址 にあります。MySQL 4.1マニュアルの日本語版は，10bet网址 からダウンロードできます。

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