The current implementation is ignoring the actual stream's charset, but uses
the local host's default charset (e. g. on Windows in Western Europe this is
Cp1252) instead. This can lead to very nasty problems in case the output stream
is containing special characters like Umlauts etc., as the XSL transformer in
use on the end customer's platform (like SAXON instead of XALAN etc.) will
presumably rely on correctly encoded characters.
The core problem is that the byte stream gets lated into UTF-8 characters using
an unspecified code page, leaving it open to the end user's platform to decide
per request which code page to use. Unfortunately it does not decide on the
actual content's XML encoding declaration, but instead uses the platform's
A correct solution would be to inspect the actual content's XML encoding
declaration, or not to translate into UTF-8 characters at all (it is anyways
doubtful whether this translation is needed at all).