[
https://issues.apache.org/jira/browse/LOG4J2-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Matz updated LOG4J2-3372:
--------------------------------
Description:
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
was:
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 caused 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."
> 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)
