Leerstellenverarbeitung in XAML

Die Sprachregeln für DEN XAML-Zustand, dass signifikanter Leerraum von einer XAML-Prozessorimplementierungen verarbeitet werden muss. In diesem Artikel werden diese XAML-Sprachregeln beschrieben. Darüber hinaus wird die Verarbeitung zusätzlicher Leerzeichen dokumentiert, die von der WPF-Implementierung (Windows Presentation Foundation) des XAML-Prozessors und des XAML-Writers für die Serialisierung definiert wird.

Leerraumdefinition

Im Einklang mit XML sind Leerzeichen in XAML Leerzeichen, Zeileneinfügezeichen und Registerkarten. Diese entsprechen den Unicode-Werten 0020, 000A bzw. 0009.

Leerraumnormalisierung

Standardmäßig erfolgt die folgende Leerraumnormalisierung, wenn ein XAML-Prozessor eine XAML-Datei verarbeitet:

  1. Zeilenvorschubzeichen zwischen ostasiatischen Zeichen werden entfernt. Eine Definition dieses Begriffs finden Sie im Abschnitt „Ostasiatische Zeichen“ weiter hinten in diesem Thema.

  2. Alle Leerzeichen (Leerzeichen, Zeilenaufschub, Tabulator) werden in Leerzeichen konvertiert.

  3. Alle aufeinander folgenden Leerzeichen werden gelöscht und durch ein Leerzeichen ersetzt.

  4. Ein Leerzeichen unmittelbar nach dem Starttag wird gelöscht.

  5. Ein Leerzeichen unmittelbar vor dem Endtag wird gelöscht.

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

Leerzeichen im inneren Text und Zeichenfolgenprimitive

Die vorherigen Normalisierungsregeln gelten für inneren Text, der in XAML-Elementen gefunden wird. Nach der Normalisierung konvertiert ein XAML-Prozessor jeden inneren Text wie folgt in einen geeigneten Typ:

  • Wenn der Typ der Eigenschaft keine Auflistung, aber kein direkter Object Typ ist, versucht der XAML-Prozessor, mithilfe seines Typkonverters in diesen Typ zu konvertieren. 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 Leerräumen

Es gibt mehrere Techniken zum Beibehalten von Leerraum im XAML-Quell-XAML für die letztliche Darstellung, die von der Leerraumnormalisierung des XAML-Prozessors nicht betroffen sind.

xml:space="preserve": Geben Sie dieses Attribut auf der Ebene des Elements an, in dem die Beibehaltung von Leerzeichen gewünscht ist. 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 xml:space="preserve" auf Stammebene, da die meisten Objektmodelle Leerraum unabhängig davon, wie Sie das Attribut festlegen, nicht als signifikant betrachten. Die globale Festlegung von xml:space kann in einigen Implementierungen die Leistung der XAML-Verarbeitung (insbesondere der Serialisierung) beeinträchtigen. Es empfiehlt sich, das -Attribut nur auf der Ebene von Elementen festzulegen, die Leerzeichen innerhalb von Zeichenfolgen rendern, oder es handelt sich um Auflistungen mit signifikanten Leerräumen.

Entitäten und Nicht-Breaking Spaces: XAML unterstützt das Platzieren beliebiger Unicode-Entitäten in einem Textobjektmodell. Sie können dedizierte Entitäten verwenden, z. B. nicht unterbrochenen Speicherplatz (  in UTF-8-Codierung). 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

"Ostasiatische Zeichen" ist als Satz von Unicode-Zeichenbereichen 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 https://www.unicode.org.

Leerraum- und Textinhaltsmodelle

In der Praxis ist die Beibehaltung von Leerzeichen 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 Leerraumbehandlungsfunktionen sind sowohl für .NET-XAML-Dienste 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.

Selbst bei Inhaltsmodellen, die Zeichenfolgen annehmen können, besteht das Standardverhalten in diesen Inhaltsmodellen darin, dass leer bleibende Leerzeichen nicht als signifikant behandelt werden. beispielsweise nimmt ein IListan, ListBox aber der Leerraum (z. B. Zeilenfeeds zwischen den einzelnen ListBoxItem) 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.

Die Sammlungen, die Leerraum als signifikant behandeln, sind in der Regel Teil des Flowdokumentmodells. Die primäre Auflistung, die das Leerraumaufbewahrungsverhalten unterstützt, ist InlineCollection. Diese Auflistungsklasse wird mit deklariert WhitespaceSignificantCollectionAttribute. Wenn dieses Attribut gefunden wird, behandelt der XAML-Prozessor Leerzeichen innerhalb der Auflistung als signifikant. Die Kombination aus xml:space="preserve" und Leerraum innerhalb einer WhitespaceSignificantCollectionAttribute bezeichneten Auflistung besteht darin, dass der gesamte Leerraum beibehalten und gerendert wird. Die Kombination aus xml:space="default" und Leerraum in einer WhitespaceSignificantCollectionAttribute bewirkt die zuvor beschriebene anfängliche Leerraumnormalisierung, die einen Leerzeichen an bestimmten Positionen hinterlässt, und 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.

Darüber hinaus sollten bestimmte Inlineelemente, die einen Zeilenbruch in einem Flowdokumentmodell enthalten, absichtlich keinen zusätzlichen Platz auch in einer Auflistung mit signifikanten Leerräumen einführen. Beispielsweise hat das LineBreak -Element den gleichen Zweck wie das <BR/> -Tag in HTML, und zur Lesbarkeit im Markup wird in der Regel ein LineBreak von jedem nachfolgenden Text durch ein erstelltes Zeilenfeed 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 den TrimSurroundingWhitespaceAttributean, der dann vom XAML-Prozessor interpretiert wird, um zu bedeuten, dass die Umgebenden LineBreak Leerzeichen immer abgeschnitten werden.

Weitere Informationen: