Der programmierte Textversteher

Textverarbeitung mit Textprozessoren – die Idee einer idealen Welt
Keine Kommentare

Die Darstellung von selbst erstellten, formatierten Texten auf Webseiten birgt einige Tücken, vor allem im Hinblick auf Sicherheitsrisiken. Aber auch die Frage der Portierbarkeit weist einige Einschränkungen auf. Betrachten wir einmal die etablierten Standards, um einige Überlegungen zu einer idealen Welt der Textbearbeitung und dem Formatieren von Inhalten anzustellen.

Einer der bekanntesten und damit auch verbreitetsten WYSIWYG-Texteditoren im World Wide Web ist CKEditor, der nach eigenen Angaben um die 20.000 Anwender zählt. Auf der Homepage findet sich die aktuelle Version zum Download, sowie eine umfangreiche Dokumentation. Die hohe Beliebtheit verdankt die Bibliothek ihrem großen Funktionsumfang und der vielen Anpassungsmöglichkeiten an eigene Bedürfnisse. Auch ist die Liste der verfügbaren Textprozessoren, mit denen der CKEditor den eingegebenen Text formatieren kann, sehr umfangreich. Codierungen wie BBCode, WikiSyntax und viele mehr sind auswählbar. Bevor wir uns allerdings weiteren Details zuwenden, wollen wir zuerst einige Überlegungen allgemeiner Art anstellen.

Formatierungen arbeiten auf Basis einer Auszeichnungssprache, der sogenannten Markup Language. So werden für den entsprechenden Textbereich der Anfang sowie das Ende der Formatierung gekennzeichnet. Bei HTML ist es nicht anders, auch hier werden die Textbereiche entsprechend ihrer semantischen Bedeutung in sogenannte Tags eingeschlossen. Möchte man einen abgegrenzten Bereich beispielsweise farblich hervorheben, kann man sich des Tags <font> bedienen, das anhand seiner Attribute Farbe, Schriftgröße und Schriftart definiert. Aber auch das Attribute Style, das nahezu in jedem Tag erlaubt ist, gestattet zahlreiche optische Anpassungen. Es ist klar, dass stark formatierter Text den Quelltext enorm anwachsen lässt. Auch widerspricht dieser Ansatz der üblichen Forderung der Trennung von Programm und Darstellung, wie es in dem MVC-Entwurfsmuster beschrieben ist. Diese Überlegungen führten zu den Cascading Style Sheets, die es ermöglichen, das Layout vom Programm zu trennen. HTML dient in dieser Konstellation als reine Markierung (Selektoren) der zu formatierenden Bereiche, denen mittels CSS die gewünschte Darstellung zugewiesen wird. Eine sehr praktische Eigenschaft von CSS ist die Vererbungsfähigkeit der Selektoren, wie es das Cascading im Namen bereits suggeriert. Das führt bei korrekter und konsequenter Verwendung zu sehr kompaktem Sourcecode. Um das Bild abzurunden, sei der Vollständigkeit halber noch JavaScript erwähnt, das HTML um ein Aktionsmodell erweitert, das gestattet, Aktionen wie beispielsweise Manipulationen des Syntaxbaums auf die HTML-Struktur anzuwenden.

Strukturschwächen

Bei diesem kleinen Exkurs wird schnell deutlich, dass sich die Speicherung von Texten zu einem komplizierten Unterfangen gestalten kann. Das zielt vor allem auf die mögliche spätere Portierbarkeit ab. Je komplexer ein Text formatiert wurde, umso schwieriger lässt er sich in einen anderen Standard transformieren. Die Konsequenz erleben wir zum Beispiel bei Vorhaben wie dem Tauschen der Dokumentationsplattform gegen ein neueres System. So lassen sich nicht ohne Weiteres Inhalte aus dem MediaWiki nach Confluence portieren. In vielen Fällen muss das Layout manuell korrigiert werden, obwohl es sich bei beiden Systemen um Wikis handelt. Daran zeigt sich, dass die Wiki-Syntax nicht standardisiert ist. Es gibt auch Überschneidungen zu anderen Formaten wie dem Makedown, das auf GitHub Verwendung findet. Die gleichen Effekte beobachtet man auch bei der Nutzung unterschiedlicher Versionen von MS Word. Obwohl es sich dabei um dasselbe Produkt handelt, ist die Kompatibilität zueinander problematisch.

