Was heißt Unicode und warum sollte ich es einschalten?

Posted on by Philip Hulsebosch — No Comments ↓


Man hat ein gutes Applikationsdesign gemacht und sogar einen schönen Namen für eine neue Applikation gefunden.
Jetzt geht es an die Arbeit: Applikation erstellen. Aber dann sieht man diese einfache, kleine, unscheinbare Option und denkt sich – soll ich da jetzt einen Haken setzen oder nicht?

Ich spreche hier von Unicode.

Was bedeutet es eigentlich und wann sollte man es einschalten?
Nun, Unicode regelt, dass Schriftzeichen richtig dargestellt werden. In einem Rechner können Spracheinstellungen gewählt werden die sogenannte „Locale“. Diese ermöglicht, sprachenspezifische Buchstaben darzustellen, z.B. Buchstaben mit Umlaut. Die Locale bestimmt auch das Datumsformat und das bekannte Dezimalzeichen.
Damit Softwareentwickler über die ganze Welt nicht immer das Rad neu erfinden müssen hat man sich geeinigt auf ein System.
Die Zeichen werden in einen Code umgewandelt der universell ist. Soweit ich weiß, verwendet die EPM Suite immer UTF-8 zur Kodierung. Die Kodierung in den Unicode Standard ermöglicht es u.a., die Buchstaben mit Umlaut auch auf einem Rechner mit US-Englischer Locale richtig darzustellen.

Was sind die Vorteile?
Wenn man also in einer internationalen Organisation arbeitet, sollte die Unicode-Option eigentlich immer eingeschaltet werden.
Hiermit werden dann die Schriftzeichen der verschiedenen Ländereinstellungen in den Unicode umgewandelt und können in allen anderen Ländereinstellungen auch wieder richtig dargestellt. Sonst sieht man Wörter wie „Kn□ckebr□d“.
Es ermöglicht also, eine Aliastabelle zu erstellen, in der dann die z.B. Elementnamen in Russischer Sprache in Kyrillischer Schrift stehen. Sehr praktisch für den Agenten in Moskau.
Der kann seine Vertriebszahlen in Rubel (lokale Währung) und in Russisch präsentieren. Sein Deutscher Kollege kann dieselben Zahlen in Rubel (lokale Währung) und Euro (nach Wechselkursumwandlung) in Deutsch darstellen.

Ein anderer Vorteil ist, dass Essbase für Objektnamen nicht auf seine 8 Zeichen begrenzt ist. Die Grenze erhöht sich auf 30 Zeichen und dass ist oft sehr praktisch. Aber hier doch der kleine Hinweis auf die Goldenen Regeln: Sich nicht verführen lassen, um Sonderzeichen in Objektnamen zu verwenden!

Gibt es Nachteile?
Ja.

  • Die Objekte einer Unicode Applikation sind nicht kompatibel mit einer Nicht-Unicode Applikation. Daher empfiehlt es sich, einen Betriebsstandard zu haben und einzuhalten. Eine Nicht-Unicode Applikation kann in eine Unicode-Applikation umgewandelt werden, aber es gibt keinen Weg zurück.
    Werden Daten oder Metadaten in Textdateien hochgeladen, müssen diese mit UTF-8 kodiert sein. In einem modernen Texteditor kann dieses problemlos eingestellt werden, erfordert aber unter Umständen einen weiteren Arbeitsschritt.
    Wenn dieses automatisiert ablaufen soll, dann gibt es das Essbase Unicode File Utility (ESSUTF8.exe).
  • Die End-Anwender-Tools müssen Unicode unterstützen. Für Financial Reports und SmartView ist dieses kein Problem, das klassische Essbase Add-In unterstützt dieses leider nicht. Beim Anmelden gibt es eine Warnung. Ich konnte zum Glück immer weiter gut damit arbeiten, aber es ist schade, dass dieses Supertool Unicode nicht unterstützt.

    • Zum Schluss:
    Wenn kein Unicode eingestellt wird (Nicht-Unicode Applikation), dann gilt die Locale des Essbase Servers. Dieses ist die ESSLANG Variable auf dem Server.

    TIPP:
    Mit dem Essbase Unicode File Utility (ESSUTF8.exe) kann man nicht nur Text Dateien in Unicode kodieren, sondern auch Nicht-Unicode Objekte in Unicode Objekte umwandeln. Dieses kann auch verwendet werden, wenn eine Locale umgestellt werden muss.
    So hatte ich mal den Fall, dass ein Server mit der falschen Locale installiert wurde. Erst als wir die bereits erstellten Objekte auf einen anderen Server kopieren wollten, bemerkten wir den Fehler.

    nach oben

    Ähnliche Beiträge

    Veröffentlicht in Installation, Konfiguration & Tuning Verwendete Schlagwörter: , ,

    Schreibe einen Kommentar