文字数の話の続き〜Unicodeの楽しくない話〜

Slide 1

Slide 1 text

文字数の話の続き Unicodeの楽しい話

Slide 2

Slide 2 text

自己紹介 t 名前: しゅん t Twitter: @shun_shobon / GitHub: @shun-shobo t 学校: 長野高専電子情報工学科 5F t 得意: Web Frontend / Web Frontend Ops / A11y なE t 研究: ホログラフィ・ヒューマンインタフェースなE t 趣味: PCゲーム・自作キーボーd t 一言: コンピュータと人との関わり方を模索しています

Slide 3

Slide 3 text

Kloud L Tで話したUnicode の話の続きになります

Slide 4

Slide 4 text

前回のあらすじ

Slide 5

Slide 5 text

Unicodeの目的 Unicodeは全ての文字にユニークなIDを降ること目的としている．このユニークなIDのことをUnicodeでは Code Point(コードポイント) と呼ぶ．チ → U+30C1 ゃ → U+3083 𠮟 → U+20B9F ！ → U+FF01

Slide 6

Slide 6 text

Code Pointの符号化方法このCode Pointを相手に送る際には，特定の方式によってバイナリにすることで送信される．これにはいくつかの方式がある． j UTF-32 … どのCode Pointも4Byteで表r j UTF-16 ... 小さなCode Pointは2Byte，大きいのは4Byty j UTF-8 ... なるべく小さなByteになるように1〜4Byteで表す ※ものすごい雑な解説なので詳しくは調べてください

Slide 7

Slide 7 text

JSの.lengthの挙動 JSの.lengthは文字列の内部表現であるUTF-16の2byte配列の要素数を数えているだけ． 4byteで表現される「𠮟」があるため，11文字だけど要素数が12なので.lengthは12を返す．

Slide 8

Slide 8 text

StringのIteratorを使う Stringがネイティブに実装しているIteratorの処理はCode Point単位で処理される． IteratorベースのSpread演算子を使えばCode Point単位に文字列を分割できる！

Slide 9

Slide 9 text

1Code Point = 1文字ではない

Slide 10

Slide 10 text

異体字セレクタという存在 Unicodeには漢字や絵文字のバリエーションを表す異体字セレクタというものがある．例えば「葛」と「葛󠄀」の違いや，「」と「」の違いなど．つまりCode Pointの数と直感的な文字数が一致しない場合がある．これらは基本となる文字にCode Pointを定義して，その文字の後に異体字セレクタという別のCode Pointをつけることによって表現される．

Slide 11

Slide 11 text

結合文字列という存在意味的にはこの2つは等しいため，検索などでこの2つを異なる扱いをしてしまうと，直感に反する可能性がある． Unicodeには結合文字列という，複数のCode Pointを使って1文字を表現することがある．例えば「が」は，「U+304C」と「U+304B, U+3099」の2通りの表し方がある．

Slide 12

Slide 12 text

絵文字の合字合字とは「f」を2回重ねたときに「ff」のように2つがくっついた状態で表示されること．一部の絵文字はこの合字を利用して複雑な絵文字を表現している場合がある．それぞれの絵文字の間にZero Width Joiner(U+200D)という不可視の文字を入れることによってその絵文字は合成されているということを表す． ※Zero Width Joinerを使わないで合成される場合もあり(一部の国旗の絵文字など)

Slide 13

Slide 13 text

自然な区切りを表す書記素クラスタこれまで見てきたように，Code Point単位で見ても異体字セレクタや結合文字，合字などの概念によってUnicodeにおける「1文字」というのはかなり表現するのが難しい．それに「1文字」という表現は非常に曖昧で，Byte単位なのか，Code Point単位なのか，「いわゆる直感的な1文字」なのかが分かりづらい．そこで，「いわゆる直感的な1文字」をUnicodeでは書記素クラスタと呼んでいる．書記素クラスタでの分割アルゴリズムはUnicodeの仕様として標準化されており，この仕様に従えば誰でも直感的な1文字で文字列を分割することができる(とはいえアルゴリズムは非常に複雑)．

Slide 14

Slide 14 text

今回はこれらの知識を踏まえて，実際のアプリ開発で起こりそうな問題について解説します

Slide 15

Slide 15 text

アプリ開発で起きる問題色々

Slide 16

Slide 16 text

文字数制限が直感と異なる問題入力フォームなどで文字数を制限してる場合，Code Point単位で文字数を数えていると直感と異なる場合がある．例えば「」は7つのCode Point(U+1F3F4, U+E0067, U+E0062, U+E0077, U+E006C, U+E0073, U+E007F)で表現されるが，これを20文字(20Code Point)で制限してる場合，「」はこの制限に引っかかることになる．ユーザー名などの場合，Code Pointよりも書記素クラスタで制限したほうが良いかもしれない(もちろんちゃんと議論して合意を取ろう)． 20文字で制限している → 「」はアウト？

Slide 17

Slide 17 text

