4.1.11  Character Mappings in der Ausgabe

Die Umstellung von XHTML auf HTML5 war nicht unbedingt ein Fortschritt, wenn es um die Verarbeitung der Strukturen mittels XSLT geht. Denn ein HTML5 Dokument kann im Gegensatz zu XHTML auch nicht abgeschlossene Tags beinhalten.
Man muss also zunächst das HTML5 mittels z.B. HTML Tidy ↗ valide machen und nach XHTML überführen, bevor man es dann per XSLT weiterverarbeiten kann. Natürlich frägt sich jetzt der geneigte Leser, warum man das will - schließlich handelt es sich bei HTML5 ja schon um ein Ausgabeformat.
Mir fallen auf Anhieb zwei Use Cases ein:
  • Reverse Engineering eines Ausgabepakets der Konkurrenz, um die Daten in das eigene CCMS zu importieren
  • Web scraping mittels XSLT
Aber auch schon einen Schritt vorher, wenn Saxon den Ausgabebaum für HTML5 schreibt, können Probleme auftreten. Insbesondere wenn sich unmaskierte Sonderzeichen, die im XML erlaubt sind - aber im HTML nicht - ausgegeben werden sollen.
Unmaskierte Sonderzeichen, die in HTML nicht erlaubt sind, kommen in der XML Eingabe vor.
Bei einer <xsl:output> Deklaration für HTML wird es in diesem Fall zu einem Saxon Fehler kommen.

4.1.11.1  Zeichen entfernen

Ein Lösungsweg wäre die HTML5 Deklaration zu lassen, aber die wenigen bekannten Zeichen, die in der XML Eingabe vorkommen können, auf erlaubte Entities zu mappen oder zu entfernen. Letzteres habe ich z.B. so in der freien Wildbahn gesehen:
<xsl:character-map name="html">
   <xsl:output-character character="&#148;" string=""/>
   <xsl:output-character character="&#149;" string=""/>
[...]
Das Hex Entity No. 148 ist z.B. ein spezielles Anführungszeichen ↗, das im obigen Beispielquelltext einfach mittels der Character Map aus dem Ausgabebaum entfernt wird. Das Zeichen kann dann in einem Fehlerlog ausgegeben werden, und die Transformation läuft durch. Natürlich sollte man sich aber auch überlegen, warum ein solches Zeichen unmaskiert in die XML Eingabe gelangt ist.
M.E. ist es am besten einen XHTML Doctype zu verwenden und nicht abgeschlossene HTML5 Tags zu verbieten.

4.1.11.2  Zeichen als Entity sichtbar machen

Ein anderer Use Case für so eine Character Map wäre, unsichtbare Zeichen sichtbar zu machen. Z.B. stellen XML Editoren, wie XMetal, auch unsichtbare Zeichen im Klartext dar. Man sieht also nicht, ob z.B. ein geschütztes Leerzeichen oder ein geschützter Bindestrich bedatet ist. Die folgende Character Map Deklaration würde diese Zeichen als Entität sichtbar machen - möglich ist das z.B. als Vorprozessierung der XMetal Eingabe, wenn diese Zeichen per Copy 'n Paste eingefügt werden:
<xsl:character-map name="desired-entities">
  <xsl:output-character character="&#x00A0;" string="&amp;nbsp;"/>
  <xsl:output-character character="&#x2011;" string="&amp;nbhy;"/>
</xsl:character-map>
Hilfreich ist in diesem Zusammenhang vielleicht auch die Möglichkeit, dass Saxon direkt Entities in den Ausgabebaum schreiben kann. Hierzu gibt es die Erweiterung saxon:character-representation , vgl. Saxon Doku ↗

4.1.11.3  Exkurs

Sonderzeichen-Probleme in Browsern
Als letztes Beispiel für die Verwendung einer Character Map möchte ich Legacy Probleme bei der Zeichendarstellung in den verschiedenen Browsern anführen.
Bevor es den Unicodestandard gab - dieser erreichte erst 1991 die Version 1.0 - hat Adobe für bestimmte Zeichen in den Fonts und Zapf Dingbats eigene Codepunkte vergeben, die mit Unicodezeichen ggf. kollidieren. Es gibt Mapping Tabelle für Symbol ↗ und . Einige Codepunkte in diesen Tabellen befinden sich aber in der sogenannten "Private Use Area" des Unicode Standards, die proprietären Anwendungen vorbehalten ist. Die Browser unterstützen diese PUA Zeichen unvollständig und Firefox, Chrome und Internet Explorer stellen bestimmte Zeichen fehlerhaft dar. Firefox schneidet hier am schlechtesten ab. Ich musste im Internet Archive nachschlagen, um eine gut Quelle zu finden, die dieses Problem genauer beschreibt, vgl. hier ↗.
Wir halten einmal fest:
  • Das Default Character Set für den HTML5 Doctype UTF-8.
  • Per XSLT werden die Zeichen normalerweise als Hex-Entities herausgeschrieben. Das ist eine Nummer, die eine Position im Unicode Standard Zeichensatz angeben sollte. Einige Glyphennummern der betreffenden Nicht-Unicode-Problemfonts passen aber nicht auf die Unicodevorgabe und die Zeichen werden fehlerhaft dargestellt.
  • Die Mapping Tabellen von Adobe korrigieren das Problem aber leider unvollständig, denn hier werden bestimmte Glyphen auf einen, in Unicode vorgesehenen, Vendor-abhängigen Bereich "Private Use Area" abgebildet. Das sind c.a. 43 Zeichen, die bei Ansicht im Browser Firefox nicht gehen, leider sind darunter auch wichtige Symbole, wie Copyright, Registered und Trademark.
Previous PageNext Page
Map Version: