Wer Velocity auf 'nem Tomcat laufen hat, stolpert vielleicht mal über das Problem, dass das Character Encoding falsch gesetzt ist. Sprich, dass Umlaute falsch gerendert werden.

Nun könnte man vermuten, dass das am String selbst liegt. Tut es nicht: In Java sind Strings UTF-16.

Dann könnte man den Fehler in Velocity suchen. Etwa könnte man die Templates explizit als UTF-8 öffnen:

Das hat bei mir nicht geholfen. Allerdings kann man Velocity das Default-, Input- und Output-Encoding vorgeben:

Das scheint schon mal was zu bewirken. Allerdings wird einem hier auffallen, dass die meisten (wenn nicht alle) Umlaute nicht im Template liegen, sondern dort nur reingeschrieben werden. In unserem Fall wurden zum Beispiel zum Teil Daten eines Webservice, zum Teil aber auch lokal gespeicherte XMLs verwendet. Die XMLs müssen UTF-8-kodiert gespeichert worden sein:

Und sie müssen vor allem auch UTF-8-kodiert gelesen werden:

Update

Kommen die XML-Daten (hier als ZIP) aus der Schnittstelle, müssen sie als UTF-8 in einen String konvertiert werden:

So. Last but not least müssen die Daten, die serverintern jetzt in UTF-8 vorliegen sollten, auch als solches an den Browser ausgegeben werden. Während normalerweise der Writer des Response ausreicht, um den OutputStream dieses Response zu handlen:

, muss man diesen für UTF-8 manchmal mit einem Writer mit explizit gesetztem UTF-8 ersetzen (Danke an Ralf!):

Achtung: Für JSON-Response musste ich dagegen das Encoding des Response selbst setzen:

Vermutlich ist das ein wenig kompliziert gemacht (ich meine, hey, das muss einfacher gehen!), aber so scheint es hier zu funktionieren. HTH

Update

Für Spring gilt es außerdem, dieses Setting zu beachten: