Seltsame Phänomene …


28. März 2012, von in EGIS, IT

… kann es auch in der IT manchmal geben. Meistens lassen sie sich aber bei genauerer Betrachtung dann doch auflösen. Gestern hatten wir so einen Fall.

Im EGIS werden PDFs aus Vorlagen von einer Applikation namens EGISPrintServer erzeugt, die vom EGIS über HTTP angesprochen wird. Benötigte Parameter wie Preise oder variable Texte werden dabei normalerweise als GET-Parameter übergeben. Beides sind WebObjects-Applikationen. Nachdem wir vor Kurzem unsere Entwicklungsumgebung endlich auf ein aktuelles Eclipse mit aktuellem WOLips-Plugin umgestellt hatten, haben wir festgestellt, dass ein vom EGIS an den EGISPrintServer übergebenes €-Symbol auf dem PDF nicht richtig dargestellt wurde.

Wir haben uns also die Seite im EGIS genauer angesehen, die den EGISPrintServer mit dem Text aufruft, der das „€“ enthält. Dort wurde die URL mit entsprechenden Parametern zusammengebaut und per java.net.URLEncoder als ISO-8859-15 codiert. Soweit also in Ordnung. Im EGISPrintServer wurde der entsprechende Parameter per formValuesForKey(String) aus dem WORequest ausgelesen und dann wurde versucht, ihn mittels URLEncoder wieder zu decodieren – offensichtlich ein Bug, da der von formValuesForKey() zurückgelieferte Parameter schon von WO decodiert wurde, allerdings per Default als ISO-8859-1. Blöd, aber kann ja mal vorkommen und lässt sich zum Glück schnell korrigieren. Das Encoding, mit dem WO die GET-Parameter decodiert, kann per WOMessage.setDefaultURLEncoding(String) gesetzt werden, am besten gleich im Konstruktor der Application. Wo wir schonmal dabei waren, haben wir da UTF-8 gesetzt und den Aufruf auf Seiten des EGIS entsprechend geändert.

Soweit so gut, jetzt sollte also alles passen. Keine seltsamen Phänomene bisher. Aber dann wurde es interessant. Wenn ich das EGIS kompiliert hatte, funktionierte alles wie gewünscht. Als mein Kollege allerdings das Testsystem deployt hatte, war das „€“ auf dem PDF wieder falsch dargestellt, es musste also immer noch ein Problem mit dem Encoding geben. Nur welches und wo?

Am EGISPrintServer lag es nicht, egal wer von uns ihn kompiliert hat, es funktionierte immer dann nicht, wenn mein Kollege das EGIS gebaut hatte. Der Java-Code war auch richtig, die Klasse im EGIS, die die URL erstellt, codiert und dann den EGISPrintServer  aufruft, war bei meinem Kollegen und bei mir identisch. Auch das die Klasse, die in einem Formatter das „€“ lieferte, schien gleich. Da aber ganz offensichtlich für das „€“ unterschiedliche Bytes verwendet wurden, habe ich mal mit einem Hexeditor einen Blick in die .class-Dateien geworfen, und tatsächlich, bei mir stand in dem String mit dem „€“ ganz ordentlich  E2 82 AC, in der von meinem Kollegen erzeugten Datei stand C2 80. Das passte genau zu dem, was im PDF zu sehen war: „€“ bei mir, Murks bei meinem Kollegen. Da Java Strings in den .class-Dateien als UTF-8 speichert, müssen also schon die .java-Dateien falsch gewesen sein – oder? Bei uns beiden waren die Sourcen in den Projekteigenschaften in Eclipse als CP1252 gekennzeit, und der Hexeditor bestätigte das, das „€“ war als 80h codiert. Offenbar hat der Compiler das bei mir auch richtig erkannt, während er bei meinem Kollegen von einem anderen Encoding der Sourcen ausging. Aber wo war der Unterschied?

Wir stellten schließlich fest, dass ich zum Erstellen der Frameworks immer so vorging, dass ich mit Rechts auf das Projekt klickte und dann „WOLips Ant Tools/Install“ auswählte, während mein Kollege auf der build.xml „Run As/Ant Build“ aufrief bzw. das „External Tools“-Menü verwendete. Nur bei meinem Kollegen wurde dabei eine Konfiguration für Ant erstellt. Bisher waren wir davon ausgegangen, dass die Vorgehensweise keinen Unterschied macht, aber so einfach war es offenbar nicht.

Wir konnten das Problem schließlich auf folgendes zurückführen: In der build.xml im target[@name=“compile] gibt es ein wocompile-Tag mit einem Attribut „encoding“. Das hatte als Wert „ISO-8859-15“, war also nicht richtig. Aber warum war das noch nicht aufgefallen? Wenn ich über „WOLips Ant Tools/Install“ die Frameworks erstellte, wurde wirkte sich dieses Attribut nicht aus, egal, was dort stand. Bei meinem Kollegen wurde es jedoch bei „Ant Build“ berücksichtigt. Sobald ich einmal ebenfalls auf diesem Weg das Framework gebaut hatte, und somit eine Ant-Konfiguration erstellt hatte, wurde das Attribut auch bei „Install“ berücksichtigt. Das ließ nur den Schluss zu, dass ein „WOLips Ant Tools/Install“ eine Default-Konfiguration verwendet, solange es keine Ant-Konfiguration gibt. Ist diese vorhanden, arbeitet es genau wie „Run As/Ant Build“. Darauf muss man erstmal kommen.

Wir haben target[@name=“compile“]/wocompile/@encoding also auf „Cp1252“ geändert und festgelegt, dass wir nur noch über „Ant Build“ gehen. Somit sollten wir in Zukunft also mehr auf unerwartete Encoding-Probleme stoßen, die durch falsche Interpretation der Sourcen entstanden sind. Und ehe es in den Kommentaren kommt: Natürlich hätten wir das „€“ im Code auch einfach durch „\u20ac“ austauschen können, aber das hätte das zugrundeliegende Problem nicht beseitigt und besser lesbar wird der Code dadurch auch nicht.

Die korrigierten Versionen von EGIS und EGISPrintServer werden dann voraussichtlich in der Nacht von Sonntag auf Montag ausgerollt.

Schreiben Sie einen Kommentar

Ihre E-Mail Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert