Is your feature request related to a problem? Please describe.
In some environments it is required to configure the charset the resources are stored at and served from the config server, so that the user does not have to apply a different one via -Dfile.encoding=utf-8 at config server client side. This should also be considered by reading the username / password for the authentication token.

Describe the solution you'd like
My suggestion would be that the client uses its default charset which is provided and configured via the properties with a field called charset value UTF-8 in here:

https://github.com/spring-cloud/spring-cloud-config/blob/main/spring-cloud-config-client/src/main/java/org/springframework/cloud/config/client/ConfigClientProperties.java

This property should be given to the config server via request header which could be done similar to addAuthorizationToken, but in a method called addAcceptedCharset with headers.setAcceptCharset(Arrays.asList(Charset.forName(properties.getCharset()))); for example.

On server side the accepted charset could be read here:

https://github.com/spring-cloud/spring-cloud-config/blob/main/spring-cloud-config-server/src/main/java/org/springframework/cloud/config/server/resource/ResourceController.java#L141

and the resource could be served with that charset.

Also the username / password of the authentication properties should use a charset the config server client is working with (like Base64Utils.encode((username + ":" + password).getBytes(properties.getAuthHeaderCharset())):

https://github.com/spring-cloud/spring-cloud-config/blob/main/spring-cloud-config-client/src/main/java/org/springframework/cloud/config/client/ConfigClientRequestTemplateFactory.java#L116

Edit: After reading the RFC of the basic authentication https://www.rfc-editor.org/rfc/rfc7617#section-2 the encoded authentication header should be at least compatible with US-ASCII, so my suggestion would be to decouple this charset. (Use a different property to read the bytes)

For backwards compatibility reasons, this specification continues to leave the default encoding undefined, as long as it is compatible with US-ASCII (mapping any US-ASCII character to a single octet matching the US-ASCII character code).

Describe alternatives you've considered
A current workaround is to use -Dfile.encoding=utf-8 which is breaking some implementations on client side.

Additional context
This happens only on systems where UTF-8 is not the default charset for the JVM on client side.