Use of default encoding: FileReader/Writer and InputStreamReader/OutputStreamWriter

[asfimport]

Sebb (Bug 60855): FileReader and FileWriter use the default encoding, so are not really suitable for use with anything other than temporary files.

Likewise InputStreamReader & OutputStreamWriter allow the encoding to be omitted.

Files that may potentially be copied between hosts should have a defined encoding, for example UTF-8 should be a suitable default.

However, that might break some existing installations - e.g. if the ResultCollector is changed to always use UTF-8 it may be unable to read some existing result files.

It may not be possible to fix all the existing usage; in the meantime it might help to document where the code assumes the default encoding.

Severity: normal OS: Mac OS X 10.1

[asfimport]

Greg (migrated from Bugzilla): This bug makes properties files unusable for storing data in Central and Easter European countries.

For example, a property containing an "é" (U+00E9) in the user.properties file becomes "Ă©" (U+0102, U+00A9) during runtime. I suspect it's also because the file is read from an InputStreamReader, instead of a Reader with UTF-8 encoding.

The main problem is that, on the other hand, when reading properties from the .jmx file, it's perfectly read in UTF-8. So I cannot convert ALL of my properties from UTF-8-read-as-Latin-1 to real UTF-8, because I don't know where has a property come from. That means I'm stuck with either using a .properties file or the .jmx.

[asfimport]

Greg (migrated from Bugzilla): I copied the wrong string, the actual one is "é" (U+00C3, U+00A9).

[asfimport]

@FSchumacher (migrated from Bugzilla): .properties files should be guarded with the tool native2ascii from the jre. That should fix your encoding problems.

It would still be a good idea to document the used encodings for the in- and output paths.