Unicode等価性とは、 Unicode文字符号化規格において、一連のコードポイントが本質的に同じ文字を表すことを規定するものです。この機能は、類似または同一の文字を含むことが多い既存の標準文字セットとの互換性を確保するために、この規格に導入されました。
Unicode は、正規等価性と互換性という 2 つの概念を提供します。正規等価と定義されたコード ポイントシーケンスは、印刷または表示時に同じ外観と意味を持つと想定されます。たとえば、コード ポイントU+006E n LATIN SMALL LETTER Nに続いてU+0303 ◌ ̃ COMBINING TILDEが続く場合、Unicode では単一のコード ポイントU+00F1 ñ LATIN SMALL LETTER N WITH TILDEと正規等価であると定義されています。したがって、これらのシーケンスは同じ方法で表示され、名前のアルファベット順への並べ替えや検索などのアプリケーションで同じように処理され、互いに置き換えることができます。同様に、単一の文字としてエンコードされる各ハングル音節ブロックは、先頭の連結ジャモ、母音の連結ジャモ、および必要に応じて末尾の連結ジャモの組み合わせとして等価にエンコードできます。
互換性があると定義されるシーケンスは、場合によっては異なる外観を持つものの、文脈によっては同じ意味を持つものと想定されます。例えば、活字合字であるU+FB00 ff LATIN SMALL LIGATURE FF は、シーケンス U+0066 U+0066 (ラテン文字の「f」が2つ) と互換性があると定義されますが、正規的に同等ではありません。互換性のあるシーケンスは、一部のアプリケーション (ソートやインデックス作成など) では同じように扱われる場合もあれば、そうでない場合もあります。また、状況によっては互いに置き換えることができる場合もありますが、そうでない場合もあります。正規的に同等のシーケンスは互換性もありますが、その逆は必ずしも真ではありません。
この規格では、 Unicode正規化と呼ばれるテキスト正規化手順も定義されています。これは、同等の文字シーケンスを置き換えることで、同等の2つのテキストが同じコードポイントのシーケンス(正規化形式または元のテキストの標準形式と呼ばれる)に変換されるようにするものです。Unicodeは、これらの2つの同等性の概念に対して、2つの標準形式を定義しています。1つは完全合成(複数のコードポイントを可能な限り単一のコードポイントに置き換える)で、もう1つは完全分解(単一のコードポイントを複数のコードポイントに分割する)です。
互換性などの理由から、Unicode では、本質的に同じ文字であるエンティティに 2 つの異なるコード ポイントを割り当てることがあります。たとえば、「上にリングのダイアクリティカルマークが付いた文字 A」は、 U+00C5 Å LATIN CAPITAL LETTER A WITH RING ABOVE (スウェーデン語および他のいくつかの言語のアルファベットの文字) またはU+212B Å ANGSTROM SIGNとしてエンコードされます。ただし、オングストロームの記号はスウェーデン語の文字として定義されており、文字である他のほとんどの記号 (ボルトを表す⟨ V ⟩など) には、使用ごとに個別のコード ポイントはありません。一般に、真に同一の文字のコード ポイントは、標準的に同等であると定義されています。
一部の古い規格との整合性を保つため、Unicodeでは、他の文字の変形と見なせる文字(「ñ」のU+00F1や「Å」のU+00C5など)や、2つ以上の文字の組み合わせ(合字のflのU+FB00やオランダ語の文字ijのU+0132など)に対して、単一のコードポイントを提供しています。
他の標準との整合性と柔軟性を高めるため、Unicode では、単独では使用されず、先行する基本文字を修飾または結合することを目的とした多くの要素のコードも提供しています。これらの結合文字の例としては、 U+0303 ◌ ̃結合チルダや日本語の発音記号濁点( U+3099 ◌゙結合カタカナ・ひらがな有声音記号)などがあります。
Unicodeの文脈では、文字合成とは、基本文字のコードポイントに1つ以上の結合文字を付加して、1つの合成済み文字に置き換えるプロセスであり、文字分解はその逆のプロセスです。
一般的に、合成文字は、その基本文字とそれに続く結合発音記号の順序が、どのような順序であっても、正統的に同等であると定義されます。
一部の文字体系では、一般的に組版上相互作用しない複数の結合記号が頻繁に使用され、それらの組み合わせに対応する合成文字も存在しません。このような相互作用しない記号のペアは、どちらの順序でも格納できます。一般的に、これらの異なる順序は標準的に同等です。標準形式での順序を定義する規則は、それらが相互作用するとみなされるかどうかも定義します。
Unicodeは、美的理由のみで変更された文字または文字群(合字、半角カタカナ、日本語テキストで使用する全角ラテン文字など)や、元の意味を失うことなく新しい意味を追加した文字(下付き文字や上付き文字の数字、一部の日本語フォントから継承された丸で囲まれた数字(「①」など)など)に対してコードポイントを提供します。このようなシーケンスは、外観や追加された意味が重要でないアプリケーションのために、元の(個々の変更されていない)文字のシーケンスと互換性があるとみなされます。ただし、この区別には意味的な価値があり、テキストのレンダリングに影響を与えるため、2つのシーケンスは正統的に同等であるとは宣言されていません。
UTF-8とUTF-16(およびその他のUnicodeエンコーディング)は、すべての可能なコード単位のシーケンスを許容するわけではありません。さまざまなソフトウェアが、異なるルールを使用して無効なシーケンスをUnicode文字に変換しますが、その中には(すべての無効なシーケンスを同じ文字に変換するなど)非常に情報損失の大きいものもあります。これは正規化の一形態とみなすことができ、他の方法と同様の問題を引き起こす可能性があります。
Unicode文字列の検索および比較機能を実装するテキスト処理ソフトウェアは、同等のコードポイントの存在を考慮に入れる必要があります。この機能がない場合、特定のコードポイントシーケンスを検索するユーザーは、視覚的に区別できないものの、コードポイント表現は異なるものの、標準的に同等のコードポイント表現を持つ他のグリフを見つけることができなくなります。
Unicodeは、同等なすべてのコードポイントシーケンスに対して一意の(正規の)コードポイントシーケンスを生成する標準正規化アルゴリズムを提供します。同等性の基準は、正規性(NF)または互換性(NFK)のいずれかです。同等性クラスの代表要素は任意に選択できるため、各同等性基準に対して複数の正規形式が可能です。Unicodeは、2つの互換性基準それぞれに対して意味的に意味のある2つの正規形式を提供します。それは、合成形式NFCとNFKC、および分解形式NFDとNFKDです。合成形式と分解形式の両方で、コードポイントシーケンスに正規順序が課せられます。これは、正規形式が一意であるために必要な条件です。
Unicode 文字列を比較または検索するために、ソフトウェアは合成形式または分解形式のいずれかを使用できます。検索、比較などに関係するすべての文字列で同じであれば、どちらを選択しても問題ありません。一方、等価性基準の選択は検索結果に影響を与える可能性があります。たとえば、U+FB03 ( ffi ) のような活字合字、U+2168 ( Ⅸ ) のようなローマ数字、さらにはU+2075 ( ⁵ ) のような下付き文字や上付き文字には、それぞれ独自の Unicode コード ポイントがあります。正規化 (NF) はこれらのいずれにも影響を与えませんが、互換性正規化 (NFK) は ffi 合字を構成文字に分解するため、部分文字列として U+0066 ( f )を検索すると、U+FB03 の NFKC 正規化では成功しますが、U+FB03 の NFC 正規化では成功しません。合成済みのローマ数字Ⅸ (U+2168)からラテン文字I (U+0049)を検索する場合も同様です。同様に、上付き文字⁵ (U+2075)は互換性マッピングによって5 (U+0035)に変換されます。
上付き文字をベースライン相当に変換することは、その過程で上付き文字の情報が失われるため、リッチテキストソフトウェアには適さない場合があります。この区別を可能にするために、Unicode 文字データベースには互換性変換の詳細を提供する互換性フォーマットタグが含まれています。 [ 1 ]タイポグラフィ合字の場合、このタグは単に ですが<compat>、上付き文字の場合は です<super>。HTML などのリッチテキスト標準は、互換性タグを考慮しています。たとえば、HTML は独自のマークアップを使用して U+0035 を上付き文字の位置に配置します。[ 2 ]
以下の表に、4種類のUnicode正規化形式と、それらを取得するためのアルゴリズム(変換)を示します。
これらのアルゴリズムはすべて冪等変換であり、つまり、既にこれらの正規化された形式のいずれかになっている文字列は、同じアルゴリズムで再度処理しても変更されないことを意味します。
正規形は文字列連結に関して閉じられていない。[ 3 ]ハングル母音で始まる、または末尾に連結子jamoがある欠陥のあるUnicode文字列の場合、連結によって合成が壊れる可能性がある。
しかし、これらは単射ではない(異なる元のグリフとシーケンスを同じ正規化されたシーケンスにマッピングする)ため、全単射でもない(復元できない)。たとえば、異なるUnicode文字列「U+212B」(オングストローム記号「Å」)と「U+00C5」(スウェーデン語の文字「Å」)は、どちらもNFD(またはNFKD)によってシーケンス「U+0041 U+030A」(ラテン文字「A」と上の結合環「°」)に展開され、その後NFC(またはNFKC)によって「U+00C5」(スウェーデン語の文字「Å」)に縮小される。
正規化の際に別の文字に置き換えられる単一の文字(ハングル音節ブロックを除く)は、Unicodeテーブルにおいて、空でない互換性フィールドを持ちながら互換性タグを持たないことで識別できます。
正規順序は主に、連結文字の並び順に関するものです。この節の例では、文字は発音記号であると仮定していますが、一般的には、連結文字ではない発音記号もあれば、発音記号ではない連結文字もあります。
Unicodeでは、各文字に数値で表される結合クラスが割り当てられます。非結合文字はクラス番号0を持ち、結合文字は正の結合クラス値を持ちます。正規の順序を取得するには、結合クラス値が0でない文字の各部分文字列を、安定ソートアルゴリズムを使用して結合クラス値でソートする必要があります。同じクラス値を持つ結合文字は組版上相互作用すると想定されるため、2つの可能な順序は同等とはみなされず、安定ソートが必要となります。
例えば、ベトナム語のアルファベットで使用される文字 U+1EBF (ế)には、鋭アクセントと曲折アクセントの両方があります。その標準的な分解は、3 文字のシーケンス U+0065 (e) U+0302 (曲折アクセント) U+0301 (鋭アクセント) です。2 つのアクセントの結合クラスはどちらも 230 であるため、U+1EBF は U+0065 U+0301 U+0302 とは等価ではありません。
すべての結合シーケンスが事前に合成された同等のものを持つわけではないため(前の例の最後のものは U+00E9 U+0302 にしか還元できない)、通常の形式 NFC でさえ結合文字の挙動の影響を受けます。
2 つのアプリケーションが Unicode データを共有しているが、正規化の方法が異なると、エラーやデータ損失が発生する可能性があります。ある特定の例では、OS X がNetatalkおよびSambaファイルおよびプリンタ共有ソフトウェアから送信された Unicode ファイル名を正規化しました。Netatalk および Samba は変更されたファイル名を元のファイル名と同等として認識せず、データ損失が発生しました。[ 4 ] [ 5 ]正規化は可逆的ではないため、このような問題を解決するのは容易ではありません。