Sicher mag es auf den ersten Blick trivial erscheinen, aber die Trennung von Inhalt und Formatierung ist eher eine kompromissbehaftete Angelegenheit. Wer einmal das Vergnügen hatte, sich im Rahmen eines Hochschulseminars in das Universum von LaTeX einzuarbeiten, hat eine etwaige Vorstellung davon, wie komplex Dokumente sein können. Sie beinhalten allzu oft Tabellen, Formeln und Grafiken, die es ebenfalls zu berücksichtigen gilt. Mit DocBook existiert ein weiterer Standard, um Dokumente semantisch zu strukturieren. Er wurde für die maschinelle Verarbeitung zur Erstellung von Büchern, Artikeln und Dokumentationen entwickelt und basiert auf XML.

Sicherheitsbedenken

Wenden wir uns nun möglichen Sicherheitsrisiken zu, die dadurch entstehen, dass Nutzer ihre Eingaben selbstständig layouten dürfen. Schließlich möchte man der eigenen Applikation keine Türen zum Cross-site Scripting (XSS) und anderen Angriffsvektoren öffnen. Dazu sei auch das Buch „PHP-Sicherheit“ [1] empfohlen, das als Standardlektüre im Bücherschrank eines jeden Webentwicklers zu finden sein sollte.

International PHP Conference

How Much Framework?

by Arne Blankerts (thePHP.cc)

Building a Cloud-Friendly Application

by Larry Garfield (Platform.sh)

Crafting Maintainable Laravel Applications

by Jason McCreary (Pure Concepts, LLC)

JavaScript Days 2020

Wie ich eine React-Web-App baue

mit Elmar Burke (Blendle) und Hans-Christian Otto (Suora)

Architektur mit JavaScript

mit Golo Roden (the native web)


Ein sehr alter Ansatz ist eine Whitelist mit HTML-Tags, die von Anwendern im Text verwendet werden dürfen. Zwar funktioniert diese Strategie recht gut, aber die Möglichkeiten sind doch sehr eingeschränkt. Ein Vertreter dieser Strategie sind die BBCodes, die sich vor allem dadurch auszeichnen, dass sie HTML-Tags sehr ähnlich sind, lediglich die Spitzklammern wurden durch eckige ersetzt. Das soll möglichen Konflikten mit dem originalen Quellcode vorbeugen. Damit der Inhalt auch korrekt dargestellt werden kann, muss der BBCode mittels eines entsprechenden Textprozessors zur Laufzeit in HTML umgewandelt werden. Auf stark frequentierten Webseiten kann das zu Performanzeinbußen führen, weswegen die Ausgabe oftmals in einem Cache vorgehalten wird. Bei eigenen Implementierungen von Tokenersetzungen sollte besondere Sorgfalt auf Anführungszeichen gelegt werden. Sie sollten möglichst vollständig durch ihre HTML-Escape-Zeichen ersetzt werden.

