Leerstellenverarbeitung in XAML

Artikel
05/04/2023

Gemäß den Sprachregeln für XAML müssen signifikante Leerräume von einer XAML-Prozessorimplementierung verarbeitet werden. Dieser Artikel dokumentiert diese XAML-Sprachregeln. Es dokumentiert auch die zusätzliche Behandlung von Leerzeichen, die von der Windows Presentation Foundation (WPF) Implementierung des XAML-Prozessors und des XAML-Writers für die Serialisierung definiert wird.

Leerzeichen-Definition

Im Einklang mit XML sind Leerzeichen in XAML Leerzeichen, Zeilenfeed und Registerkarte. Diese entsprechen den Unicode-Werten 0020, 000A und 0009.

Normalisierung von Leerzeichen

Standardmäßig findet bei der Verarbeitung einer XAML-Datei durch einen XAML-Prozessor die folgende Leerraumnormalisierung statt:

Zeilenvorschubzeichen zwischen ostasiatischen Zeichen werden entfernt. Eine Definition dieses Begriffs finden Sie im Abschnitt „Ostasiatische Zeichen“ weiter hinten in diesem Thema.
Alle Leerraumzeichen (Leerzeichen, Zeilenvorschub, Tabulator) werden in Leerzeichen konvertiert.
Alle aufeinander folgenden Leerzeichen werden gelöscht und durch ein Leerzeichen ersetzt.
Ein Leerzeichen unmittelbar nach dem Starttag wird gelöscht.
Ein Leerzeichen unmittelbar vor dem Endtag wird gelöscht.

„Standard“ entspricht dem Zustand, der durch den Standardwert des xml:space -Attribut bezeichnet wird.

Leerraum in innerem Text und Zeichenfolgenprimitive

Die oben genannten Normalisierungsregeln gelten für inneren Text innerhalb von XAML-Elementen. Nach der Normalisierung konvertiert ein XAML-Prozessor inneren Text wie folgt in einen entsprechenden Typ:

Wenn der Typ der Eigenschaft keine Auflistung, aber nicht direkt ein Object -Typ ist, versucht der XAML-Prozessor, unter Verwendung seines Typkonverters eine Konvertierung in diesen Typ durchzuführen. Ein Konvertierungsfehler verursacht einen Fehler zu Kompilierzeit.
Wenn der Typ der Eigenschaft eine Auflistung und der innere Text zusammenhängend ist (keine dazwischen liegenden Elementtags), wird der innere Text als einzelner Stringanalysiert. Wenn der Auflistungstyp Stringnicht akzeptieren kann, führt dies ebenfalls zu einem Kompilierzeitfehler.
Wenn der Typ der Eigenschaft Objectist, wird der innere Text als einzelner Stringanalysiert. Wenn dazwischen liegende Elementtags vorhanden sind, führt dies zu einem Kompilierzeitfehler, da der Object -Typ ein einzelnes Objekt impliziert (String oder anderes).
Wenn der Typ der Eigenschaft eine Auflistung und der innere Text nicht zusammenhängend ist, wird die erste Teilzeichenfolge in einen String konvertiert und als Auflistungselement hinzugefügt, das dazwischen liegende Element wird als Auflistungselement hinzugefügt, und schließlich wird die nachgestellte Teilzeichenfolge (sofern vorhanden) der Auflistung als drittes String -Element hinzugefügt.

Beibehalten von Leerraum

Es gibt mehrere Verfahren zum Beibehalten von Leerräumen in der Quell-XAML für die nachfolgende Darstellung, die nicht von der Leerraumnormalisierung durch den XAML-Prozessor betroffen sind.

XML: space = "preserve": Legen Sie dieses Attribut auf der Ebene des Elements fest, für das Leerräume beibehalten werden sollen. Hierdurch werden alle Leerräume beibehalten, auch die Leerzeichen, die ggf. von Codebearbeitungsanwendungen als visuell intuitive Schachtelung hinzugefügt werden, um Elemente für den Schöndruck auszurichten. Ob diese Leerzeichen gerendert werden, wird jedoch durch das Inhaltsmodell für das enthaltende Element bestimmt. Vermeiden Sie die Angabe von xml:space="preserve" auf der Stammebene, da die meisten Objektmodelle Leerräume nicht als signifikat betrachten, unabhängig davon, wie Sie das Attribut festlegen. Die globale Festlegung von xml:space kann in einigen Implementierungen die Leistung der XAML-Verarbeitung (insbesondere der Serialisierung) beeinträchtigen. Es ist besser, das Attribut nur auf der Ebene von Elementen spezifisch festzulegen, die Leerräume in Zeichenfolgen rendern oder leeraumsignifikate Auflistungen sind.

