[2] [DFN[[RUBYB[互換性等価性]@en[compatibility equivalence]]]]は、 [[正準等価性]]に加え、[[全角]]・[[半角]]、[[上付き]]、[[書体]]などの差異も無視した[[文字]]の[[等価性]]です。 [[互換等価性]]を保ちつつできるだけ基本的な[[基底文字]]と[[結合文字]]の列に[[分解]]する操作を[DFN[[RUBYB[[[互換分解]]]@en[compatibility decomposition]]]]といいます。 * 仕様書 [REFS[ - [5] [CITE@en-us[UAX #44: Unicode Character Database]] ([TIME[2013-09-27 22:15:15 +09:00]] 版) - [7] [CITE@en[[[RFC 7564]] - PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols]], [TIME[2024-07-07T03:59:22.000Z]] ]REFS] * 文字カテゴリー [CODE[HasCompat]] (PRECIS) [8] [[PRECIS]] の[[文字カテゴリー]] [DFN[[CODE[HasCompat]]]] は、 [[互換性等価性]]を持つ[[文字]]を表します。 [SRC[>>7]] [9] [CODE[HasCompat]] は、 [CODE[toNFKC]] を適用すると異なる値となる[[符号位置]]と定義されています。 [SRC[>>7]] ;; [10] [[IDNA2008]] は [[Unstable]] で [[case folding]] と組み合わせた定義を使っています。 * 互換分解の破壊性 [11] [[Unicode正規化]]は破壊的です。 [[文字列]]を異なる意味の[[文字列]]に不可逆的に変換する操作です。 [[互換分解]]は [[Unicode正規化]]の破壊性の主要な発生源です。 従って、[[利用者入力]]など事前にその性質を確定できない[[文字列]]に適用してはなりません。 [SEE[ [[Unicode正規化]] ]] [4] [[正準等価性]]に対しては[[正準分解]]と[[正準結合]]がありますが、 [[互換性等価性]]に対しては[[互換分解]]しかありません。 [[互換分解]]によって失われる情報はいかなる意味でも後から復元できないからです。 [6] [CODE[Vertical_Orientation]] が[[半角文字]]と[[全角文字]]で全然違っています。 そのため[[互換分解]]すると[[縦書き]]での表示方法の情報も失われてしまいます。 [1] [CODE(charname)@en[[[HIRAGANA DIGRAPH YORI]]]] を [Q[より]] にするような[[分解]]はやりすぎではないか? [Q[麿]]を[Q[麻呂]]に分解するのと何が違う? * 互換分解の不完全性 [12] [[Unicode]] の[[互換分解]]は必ずしも一貫した形で定められていません。 同じような構造の文字であるにも関わらず、あるものには[[互換分解]]があり、 あるものには[[互換分解]]がない、ということがあります。 [16] [[上付き]]の[[ラテン文字]]が[[結合文字]]になっているようなケースには基本的に[[互換分解]]が定められていないようです。 [[結合文字]]の[[互換分解]]というものがあまり想定されていないのでしょうか。 [17] 比較的新しく追加された[[文字]]には[[互換分解]]が定められていないことが多いようです。 [[互換分解]]で表されるような[[文字]]は新規追加しづらい風潮がありそうで (追加しないとはっきり決まっているのかまでは不明)、 [[Unicode]] 開発初期だったら[[互換分解]]付きになっていそうなものでも、 [[互換分解]]されるような[[文字]]ではなく独立した新規の[[文字]]として必要なものだという理由付けと共に提案されがちなのかもしれません。 [13] 従って何らかの用途に[[互換分解]]が便利そうに見えても、 本当にそれで適切かは慎重に検討が必要です。 [15] [[互換分解]]の結果の[[文字列]]中に更に[[正準分解]]できる[[文字]]が含まれることがあります。 [14] 関連: [[丸付き文字]], [[〒]], [[発音区別符付き仮名]] * 関連 [3] [[互換分解]]は [[NFKC]] と [[NFKD]] で使われています。 * メモ