フォントが異なる問題実は一部の絵文字は白黒の記号とCode Pointを共有している．例えば「⁉」と「」はどちらもU+2049である．どちらが表示されるかはフォントの優先順位などで決まる．きちんと指定する場合，Emoji Variation Selector(EVS)という異体字セレクタの一種を後ろにつけることで絵文字自体のバリエーションを選択できる．フォントの優先順位やバリエーションをきちんとしないと，ユーザーが白黒の☎を打ったつもりなのに全く別のものが表示されてしまうかもしれない．「⁉」と「」，どっちが表示されて欲しい？

Slide 18

Slide 18 text

絵文字の合字の環境依存問題一部の絵文字の合字は環境依存の場合がある．例えばWhatsAppには「◯‍」5つをZWJで接続することで作られた五輪のマークの絵文字があった(現在は削除済みの模様)．使用している端末，フォント，アプリケーションによって合字の絵文字はうまく表示されない場合がある．ユーザーは特定の絵文字を入力したつもりでも，アプリ側ではうまく表示されない可能性もある． UnicodeではRGI(Recommended for General Interchange)と呼ばれる多プラットホームでサポートされている絵文字を定義しているため，これに沿わない絵文字を弾くといった実装をする必要が出てくるかもしれない． WhatsApp → それ以外 → ◯‍◯‍◯‍◯‍◯

Slide 19

Slide 19 text

結合文字列と検索で生じる問題

Slide 20

Slide 20 text

合成文字列で生じる問題「が(U+304C)」と「が(U+304B, U+3099)」はCode Point上の表記は違うが意味的にも視覚的にも完全に同一である．そのため，検索等でこの2つを同一視しないと直感と異なる振る舞いをすることになる．普段合成文字列なんて使わねーよと思う人もいると思うが，実はmacOSのFinder上でファイルの作成や名前の変更をした場合，合成文字列に自動変換されている．「が」と「が」は意味的・視覚的に等しい

Slide 21

Slide 21 text

合成文字列で生じる問題どちらも同じ意味の文字列なのに，合成文字列の方はうまくNGチェックに引っかからなくなってしまう．

Slide 22

Slide 22 text

解決策

Slide 23

Slide 23 text

Unicode正規化

Slide 24

Slide 24 text

Unicode正規化 Unicode正規化は意味的に等しい文字列(文字)を統一させる処理のこと．例えば全て合成済文字にしたり，全て結合文字列にしたりなど． NFC → 全て合成済文字にする(分解してから合成する) NFD → 全て結合文字列にする NFKC → NFCと似ているが，互換性のある文字も正規化する NFKD → NFDと似ているが，互換性のある文字も正規化する

Slide 25

Slide 25 text

Unicode正規化の例 JavaScriptではString.prototype.normalize()で正規化が可能． NFCで処理すると「が(U+304B, U+3099)」を「が(U+304C)」にすることができる．

Slide 26

Slide 26 text

Unicode正規化の例 NFKC/NFKDで処理すると視覚的に異なっても，意味的に同じならば正規化される(互換等価という，逆にNFC/NFDは正準等価という)．検索等の実装では便利だが，視覚的な表現が変わってしまう場合があるので気をつける必要がある(下の例以外にも，半角・全角が変わったりする)．

Slide 27

Slide 27 text

Unicode正規化とやらをすれば良いんだな！

Slide 28

Slide 28 text

...本当に？

Slide 29

Slide 29 text

Unicode正規化における問題点

Slide 30

Slide 30 text

CJK互換漢字という存在 UnicodeではCJK(中国・日本・韓国)で使われる漢字を統一的に扱うCJK統合漢字という物がある．これはUnicodeに漢字を収録する際に，「ほぼ同じ」漢字をCJK間で統合し，同一の Code Pointを振るために作られた．一方，Unicodeに収録する際に出典元となった各国の標準規格との互換性を保つために，一部の漢字はCJK統合漢字とは別に単体のCode Pointが割り当てられている．これをCJK互換漢字という． CJK統合漢字 → 「羽」(U+7FBD) CJK互換漢字 → 「羽」(U+FA1E)

Slide 31

Slide 31 text

正準等価でも見た目が変わってしまうこのCJK互換文字は，CJK統合漢字と視覚的に異なるのにも関わらず，Unicode正規化において正準等価であるため，NFC/NFDで見た目が置き換わってしまうという問題がある．つまり検索等の都合で闇雲に正規化してしまうと一部の漢字の見た目が変わる可能性がある．「羽」(U+FA1E) ↓ NFC/NFDで正規化 ↓ 「羽」(U+7FBD)

Slide 32

Slide 32 text

解決策

Slide 33

Slide 33 text

異体字セレクタを使う実はCJK互換文字は異体字セレクタを使用した2Code Pointで表現が可能(例外あるかも)．事前にCJK互換文字を異体字セレクタを使用した表現に変換しておけば，Unicode正規化に巻き込まれずに済む．「羽」(U+FA1E) ↓ 異体字セレクタを使った表現に変換 ↓ 「羽︀」(U+7FBD, U+FE00) ↓ Unicode正規化 ↓ 「羽︀」(U+7FBD, U+FE00)