Yakstは、海外の役立つブログ記事などを人力で翻訳して公開するプロジェクトです。
5ヶ月前投稿 修正あり

寿司=ビール問題 : MySQL 8.0でのUTF8サポート入門 (MySQL Server Blogより)

これまでのMySQLでよく問題になった、絵文字や日本語の文字の照合やソート順序の問題に関して、来たるMySQL 8.0では大幅な改善が加えられる予定になっている。この問題の概要と今後の改善方針について、MySQL開発チームからの解説。
原文 Sushi = Beer ?! An introduction of UTF8 support in MySQL 8.0 | MySQL Server Blog (English)
翻訳者 D98ee74ffe0fafbdc83b23907dda3665 doublemarket


免責事項

この記事はManyi Lu氏によるMySQL Server Blogの投稿「Sushi = Beer ?! An introduction of UTF8 support in MySQL 8.0」(2017/1/13)をユーザが翻訳したものであり、Oracle公式の文書ではありません。


MySQL 8.0での私たちの計画として、utf8のサポートを大幅に改善します。utf8サポート自体はMySQL 4.1の頃にさかのぼりますが、いくつかの制限が存在しています。記事タイトルにもある「寿司 = ビール」問題は、バグ#76553のことを指しています。少なくとも私の味覚では、寿司とビールは合いません:-) 過去におけるutf8の問題と、進行中のutf8サポートの計画について説明するために、このバグを例として使おうと思います。

問題その1 utf8mb3とutf8mb4

歴史的な理由から、MySQLではutf8文字セットはutf8mb4ではなくutf8mb3を参照しています。3バイトのutf8文字セットは、Unicodeで定義されている限定された文字、すなわちBMP(basic multi-lingual plane / 基本多言語面)の基本的な文字しかサポートしていません。例として、SMP(supplementary multi-lingual plane / 追加多言語面)に含まれる絵文字その他の文字はサポートしていません。さらに、SIP(supplementary ideographic plane / 追加漢字面)にある中国語の拡張文字(CJK Unified Ideographs Extension B / CJK統合漢字拡張B)もutf8mb3ではカバーされていません。

utf8[mb3]とutf8mb4の違いによる混乱は、後方互換性に対する私たちの要求によって、さらに悪化しています。つまり、utf8を突然utf8mb4にエイリアスするように変更するのは、アップグレード時に新たな問題を生み出す可能性が高いのです。この問題への解決策のひとつは、「utf8」のエイリアスをあるGAバージョンで削除してしまい、後でutf8を意味するエイリアス「utf8mb4」を作ることでしょう。しかし我々の考えは、デフォルト文字セットをutf8mb4に変えてしまうことです。つまり将来的には、ユーザが文字セットを変更しなければならない機会が減ることを期待しています。これにより、utf8mb3とutf8mb4の違いによるインパクトを小さくできるとみています。

問題その2 utf8mb4のデフォルト照合順序

幸いなことに、バグ#76553の報告者がもう問題その1を解明してくれています。彼はutf8mb4文字セットを使っていました。5.7以前でのutf8mb4のデフォルト照合順序は、utf8mb4_general_ciです。これはかなり古い照合順序で、SMPに含まれる文字列全部を同じとして扱ってしまいます!これが寿司 = ビール問題の原因です。utf8mb4_general_ciがutf8文字の中でも限定したものしかサポートしていないのはパフォーマンス上の理由からだと推測しますが、そもそも絵文字あるいはSMP文字は開発時にはあまり一般的には使われていませんでした。

MySQL 5.7では、SMPに含まれる文字を正しく処理できるutf8mb4_unicode_520_ciというずっと新しい照合順序が既に使えるようになっています。寿司ビール問題は、この照合順序に変更することで解決できます。しかしMySQL 8.0では、最新のUnicode標準を元にしたutf8mb4_0900_ai_ciを導入してさらに改善することを決めました。また、これをutf8mb4のデフォルト照合順序にする予定です。

問題その3 ソートのレベル

バグ#76553の報告者にとっては、問題はまだすべて解決したわけではありません。utf8mb4_unicode_520_ciもutf8_0900_ai_ciも、ハハパパ問題は解決してくれません。MySQLは「ハ」(U+30CF カタカナのハ)、「パ」(U+30D1 カタカナのパ)、「バ」(U+30D0 カタカナのバ)を別の文字であると認識してくれないのです。

この問題を理解するには、標準規格で定められたソートのレベルに注目する必要があります。

  • 1次レベル : 基本文字の違いを表すために使われます(例、 “a” < “b”)
  • 2次レベル : アクセント(例、 “as” < “às” < “at”)
  • 3次レベル : 大文字小文字の違い(例、 “ao” < “Ao”< “aò”)

これらの文字を区別する前は、2次レベルまでが必要でしたが、日本語の文字の多くは実際には3次レベルのソートが必要になります。

MySQL 5.7以前のバージョンでは、1次レベルでのソートや比較のみがサポートされていました。MySQL 8.0には、2次及び3次レベルのソートが必要な、アクセントや大文字小文字を区別する照合順序を追加します。これには、例えばデンマーク語のアクセントや大文字小文字を区別する照合順序であるutf8mb4_0900_danish_as_csが含まれます。デンマーク語の照合順序には、デンマーク語特有で他の言語では使えないソートのルールが含まれるのです。

私たちは日本語の照合順序の追加も計画中です。日本語は興味深い言語であり、私たちの照合順序のエキスパートであるXing ZhangとBernt Marius Johnsenが、今後のブログ記事でもっと詳しく説明するはずです。

要約すると、私たちの計画では、デフォルト文字セットをutf8mb4に変えることで大幅にutf8のサポートを改善します。そして、MySQLの国際的なユーザ基盤に有益な多くの照合順序を追加します。

今後も最新の情報に注意してください。これは、文字セットや照合順序についての知識を共有し、私たちのロードマップに関する真相を伝え、アップグレードなどの実際について議論するブログのシリーズの最初の記事でしかありません。

MySQLを使ってくれてありがとうございます!

Manyi

次の記事
SaaSアプリケーション向けのMySQLシャーディングモデル
前の記事
RethinkDBはなぜ失敗したのか

Feed small 記事フィード