Skip to content

Spring default characterEncoding #26171

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
vojkny opened this issue Nov 27, 2020 · 6 comments
Closed

Spring default characterEncoding #26171

vojkny opened this issue Nov 27, 2020 · 6 comments
Labels
in: test Issues in the test module in: web Issues in web modules (web, webmvc, webflux, websocket)

Comments

@vojkny
Copy link

vojkny commented Nov 27, 2020

Since Spring 5.2 MediaType.APPLICATION_JSON_UTF8 is @deprecated as described within MediaType class:

/**
 * A String equivalent of \{@link MediaType#APPLICATION_JSON_UTF8}.
 * @deprecated as of 5.2 in favor of \{@link #APPLICATION_JSON_VALUE}
 * since major browsers like Chrome
 * <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=438464">
 * now comply with the specification</a> and interpret correctly UTF-8 special
 * characters without requiring a \{@code charset=UTF-8} parameter.
 */
@Deprecated
public static final String APPLICATION_JSON_UTF8_VALUE = "application/json;charset=UTF-8";

So basically everyone should be using MediaType.APPLICATION_JSON_VALUE without (UTF8 information) instead. This is unfortunately in conflict with MockHttpServletResponse:

private String characterEncoding = "ISO-8859-1";

So even thought UTF8 is expected by default, the testing environment is in violation with aboves:

now comply with the specification</a> and interpret correctly UTF-8 special

The tests which explicitly don't override this encoding will fail.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Nov 27, 2020
@rstoyanchev
Copy link
Contributor

The characterEncoding in MockHttpServletResponse simply reflects the Serlvet spec default. It shouldn't interfere with MappingJackson2HttpMessageConverter which writes UTF-8 directly to the OutputStream. Can you clarify how tests fail?

@rstoyanchev rstoyanchev added status: waiting-for-feedback We need additional information before we can continue in: test Issues in the test module in: web Issues in web modules (web, webmvc, webflux, websocket) labels Nov 30, 2020
@vojkny
Copy link
Author

vojkny commented Nov 30, 2020

The characterEncoding in MockHttpServletResponse simply reflects the Serlvet spec default. It shouldn't interfere with MappingJackson2HttpMessageConverter which writes UTF-8 directly to the OutputStream. Can you clarify how tests fail?

When the response from a JSON endpoint contains UTF-8 characters (ěščřžýá), then the MockHttpServletResponse will consider them as ISO-8859-1 and the these characters will be received broken. If the tests perform assertEquals on such strings, they will fail.

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Nov 30, 2020
@rstoyanchev
Copy link
Contributor

So you're probably doing this?

assertEquals("...", response.getContentAsString());

but should be:

assertEquals("...", response.getContentAsString(StandardCharsets.UTF_8));

@vojkny
Copy link
Author

vojkny commented Nov 30, 2020

The problem is that until having original aplication/json; charset=UTF-8 this worked correctly.

again:

now comply with the specification</a> and interpret correctly UTF-8 special

it is just strange to migrate to version without charset=UTF-8 when all tests are now broken.

@rstoyanchev
Copy link
Contributor

Right but the change reflects the fact that it is now up to clients to be compliant and interpret this correctly. In MockMvc we automatically interpret JSON as UTF-8 but in this case you're reading directly from the response and it is up to your tests to do that. It is too low level a place for us to start adding functionality like that.

@rstoyanchev rstoyanchev added status: waiting-for-feedback We need additional information before we can continue and removed status: feedback-provided Feedback has been provided labels Nov 30, 2020
@vojkny
Copy link
Author

vojkny commented Nov 30, 2020

Ok, thanks.

@vojkny vojkny closed this as completed Nov 30, 2020
@rstoyanchev rstoyanchev removed status: waiting-for-feedback We need additional information before we can continue status: waiting-for-triage An issue we've not yet triaged or decided on labels Nov 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: test Issues in the test module in: web Issues in web modules (web, webmvc, webflux, websocket)
Projects
None yet
Development

No branches or pull requests

3 participants