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.
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.
I copied the wrong string, the actual one is "é" (U+00C3, U+00A9).
.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.
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/4329