Die üblichen Verdächtigen – Stolperfallen beim Umgang mit elektronischen Texten

„Ich ❤ Unicode.“

In der Technischen Redaktion arbeiten wir mit digitalen Texten. Mal erstellen wir sie selbst, mal bekommen wir sie von Kollegen, Kunden oder Partnern. Häufig haben wir beim Inhalt ein Wörtchen mitzureden, aber fast immer spielt der formale Umgang mit Text eine Rolle – ob es nun darum geht, zugelieferte Teildokumente zu einem Ergebnis zusammenzubauen, oder in einem Migrationsprojekt Textbestände in ein neu installiertes Redaktionssystem zu übernehmen, oder darum, im laufenden Produktionsbetrieb Inhalte aus dem CMS in Ausgabeformate wie HTML oder JSON zu verpacken.

Inhalte wollen von Format A nach Format B oder aus System X nach System Y gebracht werden – und jedesmal wieder droht die Gefahr, sich in immer denselben Fallstricken zu verheddern. Deswegen haben wir hier einmal die üblichen Verdächtigen – Verzeihung: die üblichen Verdächtigen – zusammengestellt. Und da es doch eine Reihe von Verdächtigen gibt, führen wir die Gegenüberstellung in zwei Teilen aus. Hier im ersten Teil: Probleme mit Zeichencodierung und Textauszeichnungen.

Zeichencodierung

Doppelcodierung

Im Kontext von HTML sind Ihnen die Entity-Codierungen wie „ü“ für „ü“ sicherlich bekannt. Alles, was den Hauch eines Sonderzeichens an sich trägt (weil es nicht im Umfang des amerikanischen ASCII-Zeichensatzes enthalten ist), wird auch heute noch häufig in solche Entitäten umgewandelt. In XML allerdings ist „ü“ von Haus aus keine bekannte Entität, während aber das Zeichen „&“ selbst ein Sonderfall im HTML- und XML-Kontext ist und eine kodierte Entsprechung als „&“ hat. Aus „ü“ wird in HTML also „ü“ – und bei der nächsten XML-Weiterverarbeitung dann „ü“. In solch einem Fall spricht man von Doppelcodierung; sie tritt z. B. auf, wenn die verwendete (vielleicht selbst geschriebene?) Software nicht erkennt, ob ein „&“ Teil einer bereits kodierten Entität ist oder tatsächlich ein „und“ bezeichnet. Hatten Sie auch schon derartige Schlüssel-Erlebnisse?

Unterschiedliches Encoding

Beim Schreiben und Lesen von digitalen Texten soll die Zeichenkodierung sicherstellen, dass das vom Verfasser eingegebene Schriftzeichen vom Leser auch genauso wieder erkannt werden kann. Leider wird aber gerade auch bei deutschen oder englischen Texten mal eine, mal eine andere Zeichenkodierung verwendet, die zwar teilweise Gemeinsamkeiten, aber eben auch Unterschiede zueinander aufweisen (z. B. ISO-8859-15, Windows-1252, UTF-8 mit und ohne BOM). Und wenn Texte, die unterschiedliches Encoding verwenden, nicht sauber zusammengeführt werden, geht Information verloren. Das Resultat sind fehlende Zeichen bzw. Platzhaltersymbole wie Fragezeichen o. Ä., die auf einmal im Text erscheinen. Daher: Aufs Encoding achten und ggf. in ein einheitliches Format konvertieren!

Keine Unicode-Unterstützung

Eigentlich sollte Unicode uns von diesen Problemen fehlender Zeichencode-Kompatibilität befreien. Leider gibt es da zwei Probleme:

• Problem 1: Es sind immer noch zahlreiche Texte in anderer Kodierung im Umlauf (siehe oben). Wir können uns also schlicht und ergreifend nicht darauf verlassen, Unicode-Texte zu erhalten.
• Problem 2: Es sind auch immer noch sehr viele Tools und Schriftarten im Einsatz, die Unicode nicht beherrschen. Die Sonderzeichen ebenfalls bestenfalls als Fragezeichen oder leere Kästchen darstellen oder im schlimmsten Fall durch kryptische Zeichenkombinationen wie „ä“ oder „„“ ersetzen und damit vollkommen verhunzen. Und die ihrerseits natürlich wiederum Nicht-Unicode-Texte produzieren und damit weiter zu Problem 1 beitragen.

Vergewissern Sie sich also, ob die von Ihnen verwendete Software Unicode-Texte korrekt darstellt, verarbeitet und ausgibt – und wenn nicht, wie Sie damit umgehen können.

Codierung in Skripten