Hin und wieder kommt es vor, dass Anwender die Steueranweisungen für Formatierungen manuell eingeben. Bei fehlerhafter Notation kann das dazu führen, dass die Webseite nicht mehr angezeigt werden kann. Ein solcher Zustand ist natürlich sehr ärgerlich und sollte möglichst vermieden werden. Damit das gelingt, ist eine Validierung notwendig, die Syntaxfehler für den Nutzer hervorhebt und das Abspeichern solange verhindert, bis sämtliche Probleme behoben wurden. Viele Werkzeuge bringen diese Funktionalität implizit mit. WordPress transformiert beispielsweise manuell eingegebenes HTML im Editor während des Abspeicherns nach eigenen Regeln. Das macht die Textbearbeitung manchmal zur Geduldsprobe, wenn man eine sehr spezielle Anweisung hinterlegen möchte, die das Editiersystem unter keinen Umständen in ihrer Reinform entgegennehmen möchte. Ein Klassiker ist das Einbinden von Flash-Filmen auf WordPress.com, mangels geeigneten Plug-ins im kostenfreien Account.

Individualismus

Wägt man die bereits beschriebenen Punkte gegeneinander ab, könnte man auf die Idee kommen, sich an einer eigenen Umsetzung zu versuchen. Grund für ein solches Vorhaben wäre beispielsweise die Bereitstellung von Texten in unterschiedlichen Formaten, wie es beim E-Publishing der Fall ist. Üblicherweise stellen die Anbieter ihren Kunden mehrere Varianten wie EPUB, DOCX oder PDF als Download zur Auswahl bereit. Sicher lässt sich die Transformation zwischen den einzelnen Formaten über HTML bewerkstelligen, aber eine robustere Lösung hat durchaus auch ihren Charme.

Um unsere Bemühungen nicht allzu sehr ausschweifen zu lassen, wollen wir uns auf wenige Basisfunktionen beschränken und den Fokus auf die Konzeption legen. Die wichtigste Anforderung ist, möglichst wenig Formatierungen gemeinsam mit dem Inhalt abzuspeichern. Daraus ergeben sich implizit zwei Punkte, die es zu berücksichtigen gilt. Es ist logisch, eine manuelle Bearbeitung der Rohinhalte auszuschließen. Sie würde zu ähnlichen Effekten führen, wie das bei Datenbanken mit verknüpften Tabellen der Fall ist. Die Chance durch manuelle Editierung Inkonsistenzen herbeizuführen ist äußerst hoch. Der zweite Aspekt ist, wie bereits im vorangegangenen Abschnitt erwähnt, das Caching. Schließlich soll die Anwendung ihre Anwender nicht durch lange Ladezeiten verärgern.

Texte können in verschiedene Kategorien aufgeteilt werden, von denen die verbreitetsten das Buch oder der Artikel sind. Blogeinträge zählen von ihrer Struktur her ebenfalls zu den Artikeln. Die wichtigste Strukturierung eines Textes erfolgt durch Absätze. Diese haben verschieden Kontexte, wie Kapitel, Abstract oder Überschriften und werden immer durch einen Zeilenumbruch eingeleitet. Eine weitere Anforderung an eine Publikation sind Metadaten wie ISBN, Autor, Erscheinungsjahr, Auflage oder Version, um nur einige zu nennen. Auch hierfür muss das Rad aber nicht neu erfunden werden, sondern wir nutzen JSON, um solche Informationen in der ersten Zeile des Contents abzulegen.

Zur Hinterlegung sämtlicher Layoutinformationen, bedienen wir uns einer separaten Datei, bzw. Datenbanktabelle. Wie die von den Cascading Style Sheets bekannten Selektoren nutzen auch wir für unsere Referenzen einen ähnlichen Ansatz. Eine eindeutige Position im Text wird durch die Zeilen- und Zeichennummer referenziert. Unsere Konvention lautet [Zeile:Zeichen] oder [Zeile:*] für eine gesamte Zeile, aber auch Intervalle lassen sich problemlos formulieren, wie die Notation [Zeile:ZeichenStart-ZeichenEnde] demonstriert. Diese Referenzen lassen sich nun Formatierungsklassen wie Überschrift, Absatz, fettgedruckt oder Textfarbe zuordnen.

