MySQL :: MySQL 8.0 リファレンスマニュアル :: 10.9.8 3 バイト Unicode 文字セットと 4 バイト Unicode 文字セット間の変換

version 8.0

9.1 English
9.0 English
8.4 English
8.0 English
5.7 English

MySQL 8.0 リファレンスマニュアル / ... / 3 バイト Unicode 文字セットと 4 バイト Unicode 文字セット間の変換

このページは機械翻訳したものです。

10.9.8 3 バイト Unicode 文字セットと 4 バイト Unicode 文字セット間の変換

このセクションでは、utf8mb3 と utf8mb4 の文字セット間で文字データを変換する際に発生する可能性のある問題について説明します。

注記

この説明では、主に utf8mb3 と utf8mb4 の間の変換に焦点を当てていますが、ucs2 文字セットと utf16 や utf32 などの文字セットの間の変換にも同様の原則が適用されます。

utf8mb3 と utf8mb4 の文字セットは、次の点で異なります:

utf8mb3 では、Basic Multilingual Plane (BMP) の文字のみがサポートされます。utf8mb4 では、BMP の外部にある補助文字もサポートされます。
utf8mb3 では、文字当たり最大 3 バイトが使用されます。utf8mb4 では、文字当たり最大 4 バイトが使用されます。

注記

この説明では、3 バイトおよび 4 バイトの UTF-8 文字セットデータの参照に関する明示的な utf8mb3 および utf8mb4 文字セット名について説明します。ただし、テーブル定義では、utf8 が使用されるのは、このような定義で指定された utf8mb3 のインスタンスが、utf8mb3 のエイリアスである utf8 に MySQL によって変換されるためです。

utf8mb3 から utf8mb4 に変換する利点の 1 つは、アプリケーションで補助文字を使用できることです。 1 つのトレードオフは、これによってデータストレージ領域要件が増加する可能性があることです。

テーブルの内容に関しては、utf8mb3 から utf8mb4 への変換で問題は発生しません:

BMP 文字の場合、utf8mb4 と utf8mb3 のストレージ特性は同じです: 同じコード値、同じエンコーディング、同じ長さ。
補助文字の場合、utf8mb4 ではそれを格納するために 4 バイトが必要ですが、utf8mb3 では文字を格納できません。 utf8mb3 カラムを utf8mb4 に変換する場合、補助文字がないため、変換の心配は必要ありません。

テーブル構造に関して、主な潜在的な非互換性は次のとおりです:

可変長文字データ型 (VARCHAR および TEXT 型) の場合、utf8mb4 カラムに許可される最大長は utf8mb3 カラムより少なくなります。
すべての文字データ型 (CHAR、VARCHAR および TEXT 型) について、utf8mb4 カラムでインデックス付けできる最大文字数は utf8mb3 カラムより少なくなります。

したがって、テーブルを utf8mb3 から utf8mb4 に変換するには、一部のカラムまたはインデックスの定義の変更が必要になる場合があります。

テーブルは、ALTER TABLE を使用して utf8mb3 から utf8mb4 に変換できます。テーブルに次の定義があるとします:

CREATE TABLE t1 (
  col1 CHAR(10) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
  col2 CHAR(10) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL
) CHARACTER SET utf8;

次のステートメントは、utf8mb4 を使用するように t1 を変換します。

ALTER TABLE t1
  DEFAULT CHARACTER SET utf8mb4,
  MODIFY col1 CHAR(10)
    CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  MODIFY col2 CHAR(10)
    CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL;

utf8mb3 から utf8mb4 への変換時のキャッチは、bytes に関してカラムまたはインデックスキーの最大長が変更されないことです。そのため、文字の最大長が 3 ではなく 4 なので、文字の点ではこれはより小さくなります。 CHAR、VARCHAR および TEXT データ型の場合は、MySQL テーブルを変換する際に次の問題を確認してください:

utf8mb3 カラムのすべての定義をチェックし、ストレージエンジンの最大長を超えていないことを確認します。
utf8mb3 カラムのすべてのインデックスをチェックし、ストレージエンジンの最大長を超えていないことを確認します。最大値は、ストレージエンジンの機能強化によって変更されることがあります。

