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 Unicode-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 Bezeichner einer implementierten Normalisierungsvorschrift entsprechen muss, andernfalls wird ein Fehler gemeldet. Zur Erkennung des Bezeichners wird $normalisierungsform gegebenenfalls in Großbuchstaben umgewandelt und normalisiert (führende und folgende Leerzeichen entfernt). Die Übergabe eines leeren Strings als zweites Argument deaktiviert die Normalisierung.
Verwendungszweck:
Die Funktion fn:normalize-unicode() nimmt keine Weißraumnormalisierung vor, sondern normalisiert den Eingabestring entsprechend einer der vier einschlägigen Vorschriften der Unicode-Normalisierung. Eine solche Normalisierung vereinheitlicht den Aufbau von Zeichenketten, die Unicode-Kompositzeichen 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 zusammengesetzte Unicode-Zeichen (Kompositzeichen) enthält. Hierunter fallen beispielsweise Ligaturen, akzentierte Zeichen oder Umlaute. So kann zum Beispiel der Kleinbuchstabe ä 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 direkten Stringvergleichs zweier (auch im Grunde als gleich zu betrachtenden) Zeichenketten quasi unvorhersehbar machen.
Die Unicode-Normalisierungsformen stellen sicher, dass vor einem eventuellen Vergleich alle Zeichenkombinationen und Kombinationszeichen zu einheitlichen, definierten Zeichen bzw. Zeichenfolgen konvertiert werden.
Im Rahmen der Normalisierung wird zunächst eine Dekomposition zusammengesetzter Zeichen vorgenommen, anschließend deren Ersetzung durch eine kanonische (einer gleichförmigen Regel entsprechenden) Kompositdarstellung. Treten Sonderzeichen als sogenannte Singleton-Zeichen auf, die aus nur einem Unicode-Symbol bestehen (beispielsweise Å als Zeichen für »Angstrom«), so werden sie durch ihre entsprechende 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 Vorschrift 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 Applikation 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 Dekomposition
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 Characters (Unicode Combining Class 0). Tritt am Stringanfang ein Kombinationszeichen auf, beispielsweise ein Akzentzeichen, wird diesem (zusätzlich, als Base Character) im Zuge der Normalisierung ein Leerzeichen vorangestellt, um das Kombinationszeichen zu tragen.
Hinweis: Schreibweise der Bezeichner der Normalisierungsform
Aufgrund der vorgenommenen Normalisierung (Entfernung führender 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änderter 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 >> |
Tipp der data2type-Redaktion: Zum Thema XSLT bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an: |
Copyright © Galileo Press, Bonn 2008
Für Ihren privaten Gebrauch dürfen Sie die Online-Version ausdrucken.
Ansonsten unterliegt dieses Kapitel aus dem Buch "XSLT 2.0 & XPath 2.0 ― Das umfassende Handbuch" denselben Bestimmungen wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.
Galileo Press, Rheinwerkallee 4, 53227 Bonn