mysql

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での文字列比較結果です: 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) | [ more… ]

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’が最初となります。では残りの‘あ’, ‘ア’, ‘ｱ’はどうなるでしょうか？ここでは以下のルールが適用されます: ‘&あ<<<<ア=ｱ’ 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文字は定義されていません。 mysql> [ more… ]

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.… Source: Protecting Data with Digital Signatures by Example using MySQL Enterprise Edition

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.… Source: MySQL 8.0: Kana-sensitive collation for Japanese

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.… Source: Debugging Character Set Issues by Example