Michael Glavassevich wrote:
This is neither a Xerces bug or a bug in Java.
Investigating this further, this is definitely a bug in Java which is then not trapped by Xerces - the FileWriter opens the file with an unpredictable encoding different per platform, which is definitely broken behaviour. Xerces then silently allows this problem to remain unchecked through encoding, when in reality it should have thrown an exception.
When you pass the serializer a Writer rather than an OutputStream it will write characters not bytes. If the Writer is writing to an OutputStream, it is responsible for encoding the characters and will do whatever it does regardless of what encoding you specified on the serializer.
Which in turn produces broken XML - What Xerces should be doing is testing the encoding of the underlying Writer, and if different from the encoding specified for serialisation, it should throw an exception and fail safely, rather than quietly continuing rendering broken output.
http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStreamWriter.html#getEncoding()
Thank you for pointing me in the right direction for solving this - it had us stumped for ages.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
