Freigeben über

Leerraumverarbeitung in XAML

  • Artikel

Die Sprachregeln für DEN XAML-Zustand, dass erheblicher Leerraum von einer XAML-Prozessorimplementierung verarbeitet werden muss. In diesem Artikel werden diese XAML-Sprachregeln dokumentiert. Außerdem werden zusätzliche Leerraumbehandlungen dokumentiert, die durch die Windows Presentation Foundation (WPF)-Implementierung des XAML-Prozessors und den XAML-Writer für die Serialisierung definiert werden.

Leerzeichendefinition

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

Normalisierung des Leerraums

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

  1. Zeilenfeedzeichen zwischen ostasiatischen Zeichen werden entfernt. Eine Definition dieses Begriffs finden Sie im Abschnitt "Ostasiatische Zeichen" weiter unten in diesem Thema.

  2. Alle Leerzeichen (Leerzeichen, Zeilenfeed, Tabstopp) werden in Leerzeichen konvertiert.

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

  4. Ein Leerzeichen, das unmittelbar auf das Starttag folgt, wird gelöscht.

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

"Default" entspricht dem Zustand, der durch den Standardwert des attributs xml:space gekennzeichnet ist.

Leerzeichen im inneren Text und Zeichenfolgengrundtypen

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

  • Wenn der Typ der Eigenschaft keine Auflistung ist, aber nicht direkt ein Object Typ ist, versucht der XAML-Prozessor, mithilfe seines Typkonverters in diesen Typ zu konvertieren. Eine fehlgeschlagene Konvertierung führt hier zu einem Kompilierungsfehler.

  • Wenn der Typ der Eigenschaft eine Auflistung ist und der innere Text zusammenhängend ist (keine dazwischen liegenden Elementtags), wird der innere Text als einzelnes Stringanalysiert. Wenn der Sammlungstyp Stringnicht akzeptieren kann, führt dies auch zu einem Kompilierungsfehler.

  • Wenn der Typ der Eigenschaft Objectist, wird der innere Text als einzelne Stringanalysiert. Wenn elementtags vorhanden sind, verursacht dies einen Kompilierzeitfehler, da der Object Typ ein einzelnes Objekt impliziert (String oder anderweitig).

  • Wenn es sich bei dem Typ der Eigenschaft um eine Auflistung handelt und der innere Text nicht zusammenhängend ist, wird die erste Teilzeichenfolge in eine String konvertiert und als Sammlungselement hinzugefügt, das dazwischen liegende Element wird als Sammlungselement hinzugefügt, und schließlich wird die nachfolgende Teilzeichenfolge (sofern vorhanden) der Auflistung als drittes String Element hinzugefügt.

Beibehalten des Leerraums

Es gibt mehrere Techniken zum Beibehalten von Leerraum im Quell-XAML für eine spätere Präsentation, die von der Normalisierung des XAML-Prozessors nicht betroffen sind.

xml:space="preserve": Geben Sie dieses Attribut auf der Ebene des Elements an, auf dem die Leerraumkonservierung gewünscht ist. Dadurch bleibt der gesamte Leerraum erhalten, der die Räume enthält, die von Codebearbeitungsanwendungen hinzugefügt werden können, um Elemente als visuell intuitives Schachteln auszurichten. Ob diese Leerzeichen gerendert werden, wird jedoch vom Inhaltsmodell für das enthaltende Element bestimmt. Vermeiden Sie die Angabe von xml:space="preserve" auf Der Stammebene, da die meisten Objektmodelle unabhängig davon, wie Sie das Attribut festlegen, keinen Leerraum als signifikant betrachten. Das Globale Festlegen xml:space kann auswirkungen auf die Leistung bei der XAML-Verarbeitung (insbesondere serialisierung) in einigen Implementierungen haben. Es empfiehlt sich, das Attribut nur auf der Ebene der Elemente festzulegen, die Leerzeichen innerhalb von Zeichenfolgen rendern oder signifikante Sammlungen mit Leerzeichen darstellen.

Entitäten und nicht unterbrechende Leerzeichen: XAML unterstützt das Platzieren einer Unicode-Entität innerhalb eines Textobjektmodells. Sie können dedizierte Entitäten wie geschütztes Leerzeichen (  in UTF-8-Codierung) verwenden. Sie können auch Rich-Text-Steuerelemente verwenden, die geschützte Leerzeichen unterstützen. Sie sollten vorsichtig sein, wenn Sie Entitäten verwenden, um Layoutmerkmale wie z. B. Einzug zu simulieren, da die Laufzeitausgabe der Entitäten je nach einer größeren Anzahl von Faktoren variiert, als die Funktionen für die Erstellung eines Einzugs zu einem typischen Layoutsystem führen würden, z. B. die ordnungsgemäße Verwendung von Panels und Rändern. Entitäten werden beispielsweise Schriftarten zugeordnet und können die Größe als Reaktion auf die Auswahl der Benutzerschriftart ändern.

