Normalizer Klasse

Definition

[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

Vererbung

Object

Object

Normalizer

Attribute

RegisterAttribute

Implementiert

IJavaObject IJavaPeerable ICloneable IDisposable

Hinweise

Alte Unicode-Normalisierungs-API.

Diese API wurde durch die Normalizer2 Klasse ersetzt und steht nur aus Gründen der Abwärtskompatibilität zur Verfügung. Diese Klasse delegiert einfach an die Normalizer2-Klasse. Es gibt zwei Ausnahmen: Die neue API bietet keinen Ersatz für QuickCheckResult und compare().

normalize Wandelt Unicode-Text in eine gleichwertige durchkomponierte oder dekomponierte Form um, sodass text einfacher sortiert und durchsucht werden kann. unterstützt die in

Unicode Standard Anhang Nr. 15 — Unicode Normalisierungsformulare.

Zeichen mit Akzenten oder anderen Schmücken können in Unicode auf verschiedene Weise codiert werden. Nehmen Sie z. B. das Zeichen A-akut. In Unicode kann dies als einzelnes Zeichen (das "zusammengesetzte" Formular) codiert werden:

00C1    LATIN CAPITAL LETTER A WITH ACUTE

oder als zwei separate Zeichen (das Formular "dekompiliert"):

0041    LATIN CAPITAL LETTER A
                 0301    COMBINING ACUTE ACCENT

Für einen Benutzer Ihres Programms sollten diese beiden Sequenzen jedoch als das gleiche "Benutzerebene"-Zeichen "A mit akutem Akzent" behandelt werden. Wenn Sie Text suchen oder vergleichen, müssen Sie sicherstellen, dass diese beiden Sequenzen gleichwertig behandelt werden. Darüber hinaus müssen Sie Zeichen mit mehr als einem Akzent behandeln. Manchmal ist die Reihenfolge der kombinierten Akzente eines Zeichens signifikant, während in anderen Fällen Akzentabfolgen in unterschiedlichen Reihenfolgen wirklich gleichwertig sind.

Ebenso kann die Zeichenfolge "ffi" als drei separate Buchstaben codiert werden:

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

oder als einzelnes Zeichen

FB03    LATIN SMALL LIGATURE FFI

Die ffi-Ligatur ist kein unterschiedliches semantisches Zeichen, und genau genommen sollte es sich gar nicht in Unicode befinden, aber es wurde zur Kompatibilität mit vorhandenen Zeichensätzen aufgenommen, die es bereits bereitgestellt haben. Der Unicode-Standard identifiziert solche Zeichen, indem sie "Compatibility"-Dekompositionen in die entsprechenden semantischen Zeichen geben. Beim Sortieren und Suchen möchten Sie diese Zuordnungen häufig verwenden.

normalize hilft, diese Probleme zu lösen, indem Text in die kanonischen zusammengesetzten und dekomponierten Formen umgewandelt wird, wie im ersten Beispiel oben gezeigt. Darüber hinaus können Sie kompatibilitätskompositionierungen ausführen, damit Sie Kompatibilitätszeichen wie ihre Entsprechungen behandeln können. normalize Schließlich ordnen Sie Akzente in die richtige kanonische Reihenfolge um, sodass Sie sich keine Gedanken über die Neuanordnung von Akzenten machen müssen.

Form FCD, "Fast C oder D", ist auch für die Sortierung konzipiert. Sie ermöglicht es, Zeichenfolgen zu bearbeiten, die nicht unbedingt mit einem Algorithmus (wie in der Sortierung) normalisiert werden, der unter "kanonischer Verschluss" funktioniert, d. h., es behandelt vorkompilierte Zeichen und deren dekompilierte Entsprechungen dasselbe.

Es handelt sich nicht um eine Normalisierungsform, da sie nicht für die Eindeutigkeit der Darstellung sorgt. Mehrere Zeichenfolgen können kanonisch gleichwertig sein (ihre NFDs sind identisch) und alle entsprechen FCD, ohne sich selbst identisch zu sein.

Das Formular wird so definiert, dass die "Unformatierung", die rekursive kanonische Analyse jedes Zeichens, eine Zeichenfolge ergeben, die kanonisch geordnet ist. Dies bedeutet, dass vorkompilierte Zeichen zulässig sind, solange ihre Analysen keine kanonische Neuanordnung erfordern.

Der Vorteil für einen Prozess wie die Sortierung besteht darin, dass alle NFD und die meisten NFC-Texte - und viele unnormalisierte Texte - bereits FCD entsprechen und nicht normalisiert (NFD) für einen solchen Prozess sein müssen. Die FCD-Schnellüberprüfung gibt JA für die meisten Zeichenfolgen in der Praxis zurück.

normalize(FCD) kann mit NFD implementiert werden.

Weitere Informationen zu FCD finden Sie unter Unicode Technical Note #5 (Kanonische Äquivalenz in Anwendungen): http://www.unicode.org/notes/tn5/#FCD

Die ICU-Sortierung führt entweder NFD- oder FCD-Normalisierung automatisch aus, wenn die Normalisierung für das Collator-Objekt aktiviert ist. Über die Sortierungs- und Zeichenfolgensuche hinaus können normalisierte Zeichenfolgen für Vergleiche von Zeichenfolgen, Transliteration/Transkription, eindeutige Darstellungen usw. nützlich sein.

Das W3C empfiehlt im Allgemeinen, Texte in NFC auszutauschen. Beachten Sie auch, dass die meisten älteren Zeichencodierungen nur vorkompilierte Formulare verwenden und häufig keine kombinationsfähigen Markierungen selbst codieren. Für die Konvertierung in solche Zeichencodierungen muss der Unicode-Text in NFC normalisiert werden. Weitere Verwendungsbeispiele finden Sie im Unicode-Standard-Anhang.

Hinweis: Die Normalizer-Klasse stellt auch API für iterative Normalisierung bereit. Während "setIndex()" und "getIndex()" auf Indizes im zugrunde liegenden Unicode-Eingabetext verweisen, durchlaufen die Methoden next() und previous() Zeichen in der normalisierten Ausgabe. Dies bedeutet, dass es nicht notwendigerweise eine 1:1-Entsprechung zwischen Zeichen gibt, die von next() und previous() zurückgegeben werden, und den an setIndex() und getIndex() übergebenen Indizes. Aus diesem Grund implementiert Normalizer die CharacterIterator-Schnittstelle nicht.

Java Dokumentation für android.icu.text.Normalizer.

Teile dieser Seite sind Änderungen auf der Grundlage von Arbeiten, die von der Android Open Source Project erstellt und gemeinsam verwendet und gemäß den in der 2.5 Attribution License beschriebenen Begriffen verwendet werden.