fn:normalize-unicode

(Auszug aus "XSLT 2.0 & XPath 2.0" von Frank Bongers, Kapitel 5.)

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

   

Kategorie: Stringfunktionen – Analyse und Manipulation

Herkunft: XPath 2.0

Rückgabewert: Ein String xs:string; der Eingabestring in normalisierter Form, entweder entsprechend Unicode NFC oder gemäß der bezeichneten Unicode-Normalisierungsvorschrift.

Aufruf/Argumente:

fn:normalize-unicode($eingabestring?, $normalisierungsform?)

$eingabestring:
Optional. Eine Zeichenkette xs:string, die gemäß einer der Uni­code-Normalisierungsformen normalisiert werden soll. Wird die leere Sequenz übergeben, so gibt die Funktion eine leere Ausgabesequenz zurück.

$normalisierungsform:
Optional. Ein String xs:string, der dem Bezeich­ner einer implementierten Normalisierungsvorschrift entsprechen muss, andernfalls wird ein Fehler gemeldet. Zur Erkennung des Bezeichners wird $normalisierungsform gegebenenfalls in Großbuchstaben umgewandelt und normalisiert (füh­rende und folgende Leerzeichen entfernt). Die Übergabe eines leeren Strings als zweites Argument deaktiviert die Nor­malisierung.

Verwendungszweck:

Die Funktion fn:normalize-unicode() nimmt keine Weißraumnormalisierung vor, sondern normali­siert den Eingabestring entsprechend einer der vier einschlägigen Vorschriften der Unicode-Normalisierung. Eine solche Normalisierung vereinheitlicht den Aufbau von Zeichenketten, die Unicode-Komposit­zeichen enthalten. Dies ist sinnvoll im Vorfeld eines Stringvergleichs zwischen Unicode-Zeichenketten. Reiner ASCII-Text braucht nicht in dieser Form normalisiert werden, da hier keine Kompositzeichen auftreten können.

Einsatzmöglichkeiten:

Sinnvoll normalisierbar ist ein String, der zusam­mengesetzte Unicode-Zeichen (Kompositzeichen) enthält. Hierunter fallen beispielsweise Ligaturen, akzentierte Zeichen oder Umlaute. So kann zum Beispiel der Kleinbuch­stabe ä mittels des einzelnen Zeichens U+00E4 LATIN SMALL LETTER A WITH DIAERESIS oder als Kombination der beiden Zeichen U+0061 LATIN SMALL LETTER A und U+0308 COMBINING DIAERESIS dargestellt werden. Die möglichen Varianten können das Ergebnis eines direk­ten Stringvergleichs zweier (auch im Grunde als gleich zu betrachtenden) Zeichenketten quasi unvorhersehbar machen.

Die Unicode-Normalisierungsformen stellen sicher, dass vor einem eventuellen Vergleich alle Zeichenkombi­nationen und Kombinationszeichen zu einheitlichen, definierten Zeichen bzw. Zeichenfolgen konvertiert werden.

Im Rahmen der Normalisierung wird zunächst eine Dekomposition zusammen­gesetzter Zeichen vorgenommen, anschließend deren Ersetzung durch eine kanonische (einer gleichförmigen Regel entsprechenden) Kompositdarstellung. Treten Sonderzeichen als sogenannte Single­ton-Zeichen auf, die aus nur einem Unicode-Symbol bestehen (beispielsweise Å als Zeichen für »Angstrom«), so werden sie durch ihre entspre­chende kanonische Kompositform ersetzt.

Reiner ASCII-Text, und damit jeder Programm-Quellcode, bleibt bei einer erfolgenden Unicode-Normalisierung unverändert (ASCII enthält keine Kompositzeichen). Schädlich ist eine Normalisierung hier demzufolge also zwar nicht, sondern lediglich überflüssig.

Durch Unicode-Normalisierung betroffene Zeichen:
Vergleichstabellen aller von Unicode-Normalisierung betroffenen Zeichen aller Zeichensätze finden sich unter Unicode - Normalization Charts. 

Normalisierungsformen:

Der Standard verlangt von einer Applikation lediglich die Unterstützung der (meistverbreitetsten) Normalisierung nach NFC (Unicode Normalisation Form C, Kanonische Komposition), die auch vom W3C favorisiert wird. Diese Vor­schrift wird defaultmäßig verwendet, wenn kein zweites Argument übergeben wird, also keine Normalisierungsform explizit verlangt ist: 

• NFC (Default-Einstellung) – Unicode Normalisation Form C, kanonische Komposition 

Neben NFC existieren weitere Vorschriften, deren Bezeichnungen der Applika­tion bekannt sein können (aber nicht müssen):

• NFD – Unicode Normalisation Form D, kanonische Dekomposition
• NFKC – Unicode Normalisation Form KC, kanonisch-kompatible Komposition
• NFKD – Unicode Normalisation Form KD, kanonisch-kompatible Dekomposi­tion

Abbildung: Auszug aus der Unicode-Normalisierungstabelle.

Nicht zum Unicode-Standard gehört eine weitere, möglicherweise durch Anwendungen unterstützte Form:

• FULLY-NORMALIZED – die Normalisierungsvorschrift des W3C; beschrieben in »Character Model for the World Wide Web 1.0«.
  Diese Form entspricht im Wesentlichen NFC, erlaubt jedoch als erstes Zeichen des Strings nur sogenannte Base Cha­racters (Unicode Combining Class 0). Tritt am Strin­ganfang ein Kombinationszeichen auf, beispielsweise ein Akzentzeichen, wird diesem (zusätzlich, als Base Character) im Zuge der Normalisierung ein Leerzeichen vorange­stellt, um das Kombinations­zeichen zu tragen.

Hinweis: Schreibweise der Bezeichner der Normalisierungsform
Aufgrund der vorgenommenen Normalisierung (Entfernung füh­render und folgender Leerzeichen) des Wertes des Normalisierungsform-Arguments sowie dessen anschließender Umwandlung in Großbuchstaben können die Bezeichner prinzipiell in beliebiger Schreibweise übergeben werden.

Über die oben genannten hinaus steht es Anwendungen frei, beliebig viele weitere Normalisierungsformen zu unterstützen.

Wird ein Bezeichner übergeben, den die Applikation entweder nicht identifizieren kann, oder dessen zugehörige Normalisierungsvorschrift von ihr nicht unterstützt wird, so wird der Fehler »Unsupported normalization form« gemeldet (err:FOCH0003).

Wird der Funktion zwar ein zweites Argument übergeben, ist dies jedoch der leere String, so wird keine Normalisierung vorgenommen (also auch nicht die Default-Normalisierung nach NFC), sondern der Eingabestring wird in unverän­derter Form zurückgegeben.

Funktionsdefinition:

XPath 1.0:

Funktion nicht verfügbar

XPath 2.0:

fn:normalize-unicode($arg as xs:string?) as xs:string?

fn:normalize-unicode($arg as xs:string?, 
                     $normalizationForm as xs:string)
                     as xs:string?

   

<< zurück

vor >>