To deal with this issue at a larger scale, you may define a variable on the fly, say OS_CHARSET, and pass OS_CHARSET as the charset to PatternLayoutEncoder.
I'm still not sure I'm communicating the issue here. You mention setting an OS_CHARSET value, but the whole point is that the console/terminal charset may have no relationship at all with the charset of the operating system. Secondly how would the user even know what charset the console is using? Even I only found out programmatically, I think with System.console().charset(). Maybe if I researched I could find out some setting for the Command Prompt. But what if the user has multiple command lines, such as PowerShell? And with Microsoft Terminal, I can have multiple tabs of different types of command lines. So there may not even be one single "console charset" in use on the system. Besides, requiring the user to set some environment variable with the charset their terminal is using is an installation management nightmare, even for the most experts of users. Again I think the only realistic solution is for ConsoleAppender to delegate to the PrintStream for System.out/System.err by default unless a charset is explicitly set. |