When I use version 2.4.2, package it into a jar, and run it with cmd: java -jar demo-0.0.1-SNAPSHOT.jar, the log output is garbled. But after falling back to 2.4.1, using the same method again, it is completely normal. The attachment is the result comparison:

use-2 4 1 use-2 4 2

Comment From: philwebb

I wonder if the change we made for #24835 has had some kind of unexpected side-effect.

@jonesun I assume the last three lines are the issue? Perhaps logging.charset.console is has changed somehow. What's your default charset? Are you able to provide a sample application that shows the problem?

Comment From: jonesun

this is my demo project demo

Comment From: jonesun

thank you for your reply. my windows default charset is gbk, and my idea use utf-8

Comment From: jonesun

@philwebb I just followed your prompt and changed the application.yml, it's ok:

logging:
  charset:
    console: gbk

thank you very much!

Comment From: philwebb

Reopening because I'd like to dig into why the property wasn't needed before.

Comment From: jonesun

@philwebb ok

Comment From: wilkinsona

Thanks for the sample, @jonesun. It's allowed to confirm that the fix for #24835 is the problem.

DefaultLogbackConfiguration and LoggingSystemProperties have different defaults for CONSOLE_LOG_CHARSET. The former using default (the JVM's default) and the latter used UTF-8. In 2.4.1, LoggingSystemProperties does affect the logger context. As a result, CONSOLE_LOG_CHARSET is unset and its default (the JVM's default charset) is used by the console appender. In 2.4.2, LoggingSystemProperties does affect the logger context and, as a result, CONSOLE_LOG_CHARSET is set with LoggingSystemProperties' default which is UTF-8. This is then used by the console appender.

The fix for #24835 was intended to reinstate the lines removed in https://github.com/spring-projects/spring-boot/commit/fb25104151f0e9716f8e589bde144538c9df977d. The lines didn't set CONSOLE_LOG_CHARSET so perhaps we've swung back too far in the opposite direction and we should be more selective about the properties that are applied to the logger context. On the other hand, applying only a subset of properties seems inconsistent.

Comment From: philwebb

This line should use the LogbackLoggingSystemProperties subclass.