Normalizer クラス

定義

[Android.Runtime.Register("android/icu/text/Normalizer", ApiSince=24, DoNotGenerateAcw=true)]
public sealed class Normalizer : Java.Lang.Object, IDisposable, Java.Interop.IJavaPeerable, Java.Lang.ICloneable

[<Android.Runtime.Register("android/icu/text/Normalizer", ApiSince=24, DoNotGenerateAcw=true)>]
type Normalizer = class
    inherit Object
    interface ICloneable
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable

継承

Object

Object

Normalizer

属性

RegisterAttribute

実装

IJavaObject IJavaPeerable ICloneable IDisposable

注釈

以前の Unicode 正規化 API。

この API は Normalizer2 クラスに置き換えられ、下位互換性のためにのみ使用できます。 このクラスは、単に Normalizer2 クラスにデリゲートします。 2 つの例外があります。新しい API では、 QuickCheckResult と compare()の代わりは提供されません。

normalize は Unicode テキストを同等の構成または分解された形式に変換し、テキストの並べ替えと検索を容易にします。 normalize では、次で説明する標準の正規化形式がサポートされます

Unicode 標準付属書 #15 >Unicode 正規化フォーム。

アクセントやその他の装飾を持つ文字は、Unicode で複数の異なる方法でエンコードできます。 たとえば、A-acute という文字を使用します。 Unicode では、これは 1 文字 ("構成済み" 形式) としてエンコードできます。

00C1    LATIN CAPITAL LETTER A WITH ACUTE

または 2 つの独立した文字 ("分解" 形式):

0041    LATIN CAPITAL LETTER A
                 0301    COMBINING ACUTE ACCENT

ただし、プログラムのユーザーには、これらのシーケンスの両方を同じ "ユーザー レベル" 文字 "A with acute accent" として扱う必要があります。 テキストを検索または比較するときは、これら 2 つのシーケンスが同等に扱われるようにする必要があります。 さらに、複数のアクセントを持つ文字を処理する必要があります。 文字の組み合わせのアクセントの順序が重要な場合もあれば、異なる順序のアクセント シーケンスが実際に等しい場合もあります。

同様に、文字列 "ffi" は 3 つの個別の文字としてエンコードできます。

0066    LATIN SMALL LETTER F
                 0066    LATIN SMALL LETTER F
                 0069    LATIN SMALL LETTER I

または単一文字として

FB03    LATIN SMALL LIGATURE FFI

ffi 合字は別個のセマンティック文字ではなく、厳密に言えば Unicode ではまったく使用できませんが、既に提供されている既存の文字セットとの互換性のために含まれていました。 Unicode 標準では、対応するセマンティック文字に "互換性" 分解を与えることで、このような文字を識別します。 並べ替えや検索では、多くの場合、これらのマッピングを使用する必要があります。

normalize は、上記の最初の例に示すように、テキストを正規の構成および分解された形式に変換することで、これらの問題を解決するのに役立ちます。 さらに、互換性の分解を実行して、互換性文字を同等の文字と同じように扱うことができます。 最後に、 normalize はアクセントを適切な正規の順序に並べ替え、アクセントの並べ替えを自分で心配する必要がないようにします。

フォーム FCD "Fast C または D" も照合順序用に設計されています。 これにより、"正規のクロージャ" の下で動作するアルゴリズム (照合順序など) で必ずしも正規化されていない文字列を処理できます。つまり、事前に計算された文字とその分解された文字は同じように扱われます。

表現の一意性を提供しないため、正規化形式ではありません。 複数の文字列は正規に等しい (NFD は同じ) 場合があり、すべて同一でないと FCD に準拠している可能性があります。

フォームは、"生分解" (各文字の再帰的な正規分解) によって、正規順序付けされた文字列になるように定義されます。 つまり、事前計算済み文字は、分解に正規の並べ替えが必要ない限り許可されます。

照合順序のようなプロセスの利点は、すべての NFD テキストとほとんどの NFC テキスト (および多くの正規化されていないテキスト) が FCD に既に準拠しており、このようなプロセスに対して正規化 (NFD) する必要がないということです。 FCD クイック チェックでは、実際にはほとんどの文字列に対して YES が返されます。

normalize(FCD) は NFD で実装できます。

FCD の詳細については、Unicode テクニカル ノート #5 (アプリケーションでの正規等価性) を参照してください。 http://www.unicode.org/notes/tn5/#FCD

コレーター オブジェクトの正規化が有効になっている場合、ICU 照合順序は NFD または FCD の正規化を自動的に実行します。 照合順序や文字列検索以外に、正規化された文字列は、文字列の等価性の比較、音訳/文字起こし、一意の表現などに役立ちます。

W3C では通常、NFC でテキストを交換することをお勧めします。 また、ほとんどの従来の文字エンコーディングでは、事前計算済みのフォームのみが使用され、多くの場合、単独で結合マークをエンコードしないことにも注意してください。 このような文字エンコードに変換するには、Unicode テキストを NFC に正規化する必要があります。 その他の使用例については、Unicode 標準付属書を参照してください。

注: Normalizer クラスには、反復正規化のための API も用意されています。 setIndex() と getIndex() は基になる Unicode 入力テキストのインデックスを参照しますが、next() メソッドと previous() メソッドは正規化された出力の文字を反復処理します。 つまり、next() と previous() によって返される文字と、setIndex() と getIndex() に渡されて返されるインデックスの間に、必ずしも一対一の対応が存在するとは限りません。 このため、Normalizer は CharacterIterator インターフェイスを実装しません。

Javaドキュメント。

このページの一部は、によって作成および共有され、に記載されている条件に従って使用される作業に基づく変更です。