Unicode正規化 その１
Unicodeのテキストをあつかう上で、「結合文字列」と「Unicode正規化」はどうしても避けることのできない問題です。ここではあまり深く掘り下げずに、ユーザの眼を通してこれを見ていこうと思います。
まずはじめに、Unicodeには「特殊な文字」があることを知っておきましょう。
Unicodeの特殊な文字
ここに２つの「ポ」があります。OS X のエディタ「テキストエディット」に表示された文字です。
まったく同じに見えますが、この２文字、実は全然違う文字です。左は普通の１文字ですが、右は「ホ」に「半濁音」がくっついた２文字のデータで構成されています。見た目が１文字として表示されるので、２つの「ポ」は違いがまったく分かりません。
そこで、違いを実感できるように簡単なソフトを作ってみました。
このソフトは、テキストエディットと違って「ホ」と「半濁音」を別々に選択することができます。さらに選択した文字のコードポイントが下に表示されるようになっています。ぜひ試して遊んでみてください。
左に「ポ」と手入力し、「NFD」ボタンを押すと、右に変換された「ポ」が表示されます。この「ポ」をマウスで触ってみましょう。「半濁音」だけをカットしてペーストしてみるのも面白いです。「１文字が２文字のデータで構成されている」とはどういうことなのか、実感できますよね。
次にもっと興味深い文字を見てみましょう。「Get Glyph …」ボタンの上に「01D6」とコードポイントを入力し、ボタンを押します。上にその字形が表示されます。小文字 u にアクセント記号が付いた文字ですね。「NFD」ボタンを押して変換してみます。なんと、２文字ではなく「３文字」で構成されていることが分かります。
さらに、「Get Glyph …」の上に「00FC 0304」と２つのコードポイントを入力し、ボタンを押してみます（半角スペースを間に入れてください）。上図とまったく同じ字形が表示されます。これは３文字ではなく「２文字」で構成されています。
つまり、この字形は
「01D6」
「00FC 0304」
「0075 0308 0304」
の３通りの方法で表示できてしまうんですね。
この３通りの文字を「テキストエディット」にコピー＆ペーストしてみましょう。テキストエディットでは、どの文字も１文字として選択されます。さらに検索をしてみると、どの文字にもヒットします。３つが異なる文字であることをまったく判別することができませんし、判別する術もありません。もちろん、これはユーザへの配慮でそうなっているわけです。
さて、ここで専門用語を３つだけ覚えてください。
「結合」「結合文字列」「結合文字」
これまで見てきたように、Unicodeには「１文字を複数の文字で構成する」という特殊な方法が用意されています。この特殊な方法のことを、Unicodeでは単純に「結合 Combining」といっています。平易な言葉なのでつい読み流してしまうのですが、Unicodeの文脈では特殊な専門用語であることに注意してください。
そして「結合」によって１文字になったその文字 １文字と見なされるようになった複数文字のことを、専門用語で「結合文字列 Combining Character Sequence」といいます。「１文字に結合した文字列」という意味です。複数なので「列」なんですね。
さらにそして、上の説明で登場した「半濁音」「アクセント記号」などのことを、専門用語で「結合文字 Combining Character」といいます。この文字は結合文字列のためだけに用意された特殊な文字なので、単独で使われることはありませんし、単独で使ってもいけません。
ちなみに、これは覚えなくても構いませんが、結合文字列「ホ＋半濁音」の「ホ」の方は、結合文字ではなく「基底文字 Base Character」と呼びます。
Mac OS X は結合文字列だらけ
さて、Unicodeの特殊な文字である「結合文字列」がどういうものかを見てきましたが、もしかすると、皆さんはこう疑問に思っているかもしれませんね。
「特殊な文字のことは分かった。でも、特殊なんだから、普通に作るテキストデータにそんな文字なんか無いのでは？」
実は、OS X には結合文字列が普通にいたるところにあるのです。しかも、新しく簡単に作ることもできてしまいます。やってみましょう。
デスクトップに新規フォルダを作ります。なんと、これだけで結合文字列のできあがりです。「ダ」の文字を「簡単なソフト」へペーストしてみてください。２文字の結合文字列であることが分かります。
このように、OS X のフォルダ名やファイル名などのアイテム名は、結合文字列にできる文字ならすべて結合文字列になってしまいます。アイテム名をテキストにコピー＆ペーストしたことがない人はいないでしょうし、普通に作るテキストデータに結合文字列が混ざることは大いにありそうなことです。それにWindowsでもVistaが結合文字列に対応したことで、結合文字列混在の可能性がひときわ高くなったことも押さえておくべきだと思います。
補注：
日本のユーザがUnicode正規化で混乱する原因のひとつに「日本訳語が定まっていない」という現状があります。その最たるものが、この２つです。
combining
複数文字の組み合せで１文字を表現していること
composition
複数文字で表現された１文字を単一コードの１文字にすること
実はこの２つ、意味がまったく異なるのですが、日本語訳では「結合」と「合成」、辞書的にはどちらでも当てはまってしまいます。ですから、上記で私が「結合」と記した「combining」を「合成」と言っている資料もあります。しかし、それではそうした資料に「composition」の首尾一貫した訳語があるのかというと、私が知る限り見た事がありません。
この２つの訳語を選定するには、他の語もあわせて考える必要があります。
combining
composition
decomposition ＝ 分解
precomposed ＝ 合成済み
最低限、この４つを区別できる訳語にする必要があります。下の２つは、どの資料でも使われているので、確定されていると言っていいでしょう。（「precomposed」を「結合済み」としている資料は極々僅少です）
すると「compose」はどうしても「合成」でなければなりません。それなのに「combining」にも「合成」という訳語を与えるのは、他にどんな理由があるのでしょう？ 私にはまったく理解できません。
一方、良質の資料では、かならず
combining ＝ 結合
composition ＝ 合成
と訳語も明確に使い分けられており、混同されることはありませんし、語感上もその方がしっくりきます。私もここではそれに倣い、この訳語にすることにしました。
ちなみに、こうした用語の混乱は、実は日本だけではないようです。本家の Unicode用語集 を見ていると明らかに「combining character sequence」と「composite character sequence」を同義語にしているので、ワケがわかりません。
結局のところ、Unicode正規化の資料を読む時には、どちらのことを指しているかを「文脈で判断する」しかないのが実情です。