Wenn Sie noch ein bisschen tiefer in die Textmigration und Weiterverarbeitung von Texten einsteigen, stolpern Sie noch über ganz andere Probleme. Beispielsweise hinsichtlich der Codierung von Zeichen in Skripten, etwa in JavaScript. Während Sie in HTML oder XML Kodierungen wie „‑“ oder „‑“ kennen, notieren Sie in JavaScript den Unicode-Codepunkt „\u2011“. Das will sauber kodiert, dekodiert und konvertiert werden.

Named entities, mit „Namen“ referenzierbare Entities, gibt es in HTML einige (von ü über ß zu … …), in XML von Haus aus nur eine kleine Handvoll. Dafür können Sie in XML eigene named entities definieren, mit denen HTML aber wiederum nichts anzufangen weiß. Auch hier: Überblick behalten bei der Migration!

Anführungszeichen stellen regelmäßig ein Problem dar, wenn Daten in Strukturen wie SQL oder JSON gespeichert und ausgelesen werden. Anführungszeichen haben dort nämlich eine eigene Bedeutung und bezeichnen Beginn oder Ende von Datenwerten. In den Objektdaten müssen sie daher kodiert werden. Geschieht das Kodieren und Dekodieren unsauber, drohen entstellte Texte und im schlimmsten Fall Datenverlust.

Auszeichnung und Semantik

Textteile, Wörter, Zeichen werden bei der Bearbeitung ausgezeichnet, je nach … ihrer Bedeutung? Ihrem gewünschten Erscheinungsbild im Dokument? Hier beginnt das Problem bereits, und es manifestiert sich insbesondere beim Zusammenführen von Dokumenten oder beim Wechsel des Auszeichnungsformats:

• Da wird die gleiche nicht-semantische Auszeichnung für verschiedene Sachverhalte angewendet, beispielsweise werden sowohl Oberflächenelemente als auch Signalwörter einfach fett ausgezeichnet; sowohl Handlungsanweisungen als auch Stücklisten in Form von nummerierten Listen strukturiert.
• Da werden unterschiedliche Auszeichnungen für gleiche Sachverhalte angewendet; so erscheint eine Parameterliste mal als Tabelle, mal als Liste; Oberflächenelemente sind mal fett, mal kursiv ausgezeichnet.
• Da werden semantisch definierte Auszeichnungen zweckentfremdet – „Für die Kapiteleinleitung können wir doch das Format ‘Warnhinweis’ nehmen, das erzeugt so einen schönen grau hinterlegten Kasten …“
• Die zusammenzuführenden Dokumente weisen einen unterschiedlichen Grad der Semantik auf: Im einen Dokument sind nur Absatzformate bzw. Stil-Eigenschaften definiert, das andere Dokument ist stärker semantisch definiert und enthält Auszeichnungen für „Arbeitsschritte“ oder „Warnhinweise“.

Solche Fälle verhindern ein eindeutiges Mapping eines Dokuments auf ein anderes Dokument. Auch wenn zwei Dokumente bereits im XML-Format vorliegen, bedeutet das nicht, dass eine Zusammenführung ohne Weiteres – ohne nähere Analyse – funktionieren kann. Dafür müssen Sie die Dokumentmodelle kennen und prüfen, ob die Texte sauber ausgezeichnet sind – siehe auch den folgenden Punkt „CDATA“.

CDATA

Nicht die Liebe zum Geld, sondern CDATA-Bereiche sind die Wurzel allen Übels. „Das ist alles XML“ bedeutet gerne, dass in einem überschaubaren, wohlgeformten und validen Daten-Gerüst mit ein paar wenigen unterschiedlichen XML-Tags ein Wust von nicht oder unsauber HTML-formatierten CDATA-Blobs eingeklebt ist wie seinerzeit die selbst ausgeschnittenen Kinderfotos und welken Blätter im Poesiealbum aus der Grundschule. In der Regel sind diese Datenblöcke durch keinen Algorithmus automatisiert bearbeitbar und müssen von Hand nachbearbeitet werden. Deswegen unbedingt prüfen, ob das zu verarbeitende XML keine CDATA-Blöcke enthält.

Wenn Sie diese Themen und Tipps beachten, sind Sie schon auf einem guten Weg bei der Migration von Textinhalten. Vollständig ist diese Auflistung natürlich trotzdem noch lange nicht; jede Konstellation von Ausgangs- und Zielformat, Bearbeiter und Software kann neue Überraschungen bringen. Daher ist bei der Dokumentmigration Umsicht und ein professioneller Blick nicht nur hilfreich, sondern notwendig.

Und dann gibt es ja neben den „reinen“ Texten auch noch andere Themen wie Bilder, Layout etc. Dies besprechen wir bald ebenfalls an dieser Stelle, in einem zweiten Teil zum Thema „Verbreitete Stolperfallen beim Umgang mit elektronischen Texten“. Bleiben Sie dran!