mysql_MySQL の utf8 と utf8mb4 の違いを包括的に理解する

1. はじめに

MySQL は 5.5.3 以降に utf8mb4 エンコーディングを追加しました。mb4 はほとんどのバイト 4 を意味し、4 バイトの Unicode と互換性があるように特別に設計されています。幸いなことに、utf8mb4 は utf8 のスーパーセットであり、エンコーディングを utf8mb4 に変更する以外に他の変換は必要ありません。もちろん、スペースを節約するには、通常は utf8 を使用するだけで十分です。

2. コンテンツの説明

上で述べたように、utf8 はほとんどの中国語文字を格納できるのに、なぜ utf8mb4 を使用する必要があるのでしょうか? mysql でサポートされている utf8 エンコーディングの最大文字長は 3 バイトであることがわかりました。4 バイトのワイド文字が発生すると、例外が発生します。挿入されます。 3 バイト UTF-8 でエンコードできる最大 Unicode 文字は 0xffff で、これは Unicode の Basic Multilingual Plane (BMP) です。言い換えれば、基本的なマルチテキスト プレーンにない Unicode 文字は、Mysql の utf8 文字セットを使用して保存することはできません。絵文字表現 (絵文字は特別な Unicode エンコーディングであり、iOS や Android スマートフォンで一般的に見られます)、多くの珍しい漢字、および新しい Unicode 文字などが含まれます。

3. 問題の根源

元の UTF-8 形式は 1 ～ 6 バイトを使用し、最大 31 文字をエンコードできます。最新の UTF-8 仕様では、1 ～ 4 バイトのみを使用し、最大 21 ビットをエンコードできます。これは、17 の Unicode プレーンすべてを表すのにちょうど十分です。

utf8 は、Unicode の基本的なマルチテキスト プレーンである、最大 3 バイトの UTF-8 文字のみをサポートする Mysql の文字セットです。

Mysql の utf8 は、最大長が 3 バイトの UTF-8 文字のみをサポートするのはなぜですか?おそらく、Mysql が最初に開発され始めたとき、Unicode には補助プレーンがなかったからだと思います。当時、Unicode 委員会はまだ「全世界には 65535 文字で十分である」という夢を抱いていました。 Mysql の文字列の長さは、バイトではなく文字数として計算されます。CHAR データ型の場合、文字列用に十分な長さを確保する必要があります。 utf8 文字セットを使用する場合、予約する必要がある長さは、utf8 の最長文字長に文字列長を乗算したものになります。したがって、当然、utf8 の最大長は 3 に制限されます。たとえば、CHAR(100) Mysql は予約します。 300バイト。後続のバージョンが 4 バイト長の UTF-8 文字をサポートしない理由については、1 つは下位互換性を考慮したためであり、もう 1 つは基本的な多言語プレーン以外の文字はほとんど使用されないためだと思います。

4 バイト長の UTF-8 文字を Mysql に保存するには、utf8mb4 文字セットを使用する必要がありますが、これはバージョン 5.5.3 以降でのみサポートされます (バージョンを確認してください: select version();)。より良い互換性を得るには、常に utf8 ではなく utf8mb4 を使用する必要があると思います。 CHAR 型データの場合、Mysql 公式の推奨に従って、UTF8MB4 は CHAR の代わりに VARCHAR を使用します。

上記の記事は、mysql の utf8 と utf8mb4 の違いを包括的に理解するものであり、エディターが共有する内容のすべてです。参考にしていただければ幸いです。