Github user michalklempa commented on the issue: https://github.com/apache/nifi/pull/675 @trixpan regarding any "defaultCharset" issues, I guess, that author was thinking about what Java process sees as the default charset of the system it runs on. I have seen it couple of times, that Java developers tend to set the charset (see http://stackoverflow.com/a/31644153). It is mainly because Java writers let those methods like String.getBytes() to behave not statically -> said in documentation it will return always UTF-8 transformation to bytes, but these argless functions behave 'system-dependent' way - Java tries to figure out the Locale on the system it is running... you know. It causes o lot of headaches, mainly for Java newbies. But if NiFi is coded properly, and every such function call is used only in argument-aware version, default charset is not even used inside JVM at runtime, nobody simply ask for it by calling Charset.defaultCharset or String.getBytes or other Java gotchas String>byte manipulation function.
--- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---