Samstag, 31. Juli 2010

Ant Filter-Copy-Task und Zeichenkodierung

Ein Eintrag aus der Rubrik "kleiner Fehler, große Wirkung": Resource-Properties-Dateien wurden für eine Web-Anwendung mit einem Ant-Skript aus den Projektordnern in die passenden Ordner der Web-Applikation umkopiert. Bei manchen Properties-Dateien wurden die darin enthaltenen Umlaute im Browser manchmal (je nach Applikations-Server und je nach Rechner, auf dem die Web-Anwendung gebaut wurde) falsch dargestellt.

Ursache des Problems war ein copy-Task, der die Datei nicht 1:1 umkopiert, sondern mit einem filterset bestimmte Token ersetzt hat. Je nach Systemeinstellung kamen dann in der Web-Anwendung Umlaute (bzw. allgemein Sonderzeichen) an, die im Browser korrekt angezeigt werden konnten – oder eben nicht.

Die Lösung des Problems ist, bei Filter-Copy-Tasks die Kodierung explizit anzugeben, damit nicht die System-Default-Kodierung verwendet wird (die Doku erwähnt dies am Ende des Dokuments). Bei Properties-Dateien ist ISO-Latin-1 (ISO-8859-1) meist eine erste, gute Wahl (sofern die gesamte Web-Anwendung nicht auf UTF ausgelegt ist):
<copy
todir="${webapp}/WEB-INF/classes"
file="${src}/MyResources.properties"
encoding="ISO-8859-1"
overwrite="true">

<filterset>
<filter token="COMPILETIME" value="${DSTAMP}-${TSTAMP}"/>
</filterset>

</copy>
Entstanden ist der Bug wohl durch Copy&Paste, wobei aus einem fileset – ohne Filterung und damit ohne die Notwendigkeit, eine Zeichenkodierung anzugeben – ein filterset wurde.

Kommentare:

  1. Hmm. Generell ist es keine gute Idee für irgendeinen Schritt der Entwicklung etwas anderes als UTF-8 zu nutzen. Nur mit Unicode hat man keine Konvertierungsprobleme - egal was passiert. Und in größeren Anwendungen solche Textfilter zu finden und komplett auszumerzen ist nachträglich oft sehr schwer.
    Also, IDE auf UTF-8 umstellen und alles wird gut. Ist ohnehin nur für Windows benutzer interessant. Alle anderen Systeme laufen per default auf UTF-8.

    AntwortenLöschen
  2. Wenn alles mit UTF-8 kodiert ist, ist das besser, keine Frage!

    Im konkreten Fall waren die Java-Quelltexte (und die IDE) sogar auf UTF-8 eingestellt, nur der Webserver und vor allem die zu unterstützenden (alten) Browser haben mit UTF-8 mehr Probleme bereitet als mit ISO-Latin-1. Daher wurde für die Web-Schicht (HTML) ISO-Latin-1 gewählt, was sich dann auch auf die Resource-Properties ausgewirkt hat.

    Es ging mir mehr um einen einfachen Bugfix als um Best-Practices für neue Projekte.

    AntwortenLöschen