|Summary:||Use of default encoding: FileReader/Writer and InputStreamReader/OutputStreamWriter|
|Component:||Main||Assignee:||JMeter issues mailing list <issues>|
|OS:||Mac OS X 10.1|
Description Sebb 2017-03-13 18:22:43 UTC
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.
Comment 1 Greg 2018-05-31 12:00:07 UTC
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.
Comment 2 Greg 2018-05-31 12:13:02 UTC
I copied the wrong string, the actual one is "Ã©" (U+00C3, U+00A9).
Comment 3 Felix Schumacher 2018-05-31 14:47:23 UTC
.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.