Category Archives: CJK

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での文字列比較結果です:

この結果から
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’が最初となります。では残りの‘あ’, ‘ア’, ‘ア’はどうなるでしょうか?ここでは以下のルールが適用されます: ‘&あ<<<<ア=ア’

なぜ‘あ’, ‘ア’, ‘ア’は等価なのでしょうか?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 8.0におけるUTF-8の改良に関する記事をこれまでにも公開しております。以下の記事についてもぜひご参照下さい。

Sushi = Beer ?! An introduction of UTF8 support in MySQL 8.0

In MySQL 8.0 our plan is to drastically improve support for utf8. While utf8 support itself dates back to MySQL 4.1, there exist some limitations. The “sushi = beer” problem in the title refers to Bug #76553. Sushi and beer don’t even go well together, at least not to my taste:-) I will use this bug as an example to explain issues with utf8 collations in the past and our plans for utf8 support going forward.…

InnoDB 전문 검색 : N-gram Parser

기본 InnoDB 전문 검색(Full Text) 파서는 공백이나 단어 분리자가 토큰인 라틴 기반 언어들에서는 이상적이지만 개별 단어에 대한 고정된 구분자가 없는 중국어, 일본어, 한국어(CJK)같은 언어들에서는 각 단어는 여러개의 문자들의 조합으로 이루어집니다. 그래서 이경우엔 단어 토큰들을 처리할 수 있는 다른 방법이 필요합니다.…