Ostasiatische Zeichen

"Ostasiatische Zeichen" wird als Satz von Unicode-Zeichenbereichen U+20000 bis U+2FFFD und U+30000 bis U+3FFFD definiert. Diese Teilmenge wird manchmal auch als "CJK-Ideographen" bezeichnet. Weitere Informationen finden Sie unter https://www.unicode.org.

Leerraum- und Textinhaltsmodelle

In der Praxis ist die Beibehaltung des Leerraums nur für eine Teilmenge aller möglichen Inhaltsmodelle von Bedeutung. Diese Teilmenge besteht aus Inhaltsmodellen, die einen Singleton-String Typ in irgendeiner Form, eine dedizierte String Sammlung oder eine Mischung aus String und anderen Typen in einer IList- oder ICollection<T>-Auflistung annehmen können.

Leerraum- und Textinhaltsmodelle in WPF

Zur Veranschaulichung verweist der Rest dieses Abschnitts auf bestimmte Typen, die von WPF definiert werden. Die in diesem Artikel beschriebenen Funktionen für die Verarbeitung von Leerzeichen sind sowohl für .NET-XAML-Dienste als auch für WPF relevant. Um dieses Verhalten in Aktion zu sehen, experimentieren Sie möglicherweise mit einigen WPF-XAML-Markups, zeigen Die Ergebnisse in einem Objektdiagramm an, und serialisieren Sie dann erneut zum Markup.

Auch bei Inhaltsmodellen, die Zeichenfolgen annehmen können, ist das Standardverhalten in diesen Inhaltsmodellen, dass alle leerzeichen, die verbleiben, nicht als signifikant behandelt werden. Beispielsweise akzeptiert ListBox eine IList, aber der Leerraum (z. B. Zeilenfeeds zwischen den einzelnen ListBoxItem) wird nicht beibehalten und nicht gerendert. Wenn Sie versuchen, Zeilenfeeds als Trennzeichen zwischen Zeichenfolgen für ListBoxItem Elemente zu verwenden, funktioniert dies überhaupt nicht. die Zeichenfolgen, die durch die Zeilenfeeds getrennt sind, werden als eine Zeichenfolge und ein Element behandelt.

Diese Auflistungen, die Leerraum als signifikant behandeln, sind in der Regel Teil des Flussdokumentmodells. Die primäre Sammlung, die das Erhaltungsverhalten von Leerzeichen unterstützt, ist InlineCollection. Diese Sammlungsklasse wird mit dem WhitespaceSignificantCollectionAttributedeklariert; Wenn dieses Attribut gefunden wird, behandelt der XAML-Prozessor Leerraum innerhalb der Sammlung als signifikant. Die Kombination aus xml:space="preserve" und Leerzeichen innerhalb einer WhitespaceSignificantCollectionAttribute gekennzeichneten Auflistung besteht darin, dass alle Leerzeichen beibehalten und gerendert werden. Die Kombination aus xml:space="default" und Leerzeichen innerhalb eines WhitespaceSignificantCollectionAttribute bewirkt, dass die zuvor beschriebene anfängliche Leerraumnormalisierung, die einen Leerraum an bestimmten Positionen hinterlässt, und diese Leerzeichen beibehalten und gerendert werden. Welches Verhalten wünschenswert ist, liegt bei Ihnen, und Sie sollten xml:space selektiv verwenden, um das gewünschte Verhalten zu aktivieren.

Außerdem sollten bestimmte Inlineelemente, die einen Zeilenumbruch in einem Flussdokumentmodell konnoten, absichtlich keinen zusätzlichen Platz auch in einer erheblichen Sammlung von Leerzeichen einführen. Beispielsweise hat das LineBreak-Element den gleichen Zweck wie das <BR/>-Tag in HTML und zur Lesbarkeit im Markup, in der Regel wird ein LineBreak von jedem nachfolgenden Text durch einen autorierten Zeilenfeed getrennt. Dieser Zeilenfeed sollte nicht normalisiert werden, um ein führendes Leerzeichen in der nachfolgenden Zeile zu werden. Um dieses Verhalten zu ermöglichen, wendet die Klassendefinition für das LineBreak-Element die TrimSurroundingWhitespaceAttributean, die dann vom XAML-Prozessor interpretiert wird, um zu bedeuten, dass leerer Platz um LineBreak immer gekürzt wird.

Siehe auch