Leerstellenverarbeitung in XAML
Aktualisiert: November 2007
Extensible Application Markup Language (XAML) verfügt über Sprachregeln, die angeben, wie signifikante Leerzeichen von einer XAML-Prozessorimplementierung verarbeitet werden müssen. In diesem Thema werden diese Sprachregeln sowie zusätzliche Aspekte der Verarbeitung von Leerräumen durch eine Windows Presentation Foundation (WPF)-Implementierung des XAML-Prozessors und der XAML-Writer für die Serialisierung erläutert.
Leerraumverarbeitung
Leerraumdefinition
Wie in XML sind Leerraumzeichen in XAML Leerzeichen, Zeilenvorschub und Tabulator. Diese entsprechen den Unicode-Werten 0020, 000A bzw. 0009.
Leerraumnormalisierung
Standardmäßig wird die folgende Leerraumnormalisierung durchgeführt, wenn ein XAML-Prozessor eine XAML-Datei verarbeitet:
Zeilenvorschubzeichen zwischen ostasiatischen Zeichen werden entfernt. Eine Definition für "ostasiatische Zeichen" finden Sie im Abschnitt zu ostasiatischen Zeichen weiter unten in diesem Thema.
Alle Leerraumzeichen (Leerzeichen, Zeilenvorschub, Tabulator) werden in Leerzeichen konvertiert.
Alle aufeinanderfolgenden Leerzeichen werden durch ein Leerzeichen ersetzt.
Ein Leerzeichen, das direkt auf das Starttag folgt, wird gelöscht.
Ein Leerzeichen, das direkt vor dem Endtag steht, wird gelöscht.
Der "Standardwert" entspricht dem Status, der vom Standardwert für das xml:space-Attribut angegeben ist.
Leerraum in innerem Text und Zeichenfolgenprimitiven
Die oben aufgeführten Normalisierungsregeln gelten für inneren Text, der sich in XAML-Elementen befindet. Nach der Normalisierung konvertiert ein XAML-Prozessor inneren Text wie folgt in einen entsprechenden Typ:
Wenn der Eigenschaftentyp keine Auflistung ist, jedoch nicht direkt ein Object-Typ, versucht der XAML-Prozessor, mit dem Typkonverter eine Konvertierung in diesen Typ durchzuführen. Wenn es bei dieser Konvertierung zu einem Fehler kommt, tritt ein Fehler zur Kompilierzeit auf.
Wenn der Eigenschaftentyp eine Auflistung ist und der innere Text zusammenhängend ist (keine zwischen den Zeichen befindlichen Elementtags vorhanden sind), wird der innere Text als einzelne String analysiert. Wenn der Auflistungstyp die String nicht verwenden kann, kommt es ebenfalls zu einem Fehler zur Kompilierzeit.
Wenn der Eigenschaftentyp Object ist, wird der innere Text als einzelne String analysiert. Wenn zwischen den Zeichen Elementtags vorhanden sind, kommt es zu einem Fehler zur Kompilierzeit, da der Object-Typ ein einzelnes Objekt impliziert (String oder anderes).
Wenn der Eigenschaftentyp eine Auflistung und der innere Text nicht zusammenhängend ist, wird die erste untergeordnete Zeichenfolge in eine String konvertiert und als Auflistungselement hinzugefügt, das zwischen den Zeichen befindliche Element wird als Auflistungselement hinzugefügt, und zum Schluss wird die nachstehende untergeordnete Zeichenfolge (soweit vorhanden) der Auflistung als drittes String-Element hinzugefügt.
Leerraum- und Textinhaltsmodelle
In der Praxis ist die Beibehaltung von Leerräumen nur für eine Teilmenge aller möglichen Inhaltsmodelle von Bedeutung. Diese Teilmenge besteht aus Inhaltsmodellen, die einen Singleton-String-Typ in einem bestimmten Format, eine dedizierte String-Auflistung oder eine Kombination von String und anderen Typen in einer IList-Auflistung oder ICollection<T>-Auflistung verwenden kann.
Auch bei Inhaltsmodellen, die Zeichenfolgen verwenden können, besteht das Standardverhalten in diesen Inhaltsmodellen darin, dass verbleibende Leerräume als nicht signifikant behandelt werden. So verwendet ListBox zum Beispiel eine IList, wobei der Leerraum (wie z. B. Zeilenvorschübe zwischen jedem ListBoxItem) nicht beibehalten und nicht gerendert wird; die Verwendung von Zeilenvorschüben als Trennzeichen zwischen Zeichenfolgen für ListBoxItem-Elemente funktioniert in der Tat nicht sehr gut; die durch Zeilenvorschübe getrennten Zeichenfolgen werden als eine Zeichenfolge und ein Element behandelt.
Die Auflistungen, bei denen Leerräume als signifikant behandelt werden, sind in der Regel Teil des Flussdokumentmodells. Die primäre Auflistung, die die Beibehaltung von Leerräumen unterstützt, ist die InlineCollection. Diese Auflistungsklasse wird mit dem WhitespaceSignificantCollectionAttribute deklariert; wenn dieses Attribut gefunden wird, behandelt der XAML-Prozessor Leerräume in der Auflistung als signifikant. Die Kombination von xml:space="preserve" und Leerraum in einer mit WhitespaceSignificantCollectionAttribute gekennzeichneten Auflistung führt dazu, dass ALLE Leerräume beibehalten und gerendert werden. Die Kombination von xml:space="default" und Leerraum in einem WhitespaceSignificantCollectionAttribute führt zu der weiter oben beschriebenen anfänglichen Leerraumnormalisierung, wobei ein Leerraum an einer bestimmten Stelle erhalten bleibt; diese Leerräume werden dann beibehalten und gerendert. Sie müssen selbst entscheiden, welches Verhalten verwendet werden soll; Sie sollten xml:space selektiv verwenden, um das gewünschte Verhalten zu aktivieren.
Außerdem sollten bestimmte Inlineelemente, die einen Zeilenumbruch in einem Flussdokumentmodell kennzeichnen, absichtlich kein zusätzliches Leerzeichen in einer leerraumsignifikanten Auflistung einfügen. So hat zum Beispiel das LineBreak-Element den gleichen Zweck wie das <BR/>-Tag in HTML; zur besseren Lesbarkeit im Markup wird ein LineBreak in der Regel durch einen erstellten Zeilenvorschub von nachfolgendem Text getrennt. Dieser Zeilenvorschub sollte nicht normalisiert werden, sodass er zu einem Leerraum in der nachfolgenden Zeile wird. Um dieses Verhalten zu aktivieren, wendet die Klassendefinition für das LineBreak-Element das TrimSurroundingWhitespaceAttribute an, das dann vom XAML-Prozessor so interpretiert wird, dass Leeräume um LineBreak immer verkürzt werden.
Beibehalten von Leerräumen
Es gibt mehrere Möglichkeiten zum Beibehalten von Leerräumen im Quell-XAML für die eigentliche Darstellung, auf die sich die XAML-Prozessor-Leerraumnormalisierung nicht auswirkt.
xml:space="preserve": Legen Sie dieses Attribut auf der Ebene des Elements fest, auf der eine Beibehaltung von Leerräumen erwünscht ist. Beachten Sie, dass hierdurch alle Leerräume beibehalten werden, einschließlich der Leerräume, die möglicherweise von Codebearbeitungsanwendungen hinzugefügt werden, um Elemente als visuell intuitive Schachtelung zur besseren Druckausrichtung darzustellen. Ob diese Leerräume gerendert werden, hängt wiederum vom Inhaltsmodell des Elements ab. Das Festlegen von xml:space="preserve" auf der Stammebene wird nicht empfohlen, da die Mehrheit der Objektmodelle Leerräume in der Regel nicht als signifikant betrachten. Die empfohlene Vorgehensweise besteht darin, das Attribut nur auf der Ebene der Elemente festzulegen, die Leerräume in Zeichenfolgen rendern oder bei denen es sich um leerraumsignifikante Auflistungen handelt.
Entitäten und feste Leerzeichen: XAML unterstützt das Platzieren beliebiger Unicode-Entitäten in einem Textobjektmodell. Sie können dedizierte Entitäten wie feste Leerzeichen (  in UTF-8-Codierung) verwenden. Sie können auch Rich-Text-Steuerelemente verwenden, die feste Leerzeichen unterstützen. Sie sollten bei der Verwendung von Entitäten, die Layoutmerkmale wie Einzüge simulieren, vorsichtig vorgehen, da die Laufzeitausgabe der Entitäten von einer größeren Anzahl an Faktoren abhängig ist als die allgemeinen Layoutmöglichkeiten, wie zum Beispiel die ordnungsgemäße Verwendung von Fensterbereichen und Rändern. So sind Entitäten Schriften zugeordnet und können ihre Größe ändern, je nachdem, welche Schrift der Benutzer auswählt.
Ostasiatische Zeichen
"Ostasiatische Zeichen" werden als Satz von Unicode-Zeichenbereichen von U+20000 bis U+2FFFD und U+30000 bis U+3FFFD definiert. Diese Teilmenge wird manchmal auch als "CJK-Ideogramme" bezeichnet. Weitere Informationen finden Sie unter http://www.unicode.org.