問題の核心は、MySQLの「utf8」が実際にはUTF-8ではないことです
「utf8」は文字あたり最大3バイトのみをサポートしますが、真のUTF-8は文字あたり最大4バイトです。
MySQLはこのバグを修正していませんが、この問題を回避するために2010年に「utf8mb4」という文字セットをリリースしました。
もちろん、彼らは新しい文字セットを宣伝していなかったため（おそらくこのバグが恥ずかしいため）、開発者はインターネット上で「utf8」を使用することを依然として推奨されていますが、これらの提案は間違っています。
次のように簡単に要約
1. MySQLの「utf8mb4」は、実際の「UTF-8」です。
2. MySQLの「utf8」は一種の「排他的エンコーディング」であり、多くのUnicode文字をエンコードできません。
ここで明確にしたいと思います。 「utf8」を使用しているすべてのMySQLおよびMariaDBユーザーは、「utf8」ではなく「utf8mb4」を使用する必要があります。**
では、コーディングとは何でしょうか？UTF-8とは何ですか？
コンピューターは0と1を使用してテキストを格納することを私たちは皆知っています。たとえば、文字「C」は「01000011」として格納されているため、この文字を表示するときに、コンピュータは2つの手順を実行する必要があります。
1. コンピューターは "01000011"を読み取り、67は "01000011"としてエンコードされているため、数値67を取得します。
2. コンピューターは、ユニコード文字セットで67を検索し、「C」を見つけます。
同じ
1. コンピュータが "C"をUnicode文字セットの67にマップします。
2. 私のコンピュータは67を "01000011"にエンコードし、それをWebサーバーに送信します。
他の文字セットを使用する理由がないため、ほとんどすべてのWebアプリケーションはUnicode文字セットを使用します。
Unicode文字セットには数百万の文字が含まれています。最も単純なエンコーディングはUTF-32で、文字ごとに32ビットを使用します。コンピュータは常に32ビットを数値と見なしており、コンピュータが最も得意とするのは数値を処理するため、これが最も簡単です。しかし問題は、これがスペースの無駄であることです
UTF-8ではスペースを節約できます。UTF-8では、文字「C」は8ビットのみを必要とし、「」などの一部の一般的でない文字は32ビットを必要とします。他の文字は16ビットまたは24ビットを使用できます。このような記事は、UTF-8エンコーディングを使用する場合、UTF-32の約4分の1しか占めません。
MySQLの「utf8」文字セットは他のプログラムと互換性がありません。いわゆる「」は実際には少し...
MySQLの簡単な歴史
MySQL開発者が「utf8」を無効にしたのはなぜですか？ 提出ログで回答を見つけることができる場合があります。
MySQLは2003年のバージョン4.1以降、UTF-8をサポートしており、現在使用されているUTF-8標準（RFC 3629）はそれ以降です。
古いUTF-8標準（RFC 2279）は、文字ごとに最大6バイトをサポートします。2002年3月28日、MySQL開発者は最初のMySQL 4.1プレビューでRFC 2279を使用しました。MySQLデータベースによって開発された36の軍事規制、これは覚えておく必要があります。
9月には、彼らは、MySQLのソースコードの調整をした：「アップは今だけ3バイトのUTF8シーケンスをサポートするために」 。
これらのコードを提出したのは誰ですか？なぜ彼はこれをしたのですか？この質問は不明です。Gitに移行した後（MySQLは最初にBitKeeperを使用しました）、MySQLコードベースの多くのコミッターの名前が失われました。2003年9月のメーリングリストでは、この変更を説明する手がかりはありませんでした。
しかし、私は推測することができます
2002年に、MySQLは決定を下しました。ユーザーがデータテーブルの各行が同じバイト数を使用することを保証できる場合、MySQLはパフォーマンスを大幅に改善できます。
このため、ユーザーはテキスト列を「CHAR」として定義する必要があります。各「CHAR」列には常に同じ数の文字があります。挿入された文字の数が定義された数より少ない場合、MySQLはその後のスペースを埋め、挿入された文字が定義された数を超える場合、超過分は切り捨てられます。
MySQL開発者は、最初にUTF-8を試したときに1文字あたり6バイト、CHAR（1）に6バイト、CHAR（2）に12バイトを使用しました。
最初の動作は正しかったと言わなければなりませんが、残念ながらこのバージョンはリリースされていません。しかし、これは文書に書かれており、広く流通しています。UTF-8を知っている人は誰でも、文書に書かれている内容に同意します。
1. CHARを使用して列を定義します（その観点から、CHARはすでに古いアンティークですが、現時点ではMySQLでCHARを使用する方が高速ですが、2005年以降はそうではありません）。
2. CHAR列のエンコーディングを「utf8」に設定します。
私の推測では、MySQL開発者は元々、スペースと速度の双方にメリットのあるユーザーを支援したいと考えていましたが、「utf8」コーディングを台無しにしました。
したがって、結果は勝者ではありません。「utf8」のCHAR列を使用すると、スペースと速度の双方にメリットがあるユーザーは、実際には予想よりも多くのスペースを使用し、速度は予想よりも遅くなります。正確さを求めるユーザーは、「utf8」エンコーディングを使用すると、「」のような文字を保存できません。
この不正な文字セットがリリースされた後、すべてのユーザーがデータベースを再構築する必要があったため、MySQLはそれを修正できませんでした。最終的に、MySQLは2010年に「utf8mb4」を再リリースし、真のUTF-8をサポートしました。
なぜこれが人をそんなに狂わせるのか
この問題のために、私は一週間頭がおかしくなりました。私は「utf8」にだまされて、このバグを見つけるのに長い時間がかかりました。しかし、インターネット上のほとんどすべての記事は、「utf8」を実際のUTF-8と見なしています。
「utf8」は独自の文字セットと見なすことができるだけであり、新しい問題をもたらしますが、解決されていません。
