Intern behandelt Imperia alle Meta-Informationen und Assets als (8-Bit-)Binärdaten, macht also keinerlei Annahmen darüber, in welchem Codeset textuelle Daten eingegeben oder gespeichert werden. Diese Vorgehensweise erlaubt die größtmögliche Flexibilität, da sie nicht nur die gleichzeitige Speicherung von Informationen in beliebigen Kodierungen, sondern daneben sogar die zwanglose Verwaltung von echten Binärdaten erlaubt. Eine Klassifizierung der Meta-Informationen kann aber jederzeit über geeignete Namenskonventionen für Meta-Variablen erreicht werden, auch wenn die Praxis zeigt, dass dieser Aufwand meist gar nicht nötig ist.
Interne Informationen (zum Beispiel Menü-Titel, Grid-Parameter oder aber auch die Beschriftungen von Buttons in der OneClickEdit-Toolbar) speichert Imperia mittlerweile bevorzugt in UTF-8 ab, und wandelt sie erst für die Anzeige in ein geeignetes Codeset um. Es soll allerdings nicht verschwiegen werden, dass dieser zu bevorzugende Weg von Imperia noch nicht durchgehend beschritten wird, eine Tatsache, die bei der Umsetzung von Projekten bereits frühzeitig bedacht werden sollte.
Jeder in Imperia angemeldete User besitzt die Möglichkeit, in seinen persönlichen Einstellungen sowohl die Sprache, als auch das zur Anzeige verwendete Charset frei zu wählen. Trifft ein einzelner User keine Auswahl, werden stattdessen die systemweiten Einstellungen (über den Menüpunkt „“ zugänglich) verwendet. In der Regel wird es sinnvoll sein, hier eine funktionierende systemweite Einstellung zu wählen, um Fehlkonfigurationen der Redakteure vorzubeugen. In zukünftigen Imperia-Versionen wird es genau aus diesem Grunde möglich sein, eine abweichende persönliche Konfiguration durch die einzelnen User zu unterbinden. Eine ungeeignete Einstellung kann faktisch dazu führen, dass sich User aus dem System aussperren, weil sie zum Beispiel als Sprache Russisch und als Charset Latin-1 wählen. Da Latin-1 keinerlei russische Schriftzeichen enthält, wird sich die Imperia-Oberfläche daraufhin jedoch mit Fragezeichen (der Ersatzdarstellung für nicht-darstellbare Zeichen) übersät präsentieren, was eine Korrektur der Fehleinstellung natürlich stark erschwert.[2]
Natürlich wäre es möglich, solcherlei Fehleingaben abzufangen, allerdings nur auf Kosten der Flexibilität des Systems. Da die Software in beliebige Sprachen übersetzt werden kann, ist es schlechterdings unmöglich, mit Softwaremitteln zu entscheiden, ob eine bestimmt Kombination aus Sprache und Charset zu einer sinnvollen Darstellung führt. Die in der Praxis nicht relevante Gefahr, dass bestimmte Einstellungen zu temporären Einschränkungen in der Bedienbarkeit führen, wird daher bewusst in Kauf genommen. Der jetzige Zustand ist ohnehin lediglich als Übergang zu betrachten. Mittelfristig wird Imperia intern komplett auf Unicode umgestellt, sobald davon ausgegangen werden kann, dass alle unterstützten Browsertypen und -versionen Unicode problemlos verarbeiten können.
Welche Wirkung haben diese Einstellungsmöglichkeiten aber nun, wo Imperia Content doch in neutraler Binärform behandelt? Tatsächlich wird von diesen Parametern lediglich die Darstellung der Imperia-Oberfläche beeinflusst. Als Web-Applikation erzeugt Imperia selbst ja permanent HTML-Seiten bzw. HTML-Formulare, die über HTTP zum Browser übertragen werden. Die Charset-Einstellung bewirkt dabei zweierlei: Erstens werden alle lokalisierten Texte der Imperia-Oberfläche in dieses Charset konvertiert, und zweitens sorgt das System durch die Übermittlung der korrekten HTTP-Header dafür, dass die Browser diese Texte dann auch richtig darstellen.
Eine wichtige Ausnahme stellen die Seiten dar, die direkt aus Templates generiert werden. Bei diesen Seiten übermittelt Imperia keine entsprechenden HTTP-Header, um den Templateprogrammierern die volle Freiheit bei der Wahl des Dokumenten-Charsets zu überlassen. Wie dies im Detail erfolgen sollte, wird weiter unten noch beschrieben.
Dem bisher Gesagten mag man entnehmen, dass eine Fehlkonfiguration des Charsets lediglich zu Unregelmäßigkeiten in der Darstellung der Oberfläche führen kann. Dem ist leider nicht so, weil Imperia bidirektional mit den Benutzern interagiert: Das System übermittelt (Text-)Daten zum Benutzer, die Benutzer übermitteln umgekehrt (Formular-)Daten zurück zum System. Der Rückkanal birgt dabei einige Schwierigkeiten.
Die Übermittlung von Daten vom Benutzer/Client zum Imperia-Server erfolgt durchweg über HTML-Formulare. Wird in Imperia zum Beispiel UTF-8 als Charset eingestellt, führt dies dazu, dass Imperia dieses Charset auch in den HTTP-Headern der HTML-Seiten übermittelt, worauf die Browser entsprechend reagieren (sollten): Geht der Browser davon aus, dass die HTML-Seite in UTF-8 kodiert ist, wird er auch die Formulareingaben in UTF-8 zum Server zurückschicken. Bei einem UTF-8-Formular wird der Browser also für das Zeichen „ä“ ein Multi-Byte-Sequenz in UTF-8 zurücksenden. Geht der Browser dagegen von Latin-1 aus, „sieht“ Imperia ein 8-Bit-Zeichen (ein Byte, die „Hausnummer“ des „ä“ in Latin-1). Dieses Verhalten erweist sich an einzelnen Stellen, an denen Imperia aus Kompatibilitätsgründen intern noch nicht auf Unicode umgestellt wurde, als erheblicher Stolperstein.
In erster Linie treten diese Schwierigkeiten noch bei der Datenhaltung für die Rubrik- und User- bzw. Rolleninformationen auf, genauergesagt bei allen Daten, die direkt oder mittelbar in Templates ausgewertet werden können. Diese Schwierigkeiten lassen sich derzeit nicht vermeiden, da ansonsten die Abwärtskompatibilität des Systems nicht mehr gewährleistet wäre.
Konkret stellt sich das Problem so dar: User U hat als System-Charset UTF-8 eingestellt, und erzeugt eine Rubrik, die deutsche Umlaute im Namen enthält, und legt weiterhin einen neuen User L an, und vergibt für L auch gleich ein Passwort, ebenfalls mit Umlaut. Der Browser wird die entsprechenden Formulardaten in UTF-8 übermitteln, die Umlaute kommen bei Imperia also als Multi-Byte-Sequenzen an, und Imperia wird sie - so wie sie sind - als Binärdaten abspeichern.
Wenn User L sich jetzt versucht, in Imperia einzuloggen, kommt es zum ersten Problem: Imperia hat das Passwort in UTF-8 gespeichert, übermittelt wird es jetzt jedoch in Latin-1, dem Charset, das für User L eingestellt wurde. Der (binäre) Vergleich der Passwörter wird fehlschlagen, und als Konsequenz kann User L sich nicht erfolgreich anmelden. Nicht nur aus diesem Grunde sollte man sich bei Passwörtern grundsätzlich auf ASCII-Zeichen beschränken.
Das nächste Problem, dem L sich gegenübersieht, ist weniger kritisch, aber noch immer ärgerlich: Auch die Informationen der Rubrik, die von U angelegt wurde, sind in Unicode (bzw. UTF-8) abgelegt worden. Die Anzeige des Rubrikenbaums für L erfolgt jedoch in Latin-1. Sonderzeichen in UTF-8 sind Multi-Byte-Sequenzen, diese werden von Imperia ohne Modifikation übertragen, und L wird statt dieser Sonderzeichen nur eine Folge von zwei bis sechs 8-Bit-Zeichen sehen.
Die Moral der Geschichte ist, dass administrativ unbedingt sichergestellt werden sollte, dass die Wahl des Charsets einheitlich erfolgt. Dies bedeutet nicht zwangsläufigerweise, dass alle User mit dem gleichen Charset arbeiten müssen; denkbar wäre zum Beispiel, bei allen Mitgliedern der deutschen Redaktion ISO-8859-1 einzustellen, bei allen Mitgliedern der russischen Redaktion dagegen KOI8-R. Für diesen Fall muss allerdings entweder durch eine geeignete Rechtevergabe sichergestellt werden, dass die Mitglieder der einen Redaktion die Daten der anderen gar nicht erst sehen, oder aber zumindest darüber aufgeklärt werden, dass die (Read-Only-)Daten der jeweils anderen Redaktion „entstellt“ übermittelt werden.
Auf template-basierte Seiten hat die Wahl des in Imperia konfigurierten Charsets keinen Einfluss, und dies aus gutem Grund. Das System erlaubt die Erzeugung von Dokumenten in beliebigen, auch innerhalb einer Imperia-Installation voneinander abweichenden Charsets, und deshalb übermittelt das System hier keine entsprechenden HTTP-Header; die Charset-Information entnimmt der Browser lediglich den Informationen aus dem Template selbst. Hieraus ergibt sich, dass Templates grundsätzlich ein entsprechendes Meta-Tag enthalten sollten, z. B.
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
Bei neuen Projekten sollte als Charset im (Eingabe-)Template vorzugsweise UTF-8 verwendet werden, da dies dazu führt, dass Imperia auch den eingegebenen Content in UTF-8 abspeichert. Wir werden später sehen, dass es leicht möglich ist, die Daten - völlig unabhängig von der Wahl des Charsets im Eingabetemplate - später in beliebigen anderen Charsets zu publizieren. Umgekehrt gilt dies leider nicht: Hat man sich einmal im Template auf beispielsweise Latin-1 festgelegt, ist es später nicht mehr ohne weiteres möglich, das Charset zu wechseln oder evtl. weitere Sprachen zu unterstützen, die nicht mehr in Latin-1 dargestellt werden können. Unicode steht für das universelle Codeset, aus dem praktisch alle anderen Kodierungen erzeugt werden können. Wenn irgend möglich, sollte man diese universelle Wiederverwendbarkeit auch ausnutzen.
Aber auch bei der Wahl des Template-Charsets kann es zu vereinzelten (unangenehmen) Wechselwirkungen mit der Wahl des System- bzw. User-Charsets kommen: So ist die Editieransicht teilweise mit Elementen der Imperia-Bedienoberfläche durchsetzt, so zum Beispiel bei den Flexmodul-Boxen oder auch den Tooltips für die Buttons zum Speichern oder die Voransicht. Diese Elemente werden entsprechend den Charset-Einstellungen dargestellt, da Imperia (noch) nicht erkennen kann, auf welches Charset ein Template ausgelegt ist. Typisches Beispiel ist die Beschriftung „Ausführen“ in den Flexmodul-Boxen. Weicht das Imperia-Charset vom Template-Charset ab, wird es hier zu (harmlosen!) Fehldarstellungen kommen.
Problematischer wird es bei Anzeigen, die aus Imperia-Strukturdaten gewonnen werden, z. B. User- oder Rubrikdaten:
Bearbeiter: <!--USER_CONF:fname--> <--USER_CONF:name--> Rubrik: <--SECTION:NAME:0-->
Auch hier vermag Imperia weder festzustellen, in welchem Charset diese Daten eingepflegt wurden, noch in welchem Charset sie ausgegeben werden sollen, und wird sie deshalb unmodifiziert als Binärdaten einfügen. Sollte jedoch das Charset des Eingabetemplates vom in Imperia eingestellten Charset abweichen, wird es hier zwangsläufig zu Fehlern kommen, sobald die entsprechenden Daten nicht aus dem Zeichenvorrat von US-ASCII stammen.
Meta-Dateien werden von Imperia im konfigurierten Charset dargestellt. Es ist also darauf zu achten, dass beschreibende Zusatztexte ebenfalls in diesem Charset kodiert sind. Andererseits werden aus Meta-Dateien natürlich auch Daten über Usereingaben gewonnen, die dann ebenfalls im eingestellten Charset abgespeichert werden. Werden diese Daten später im Template verwendet, ist dementsprechend sicherzustellen, dass sie im Template-Charset darstellbar sind.
Wie bereits erwähnt, trifft Imperia alle Vorkehrungen, um die HTML-Dateien bzw. Formulare im redaktionellen Workflow so zu übermitteln, dass der Browser das erwartete Charset korrekt interpretieren kann. Damit dies auch funktioniert, ist es natürlich unbedingt erforderlich, dass der Web-Server die entsprechenden Daten auch unverändert übermittelt, die jeweiligen HTTP-Header also nicht überschreibt. Insbesondere der Web-Server Apache wird jedoch oft so ausgeliefert, dass ein Standard-Charset für alle ausgelieferten Daten eingestellt wird (siehe hierzu Abschnitt 1.2.1, „Die Konfigurationsanweisung AddDefaultCharset“), was diese Bemühungen zunichte macht. Sollte Imperia trotz aller Bemühungen also die eigenen HTML-Dateien/-Formulare nicht den Einstellungen entsprechend ausliefern, hilft hier oft die Direktive AddDefaultCharset Off in der Serverkonfiguration.
Die Ausführungen der vorhergehenden Abschnitte lassen erahnen, dass die Vermischung verschiedener Charsets zu teilweise recht erheblichen Problemen führen kann. Wann immer dies möglich ist, sollte man sich daher von vorneherein auf ein geeignetes Charset festlegen, und dieses durchgehend in Imperia verwenden. Prinzipiell kann dies jedes Charset sein, sofern es nicht mit der bevorzugten Benutzersprache in Konflikt steht, aus praktischen Erwägungen sollte jedoch UTF-8 hier stets bevorzugt in Betracht gezogen werden, selbst für den klassischen Fall einer rein deutschsprachigen Site. Unicode bzw. UTF-8 als universelles Charset lässt sich verlustfrei in jedes beliebige andere Charset umwandeln, Imperia liefert schon mit Bordmitteln alle notwendigen Werkzeuge hierfür, eine Festlegung auf UTF-8 stellt also gerade keine Festlegung dar, sondern lässt für die Zukunft alle Freiheiten, sei es für die Erweiterung des Auftritts um weitere Sprachen oder auch für die Syndizierung des eigenen Contents in sprachneutraler Form. Wurde als einheitliches Charset UTF-8 gewählt, beschränkt sich die Konvertierung des kompletten Auftritts auf eine triviale Änderung der Templates und einen Lauf des Template-Reparsers, während die kurzsichtige Festlegung auf (veraltete) 8-Bit-Zeichensätze doch zu mehr oder weniger schmerzhaften Migrationsprozessen bei der Annahme neuer Herausforderungen führen kann.
Der vorhergehende Abschnitt sollte verdeutlicht haben, dass Imperia intern über sehr mächtige Funktionen zur Verarbeitung und Konvertierung textueller Daten in beliebigen Charsets verfügt. Es vermag daher nicht zu überraschen, dass diese Funktionen an verschiedenen Stellen des Systems „durchscheinen“ und auch für eine redaktionelle Verwendung nutzbar gemacht werden. Dies reicht von Erweiterungen der Template-Syntax (beispielsweise der lokalisierten Generierung von Datum bzw. Zeit über die Template-Direktive Xstrftime) bis hin zur automatischen Konvertierung von Content zwischen beliebigen Charsets. Diese Features sind in den mit der Software ausgelieferten Handbüchern dokumentiert, und werden teilweise im weiteren Verlauf einer eingehenderen Betrachtung unterzogen.
[2] Eine Zurücksetzung auf eine sinnvolle Einstellung ist natürlich weiterhin möglich, da die entsprechenden Menüpunkte noch immer über aussagekräftige Icons erreichbar sind. Die Sprach- und Charsetauswahl wiederum wird von Imperia nicht in die bevorzugte Sprache übersetzt, und die entsprechenden Drop-Downs sind ausschließlich mit ASCII-Zeichen beschriftet, wordurch die Darstellbarkeit in allen unterstützten Charsets gewährleistet ist.
| Guido Flohr | Imperia AG | Impressum |