Entitäten und geschützte Leerzeichen: In XAML kann eine beliebige Unicodeentität innerhalb eines Textobjektmodells angegeben werden. Sie können dedizierte Entitäten wie geschützte Leerzeichen ( in UTF-8-Codierung) verwenden. Sie können auch Rich-Text-Steuerelemente verwenden, die geschützte Leerzeichen unterstützen. Seien Sie vorsichtig, wenn Sie Entitäten zum Simulieren von Layouteigenschaften wie Einzügen verwenden, da die Laufzeitausgabe der Entitäten basierend auf einer größeren Anzahl von Faktoren variiert, als dies bei den Funktionen zum Erzeugen von Einzugsergebnisse in einem typischen Layoutsystem der Fall ist, z. B. richtige Verwendung von Bereichen und Rändern. Beispielsweise werden Entitäten Schriftarten zugeordnet und können sich als Reaktion auf eine Schriftartauswahl durch den Benutzer in der Größe ändern.

Ostasiatische Zeichen

Mit ostasiatischen Zeichen sind die Unicode-Zeichenbereiche „U+20000 bis U+2FFFD“ und „U+30000 bis U+3FFFD“ gemeint. Diese Teilmenge wird manchmal auch als „CJK-Ideogramme“ bezeichnet. Weitere Informationen finden Sie unter https://www.unicode.org.

Leerraum- und Textinhaltsmodelle

In der Praxis ist das Beibehalten von Leerräumen nur für eine Teilmenge aller möglichen Inhaltsmodelle von Bedeutung. Diese Teilmenge besteht aus Inhaltsmodellen, die eine Form von Singleton- String -Typ, eine dedizierte String -Auflistung oder eine Mischung aus String und anderen Typen in einer IList - oder ICollection<T> -Auflistung verwenden können.

Leerraum- und Textinhaltsmodelle in WPF

Zur Veranschaulichung bezieht sich der Rest dieses Abschnitts auf bestimmte von WPF definierte Typen. Die in diesem Artikel beschriebenen Funktionen zur Behandlung von Leerraum sind sowohl für .NET XAML Services als auch für WPF relevant. Um diese Verhaltensweisen in Aktion zu sehen, können Sie mit einigen WPF-XAML-Markups experimentieren, die Ergebnisse in einem Objektdiagramm anzeigen und dann wieder zurück zu Markup serialisieren.

Sogar für Inhaltsmodelle, die Zeichenfolgen unterstützen, besteht das Standardverhalten innerhalb dieser Inhaltsmodelle darin, dass alle verbleibenden Leerräume als nicht signifikant behandelt werden. Beispielsweise verwendet ListBox eine IList, aber der Leerraum (wie z. B. Zeilenvorschübe zwischen den einzelnen ListBoxItem-Elementen) wird nicht beibehalten und nicht gerendert. Wenn Sie versuchen, Zeilenvorschübe als Trennzeichen zwischen Zeichenfolgen für ListBoxItem -Elemente zu verwenden, funktioniert dies nicht; alle durch die Zeilenvorschübe getrennten Zeichenfolgen werden als eine Zeichenfolge und ein Element behandelt.

Diese Auflistungen, die Leerräume als signifikant behandeln, sind in der Regel Teil des Flussdokumentmodells. Die primäre Auflistung, die die Beibehaltung von Leerräumen unterstützt, ist InlineCollection. Diese Auflistungsklasse wird mit dem WhitespaceSignificantCollectionAttributedeklariert; wenn dieses Attribut gefunden wird, behandelt der XAML-Prozessor Leerräume in der Auflistung als signifikant. Die Kombination von xml:space="preserve" und Leerräumen in einer mit WhitespaceSignificantCollectionAttribute bezeichneten Auflistung führt dazu, dass alle Leerräume beibehalten und gerendert werden. Die Kombination von xml:space="default" und Leerräumen in einem WhitespaceSignificantCollectionAttribute bewirkt die weiter oben beschriebene anfängliche Leerraumnormalisierung, die ein Leerzeichen an bestimmten Positionen beibehält; diese Leerzeichen werden beibehalten und gerendert. Welches Verhalten Sie bevorzugen, steht Ihnen frei, und Sie sollten xml:space selektiv verwenden, um das gewünschte Verhalten zu aktivieren.

Außerdem dürfen bestimmte Inlineelemente, die einen Zeilenumbruch in einem Flussdokumentmodell darstellen, nicht absichtlich ein zusätzliches Leerzeichen einfügen, selbst nicht in einer leerraumsignifikaten Auflistung. Beispiel: Das LineBreak-Element hat den gleichen Zweck wie das <BR/>-Tag in HTML, und zur besseren Lesbarkeit im Markup wird ein LineBreak in der Regel durch einen erstellten Zeilenvorschub von nachfolgendem Text getrennt. Dieser Zeilenvorschub darf nicht zu einem voranstellten Leerzeichen in der nächsten Zeile normalisiert werden. Um dieses Verhalten zu aktivieren, wendet die Klassendefinition für das LineBreak-Element das TrimSurroundingWhitespaceAttributean, das dann vom XAML-Prozessor so interpretiert wird, dass Leerraum um LineBreak immer entfernt werden soll.