xml-xalan-j-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bjoern Martin <mabj0...@fh-karlsruhe.de>
Subject Re: Reader buggy for transformation? (Was: Re: Force encoding of result doc)
Date Fri, 13 Jul 2001 07:10:35 GMT
> Thanks, Bjoern.  I looked at Cmdline.java and this was the first
> thing that jumped out at me.  I'm sure I'll be able to reproduce
> it on my machine.  If this is a bug, I think it is mostly a bug
> with the documentation but probably Scott and Joe should comment
> on this since I haven't really thought it through.

Are they reading on this list? Or are we alone here? :)

> It seems to me when you ask for a Writer output, you're asking
> for a specific encoding.  The one argument constructor for
> FileWriter assumes an encoding of the java system property
> file.encoding and that's what you used.  This overrides the
> encoding requested in the XSLT.

I just added the line

 System.setProperty("file.encoding", "UTF-8");

in the beginning of the sample app, but nothing changed, as the line


added after the file's written still returns "cp1252" :(

> I do think this merits a FAQ entry but I wouldn't change XalanJ.
> What do you think?

That would be sufficient, as this only occurs if you change the
encoding. Just to check I used an UTF-8 input and UTF-8 style,
creating UTF-8 output - worked fine with the streams and FileWriter,
though I still get encoding "cp1252" for the FileWriter. Now, if I
change the output encoding to "iso-8859-1" in <xsl:output />, the
streams do the job and output the utf-8 'ä' as iso-8859-1 'ä', but
the FileWriter doesn't!
So if the FAQ entry would state that changing the encoding is only
safe with streams set for the StreamResult, everything's fine.


Bjoern Martin                                bjoern.martin@gmx.net

View raw message