Clients with incompatible default encoding may corrupt output from log file endpoint as it does not specify the charset that it produces

[zl7261]

I download a plugin for chrome before.
And the default encoding for chrome doesn't support very well.
And convert to utf-8 by plugin,the Chinese display right.

I assume it's a browser problem. But I found Firefox it's the same.

By browser default encoding without

···
meta charset="UTF-8"
···

"enterpriseName":"企业名称" is be corrupted as "enterpriseName":"浜胯仈缃戠粶" which is unreadable.

[wilkinsona]

Thanks for the report. Unfortunately, the problem that you are describing isn't clear to me. Can you please describe it in some more detail or, ideally, provide a minimal sample that reproduces the problem?

[zl7261]

my project use mybatis and slf4j.
when the slf4j print the log on the ide's console ,the Chinese condition param is showing well.

2019-03-12 00:10:00.012  INFO 32363 --- [scheduling-1] c.y.sz.ytms.task.EnterprisePollTask      : Param:{"enterpriseName":"企业名称","country":"china"} 

the "enterpriseName" is readable.

but when I open /logfile endpoint.the log which is showing on browser which dont contains

meta charset="UTF-8"

is

2019-03-12 00:10:00.012 INFO 32363 --- [scheduling-1] c.y.sz.ytms.task.EnterprisePollTask : Param:{"enterpriseName":"浜胯仈缃戠粶","country":"china"}

which the chinese param "enterpriseName" has be corrupted.

By with the charset plugin,I convert /logfile page charset from default encoding to utf8.
the Chinese param is readable.

As for sample,just a very simple mybatis-springboot project which used actuator and open /logfile endpoint.

[zl7261]

btw,It's a scheduler log which use apache httpclient to poll some information for each 5 minutes.
I set the http content-type to 'application/json,charset=utf8'.
the task works well.
just the chinese param of /logfile endpoint doesn't work.

[wilkinsona]

Thanks for the additional information. I've reproduced the behaviour you have described. It's really a client-side presentation problem. The contents of the log file are served correctly but are then corrupted by the browser as it makes an incorrect assumption about the encoding of the file. With Safari's default encoding set to ISO Latin 1, corruption occurs. With its default encoding changed to UTF-8 the text is displayed correctly.

With that said, and given that we default to UTF-8 in numerous other places, I wonder if we should build upon #16188 and set produces to text/plain; charset=UTF-8 rather than just text/plain.