MySQL 5.6 introduced the fractional second precision for temporal data types – TIME, DATETIME, and TIMESTAMP, with up to microseconds (6 digits) precision. Along with providing fractional second precision, the new implementation for temporals is disk efficient.
MySQL 8.0: ひらがなカタカナを判別する日本語用Collation
以前の記事では、MySQL 8.0.1で導入された新しい 日本語のutf8bm4のCollation(文字照合順)について ご紹介しました。このcollation (utf8mb4_ja_0900_as_cs) は、CLDR 30で定義されたアクセント記号(清音濁音半濁音)ならびに大文字小文字(拗音促音など)を判別する実装となっています。
今日ご紹介するのはひらがなカタカナを判別できる新しい「かなセンシティブ」なCollation utf8mb4_ja_0900_as_cs_ksです。DUCETではひらがながカタカナよりも前にソートされるように3次レベルの重みを定義しています。例えば:
3042 ; [.3D5A.0020.000E] # HIRAGANA LETTER A
30A2 ; [.3D5A.0020.0011] # KATAKANA LETTER A
2次レベルでの違い(000E および 0011)によって 0x3042 (あ) < 0x30A2 (ア) となります。CLDRではひらがなとカタカナの違いは4次レベル(例: &あ<<<<ア)で比較するよう定義されています。デフォルトの比較レベルは3次レベル(強さ 3)となっており、最初の3次レベルでみると同じとなります。
utf8mb4_ja_0900_as_cs_ksについて
utf8mb4_ja_0900_as_csに対していただいたフィードバックにお応えする形で、ひらがなとカタカナを判別する新しいCollationである utf8mb4_ja_0900_as_cs_ks を追加することにしました。ここでの’_ks’は「かなセンシティブ Kana Sensitive」を意味しています。
このCollationは最初の3次レベルまでが同じひらがなとカタカナの判別に必要となる4次レベルでの処理を行います。以下の例では、utf8mb4_ja_0900_as_cs および utf8mb4_ja_0900_as_cs_ks のそれぞれのCollationでの文字列比較結果です:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 |
mysql> SET @s1 = CONVERT('きゅう' USING utf8mb4); Query OK, 0 rows affected (0.01 sec) mysql> SET @s2 = CONVERT('キュウ' USING utf8mb4); Query OK, 0 rows affected (0.00 sec) mysql> SET @s3 = CONVERT('きゆう' USING utf8mb4); Query OK, 0 rows affected (0.00 sec) mysql> SET @s4 = CONVERT('キユウ' USING utf8mb4); Query OK, 0 rows affected (0.00 sec) mysql> SELECT STRCMP(@s1 COLLATE utf8mb4_ja_0900_as_cs, @s2); +------------------------------------------------+ | STRCMP(@s1 COLLATE utf8mb4_ja_0900_as_cs, @s2) | +------------------------------------------------+ | 0 | +------------------------------------------------+ 1 row in set (0.00 sec) mysql> SELECT STRCMP(@s2 COLLATE utf8mb4_ja_0900_as_cs, @s3); +------------------------------------------------+ | STRCMP(@s2 COLLATE utf8mb4_ja_0900_as_cs, @s3) | +------------------------------------------------+ | -1 | +------------------------------------------------+ 1 row in set (0.00 sec) mysql> SELECT STRCMP(@s3 COLLATE utf8mb4_ja_0900_as_cs, @s4); +------------------------------------------------+ | STRCMP(@s3 COLLATE utf8mb4_ja_0900_as_cs, @s4) | +------------------------------------------------+ | 0 | +------------------------------------------------+ 1 row in set (0.00 sec) mysql> SELECT STRCMP(@s1 COLLATE utf8mb4_ja_0900_as_cs_ks, @s2); +---------------------------------------------------+ | STRCMP(@s1 COLLATE utf8mb4_ja_0900_as_cs_ks, @s2) | +---------------------------------------------------+ | -1 | +---------------------------------------------------+ 1 row in set (0.00 sec) mysql> SELECT STRCMP(@s2 COLLATE utf8mb4_ja_0900_as_cs_ks, @s3); +---------------------------------------------------+ | STRCMP(@s2 COLLATE utf8mb4_ja_0900_as_cs_ks, @s3) | +---------------------------------------------------+ | -1 | +---------------------------------------------------+ 1 row in set (0.01 sec) mysql> SELECT STRCMP(@s3 COLLATE utf8mb4_ja_0900_as_cs_ks, @s4); +---------------------------------------------------+ | STRCMP(@s3 COLLATE utf8mb4_ja_0900_as_cs_ks, @s4) | +---------------------------------------------------+ | -1 | +---------------------------------------------------+ 1 row in set (0.00 sec) |
この結果から
utf8mb4_ja_0900_as_csでは‘きゅう’ = ‘キュウ’ < ‘きゆう’ = ‘キユウ’
utf8mb4_ja_0900_as_cs_ksでは‘きゅう’ < ‘キュウ’ < ‘きゆう’ < ‘キユウ’
となることが確認できました。
まとめ
この新しいCollationは Labs release (実験室版) のMySQL 8.0.1にて動作確認いただけます。またMySQL 8.0.2にて標準機能として利用可能となる予定です。
ぜひお試しいただきフィードバックをお送りいただければと思います。…
MySQL8.0: 日本語のutf8bm4のCollation(文字照合順)
MySQL 8.0.1では、utf8mb4の大文字小文字およびアクセント記号付きの文字を判別するas_cs collationに加えて、日本語用のCollation(文字照合順)を追加しました。
utf8mb4_ja_0900_as_csについて
日本語に関する文字照合およびソートのルールは複雑です。日本語ではひらがな、カタカナ、漢字、アルファベット(ラテン文字)を混在させて利用しています。さらに、全角と半角が存在する文字もあります。では、‘あ’, ‘ア’, ‘a’, ‘ｱ’はどのようにソートされるのでしょうか？
Unicode照合アルゴリズム(UCA / Unicode Collation Algorithm)の中で規定されているデフォルトUnicode照合基本テーブル(DUCET / Default Unicode Collation Element Table)にてUnicode文字列の比較アルゴリズムを定義しています。このDUCETは言語ごとにカスタマイズされた情報をXML形式で提供する共通ロケールデータリポジトリ(CLDR, Common Locale Data Repository)にて、日本語に関するソート順を定義した部分[reorder Latn Kana Hani]での日本語に関するソート順のルールによると、ラテン文字は全てのひらがなやカタカナよりも前に位置づけられているため‘a’が最初となります。では残りの‘あ’, ‘ア’, ‘ｱ’はどうなるでしょうか？ここでは以下のルールが適用されます: ‘&あ<<<<ア=ｱ’
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
mysql> set names utf8mb4; Query OK, 0 rows affected (0.00 sec) mysql> select strcmp('a', 'あ' collate utf8mb4_ja_0900_as_cs); +--------------------------------------------------+ | strcmp('a', 'あ' collate utf8mb4_ja_0900_as_cs) | +--------------------------------------------------+ | -1 | +--------------------------------------------------+ 1 row in set (0.00 sec) mysql> select strcmp('あ', 'ア' collate utf8mb4_ja_0900_as_cs); +----------------------------------------------------+ | strcmp('あ', 'ア' collate utf8mb4_ja_0900_as_cs) | +----------------------------------------------------+ | 0 | +----------------------------------------------------+ 1 row in set (0.00 sec) mysql> select strcmp('ア', 'ｱ' collate utf8mb4_ja_0900_as_cs); +----------------------------------------------------+ | strcmp('ア', 'ｱ' collate utf8mb4_ja_0900_as_cs) | +----------------------------------------------------+ | 0 | +----------------------------------------------------+ 1 row in set (0.00 sec) |
なぜ‘あ’, ‘ア’, ‘ｱ’は等価なのでしょうか？UCAではマルチレベルの比較アルゴリズムを使用して照合を個なっています。この比較アルゴリズムの4次レベルでは‘あ’が‘ア’よりも前に来るとされているにも関わらずです。ポイントはCLDRでは日本語の文字照合順の強度は3次レベルであると定義されています。従って4次レベルでの差は無視されることとなります。これはユーザーの期待した挙動ではないかもしれません。そこで我々は日本語を扱うMySQLユーザーの要望をもとにしたCollationをMySQL 8.0に追加することを検討しています。
日本工業規格の一つJIS X 0208 (http://www.jisc.go.jp/app/pager?id=94516)では、日本語の漢字6,355文字とそのソート順について定義しています。utf8mb4_ja_0900_as_csはこのJIS X 0208に準じた漢字のソートを行います。しかしこのJIS X 0208では含まれない漢字も多数存在します。これらの漢字についてutf8mb4_ja_0900_as_csはUCA(Unicode Collation Algorithm)で定義されたそれぞれの文字の重み(implicit weight) (http://www.unicode.org/reports/tr10/#Implicit_Weights)を利用します。
以下の文字を例にソート順を確認してみます: ‘王’, ‘人’, ‘兵’, ‘﨎’, ‘㐀’
最初の3文字はJIS X 0208で定義されていますが、残りの2文字は定義されていません。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
mysql> create table jpn(a varchar(10)) collate utf8mb4_ja_0900_as_cs; Query OK, 0 rows affected (0.90 sec) mysql> insert into jpn values ('王'), ('﨎'), ('人'), ('㐀'), ('兵'); Query OK, 5 rows affected (0.05 sec) Records: 5 Duplicates: 0 Warnings: 0 mysql> select a from jpn order by a; +------+ | a | +------+ | 王 | | 人 | | 兵 | | 﨎 | | 㐀 | +------+ 5 rows in set (0.02 sec) |
まとめ
この記事以外にもMySQL 8.0におけるUTF-8の改良に関する記事をこれまでにも公開しております。以下の記事についてもぜひご参照下さい。
…Protecting Data with Digital Signatures by Example using MySQL Enterprise Edition
Often databases contain data that needs to be proven as valid and authentic. We want to ensure that a known person or other sender (e.g. a trusted app) of the information can’t deny content, nor that the content can change without that person (senders) consent.…
MySQL 8.0: Kana-sensitive collation for Japanese
In my previous post, I wrote about the new Japanese collation for utf8mb4 introduced in MySQL 8.0.1! This collation (utf8mb4_ja_0900_as_cs) implements accent / case sensitivity for Japanese as defined by CLDR 30.
Today, I am writing about our new utf8mb4_ja_0900_as_cs_ks collation which includes support for kana sensitivity.…
Debugging Character Set Issues by Example
In a world moving towards Unicode and UTF-8, a lot of applications still use some one-byte character set. And since one-byte characters usually accepts any byte in the range 0x00-0xFF it often works well to store and retrieve any data in such character strings, e.g.…
MySQL 8.0: New mysql-test-run option to minimize skipped tests in regression test runs
Anybody who has run the MySQL MTR test suite must have seen a statement like “x tests were skipped, y by the test itself. ” at the end of test runs. Why are some tests being skipped? Are the skipped tests affecting test coverage?…
Hybrid Data Encryption by Example using MySQL Enterprise Edition
Sharing keys, passphrases with applications is problematic, especially with regard to encrypting data. Too often applications are developed where “the keys are left in the door” or at best “under the mat” – hard coded, in a clear text property file… exposed and vulnerable. …
MySQL 8.0: Retiring Support for the Query Cache
As Rene wrote on the ProxySQL blog yesterday:
Although MySQL Query Cache was meant to improve performance, it has serious scalability issues and it can easily become a severe bottleneck.
This is indeed something we have observed in the MySQL team for a while.…
MySQL 8.0 MTR: ‘require’, is now an invalid mysqltest command
Some of the users may have noticed that .require files do not exist anymore in the MySQL test suite.
A .require is file is used along with 'require' mysqltest command. In test cases, the command 'require' is used to ensure MTR performs certain sanity checks.…