前述の条件が適用される場合は、定義されているカラムまたはインデックスの長さを減らすか、utf8mb4 ではなく utf8mb3 を引き続き使用する必要があります。

次に、構造的な変更が必要な例をいくつか示します。

TINYTEXT カラムは、最大 255 バイトを保持できるので、3 バイトの文字は 85 個まで、4 バイトの文字は 63 個まで保持できます。 utf8mb3 を使用する TINYTEXT カラムがあるが、63 文字を超えることができる必要があるとします。データ型も TEXT などのより長い型に変更しないかぎり、これを utf8mb4 に変換できません。

同様に、utf8mb3 から utf8mb4 に変換する場合は、非常に長い VARCHAR カラムを長い TEXT 型のいずれかに変更する必要があります。
InnoDB では、COMPACT または REDUNDANT の行形式を使用するテーブルのインデックスの最大長は 767 バイトであるため、utf8mb3 または utf8mb4 のカラムでは、それぞれ 255 文字または 191 文字までインデックス付けできます。 191 文字を超えるインデックスを持つ utf8mb3 カラムが現在ある場合は、インデックス付けする文字数を減らす必要があります。

COMPACT または REDUNDANT の行形式を使用する InnoDB テーブルでは、次のカラムおよびインデックスの定義が有効です:
```
col1 VARCHAR(500) CHARACTER SET utf8, INDEX (col1(255))
```
代わりに utf8mb4 を使用するには、インデックスをより小さくする必要があります。
```
col1 VARCHAR(500) CHARACTER SET utf8mb4, INDEX (col1(191))
```
注記

COMPRESSED または DYNAMIC の行形式を使用する InnoDB テーブルの場合、767 バイト (最大 3072 バイト) を超える index key prefixes が許可されます。これらの行フォーマットを使用して作成されたテーブルでは、utf8mb3 カラムまたは utf8mb4 カラムに対してそれぞれ最大 1024 文字または 768 文字をインデックス付けできます。関連情報については、セクション15.22「InnoDB の制限」,およびDYNAMIC 行フォーマットを参照してください。

前述の変更のタイプは、非常に長いカラムまたはインデックスを持つ場合にのみ必要になる可能性が高くなります。それ以外の場合は、前述の ALTER TABLE を使用して、問題なくテーブルを utf8mb3 から utf8mb4 に変換できます。

次の項目は、その他の潜在的な非互換性をまとめたものです:

SET NAMES 'utf8mb4' では、接続文字セットに対して 4 バイトの文字セットを使用する必要があります。 4 バイト文字がサーバーから送信されていないかぎり、問題は起こりません。それ以外の場合は、文字ごとに最大 3 バイトの受信を要求するアプリケーションで問題が発生する可能性があります。反対に、4 バイトの文字の送信を要求するアプリケーションは、その文字がサーバーで認識されることを確認する必要があります。
レプリケーションでは、補助文字をサポートする文字セットをソースで使用する場合、すべてのレプリカもそれらを理解する必要があります。

また、ソースとレプリカでテーブルの定義が異なる場合、予期しない結果が発生する可能性があることにも注意してください。たとえば、インデックスキーの最大長が異なると、ソースで utf8mb3 を使用し、レプリカで utf8mb4 を使用するリスクがあります。

utf8mb4, utf16, utf16le または utf32 に変換し、utf8mb3 または ucs2 に変換しなおすことにした場合 (古いバージョンの MySQL にダウングレードする場合など)、次の考慮事項が適用されます:

utf8mb3 および ucs2 データに問題はありません。
サーバーは、変換元の文字セットを参照する定義を認識するのに十分な最新の状態である必要があります。
utf8mb4 文字セットを参照するオブジェクト定義の場合、ダウングレード前に mysqldump でダンプし、ダンプファイルを編集して utf8mb4 のインスタンスを utf8 に変更し、データに 4 バイト文字がないかぎり、古いサーバーでファイルをリロードできます。古いサーバーでは、ダンプファイルのオブジェクト定義に utf8 が表示され、(3 バイト)utf8 文字セットを使用する新しいオブジェクトが作成されます。

PREV HOME UP NEXT