Natürlich gilt es, im Vorfeld sämtliche vorgesehenen Formatierungsklassen mit ihren HTML-Ersetzungsregeln festzulegen. Ein einfaches Beispiel für eine solche Regel für die Formatierungsklasse bold (fett) für HTML lautet: B=<b>#</b>. Die Raute steht als Platzhalter für den einzufügenden Text. Auf diese Weise lassen sich bei Bedarf sehr komplexe Grammatiken formulieren. Um ein möglichst optimales Resultat zu erzielen, sollte bei den Ersetzungsregeln auf ein möglichst minimales und robustes HTML geachtet werden, frei nach dem KISS-(Keep-it-simple,-stupid-)Prinzip. Terence Parrs Buch zu ANTLR [2] sei an dieser Stelle als weiterführende Literatur empfohlen.

In Abbildung 1 ist die vorgestellte Lösung schematisch dargestellt und hilft, einen Eindruck von der Funktion zu vermitteln. Eine berechtigte Frage, die noch nicht beantwortet wurde, ist der Umgang mit Grafiken und Verlinkungen. Aber auch das ist kein allzu kompliziertes Unterfangen. Verlinkungen und Grafiken sind ebenfalls Formatierungsklassen zugewiesen. Bei einem Link dient der Verlinkungstext, der üblicherweise durch den <a>-Tag eingeschlossen ist, als Referenz im Text. Die Notation im Layout ist als [Zeile:ZeichenStart-ZeichenEnde:URL] definiert.

Grafiken hingegen haben keine Repräsentation im Inhalt und werden ausschließlich im Layout definiert. Der Layoutklasse für Grafik steht die Notation [Zeile:Datei:Ausrichtung:Höhe:Breite] zur Verfügung. Es ist zu berücksichtigen, dass Bilder entweder über eine WWW-Referenz oder einen Dateipfad verknüpft werden können.

Redaktionssysteme benötigen neben strengen Workflows zur Qualitätssicherung, auch eine Versionierung. Dank der Trennung des Inhaltes von der Darstellung lassen sich feingranulare Berechtigungen formulieren. So kann ein Grafiker beispielsweise keine Änderungen an Inhalten vornehmen, während er am Layout arbeitet. Aber auch eine Versionierung von Inhalten und automatisierte Rechtschreibkorrekturen lassen sich so wesentlich leichter integrieren. Damit haben wir die wichtigsten Aspekte auch schon besprochen und der Implementierung steht nichts mehr im Weg.

Abb. 1: Schematische Darstellung zur Trennung von Inhalt und Layout

Abb. 1: Schematische Darstellung zur Trennung von Inhalt und Layout

Resümee

Unsere kurze Abhandlung gibt einen Einblick, wie schwierig es sein kann, für Menschen lesbare Inhalte in elektronischer Form langfristig aufzubewahren, ohne die wunderbaren Vorteile maschineller Verarbeitung zu verlieren. Schließlich hat man im Laufe der Jahre die Volltextsuche in Dokumenten schätzen gelernt. Wer sich tiefgreifender mit der Thematik auseinandersetzen möchte, dem sei als Einstieg ebenfalls der Artikel „What is Text, Really?“ [3] ans Herz gelegt.

Links & Literatur

  • [1] Kunz, Christopher; Esser, Stefan: „PHP-Sicherheit“, 3. Aufl., dpunkt.verlag, 2008
  • [2] Parr, Terence: „The Definitive ANTLR 4 Reference“, O’Reilly, 2013
  • [3] DeRose, Steven J. et al.: „What is Text, Really?“, in: Journal of Computing in Higher Education I, 2 (1990), S. 3-26.

 

PHP Magazin

Entwickler MagazinDieser Artikel ist im PHP Magazin erschienen. Das PHP Magazin deckt ein breites Spektrum an Themen ab, die für die erfolgreiche Webentwicklung unerlässlich sind.

Natürlich können Sie das PHP Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Kiosk ist das PHP Magazin weiterhin im Print-Abonnement erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -