[ https://issues.apache.org/jira/browse/LOG4J2-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17484361#comment-17484361 ]
Piotr P. Karwasz edited comment on LOG4J2-3372 at 1/30/22, 2:34 PM: -------------------------------------------------------------------- LOG4J2-1636 supposedly fixed it again, but is is still reproducible on my system. What actually happens is: # The `PatternLayout` is created using the default system charset (`Cp1250`), # The builder of the `ConsoleAppender` correctly computes `cp850` as the appropriate charset, but it can not modify the layout. was (Author: JIRAUSER280472): LOG4J2-1636 supposedly fixed it again, but is is still reproducible on my system. > ConsoleAppender on Windows does not use platform default encoding > ----------------------------------------------------------------- > > Key: LOG4J2-3372 > URL: https://issues.apache.org/jira/browse/LOG4J2-3372 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders > Affects Versions: 2.17.1 > Reporter: Oliver Matz > Priority: Minor > Attachments: ConsoleEncodingExample.java, LOG4J2-3372-sceenshot.png, > log4j2.xml > > > The attached example outputs a short string containing non-ascii characters > ("Schöner Spaß") both to System.out and via log4j2 to a ConsoleAppender with > target SYSTEM_OUT. > When I run the example in my IDE, it outputs the string correctly both times, > as expected > However, if I run the example in a console on my Windows Desktop (10.0), only > the output to System.out is correct. The non-ascii-characters get broken in > the output of log4j2. > I know that a workaround is to add {{charset="IBM850"}} in the > {{{}PatternLayout{}}}, but this clearly causes problems if the application > runs in a different environment. > I definitely expect that log4j uses the platform default encoding, just as > System.out does, and this seems to be other peoples' expectation, too. See > e.g. LOG4J2-2929, stating incorrectly that "Currently PatternLayout always > uses the default charset if none is specified explicitly." > Another workaround is, of course, to specify a certain encoding (e.g. UTF-8) > both for System.out and for the PatternLayout and to require the user to set > the windows codepage (using e.g. CHCP 65001). I dislike that approach because > it defeats the purpose of the "platform default encoding" and places a burden > on the user -- This message was sent by Atlassian Jira (v8.20.1#820001)