Note: calling the static native method `String Console.encoding()` returns the current console encoding, even if `System.console()` is null because the console is not interactive (pipe or redirection).
- due to some rewriting without testing, the encoding property was not added to the renderer properties.
- better console encoding: use system property `sun.stdout.encoding` in interactive console, and `file.encoding` in piped or redirected output
Hi,
The writers in the Ant task's formatter uses the default platform's encoding (for instance cp1252 on Western Windows) and the XMLRenderer sets the default XML encoding to UTF-8. This may lead to incorrect XML encoding, detected for instance when the XML file is sent to a XSLT task.
This goes undetected as long as the characters in the XML file are in the ASCII subset, which is frequently the case with code, usually in plain Latin language. In my case, the issue was raised because of the localized formatting of some line numbers greater than 999, due to localized thousand separator 0xA0, which is out of the ASCII subset.
I modified the Formatter class to always use a charset for writers. When no encoding is specified, UTF-8 is used instead of the default platform's encoding.
I strongly recommend to *always set the encoding parameter* of the formatter element. It should be reflected as so in the Ant Task documentation.
```xml
<pmd encoding="cp1252"> <!-- source encoding -->
<formatter type="xml" toFile="pmd.xml">
<param name="encoding" value="UTF-8" /> <!-- report encoding -->
</formatter>
<fileset dir="src/main/java">
<include name="**/*.java"/>
</fileset>
</pmd>
```
Note: when digging into sourceforge issues for similar bugs, I found [Bug 877: Output with encoding CP1252](https://sourceforge.net/p/pmd/bugs/877/) . Not the same task, but the same symptoms, probably the same cause ?
