Since: Spring 5.2 and the deprecation of APPLICATION_JSON_UTF8 Mediatype.
Although the content type 'application/json' can only be encoded in UTF-8 (which is why the explicit encoding was deprecated), MockHttpServletResponse#getCharacterEncoding() returns 'ISO-8859-1'.
This breaks any test code that inspects or uses the getCharacterEncoding() directly. But more unexpectedly, it breaks MockHttpServletResponse#getContentAsString(), because the response is decoded with ISO-8859-1 instead of UTF-8. Explicitly using MockHttpServletResponse#getContentAsString(Charset fallbackCharset) works correctly.
The Javadoc for getContentAsString() is (to me) somewhat ambiguous:
Get the content of the response body as a String, using the charset specified for the response by the application, either through HttpServletResponse methods or through a charset parameter on the Content-Type.
"using the charset specified for the response by the application" could imply UTF-8 for 'application/json', because that must always be the value for JSON. If using this interpretation, then the method breaks its Javadoc contract.
Previously, this was fixed for ContentResultMatchers#json(String) but not for MockHttpServletResponse#getContentAsString() (#23622).
Another report was closed by the submitter without any resolution except using an explicit charset (#23851).
If it is not possible to fix this for JSON specifically, I would appreciate if somehow a default value could be set (instead of always defaulting to ISO-8859-1).
Since: Spring 5.2 and the deprecation of
APPLICATION_JSON_UTF8Mediatype.Although the content type 'application/json' can only be encoded in UTF-8 (which is why the explicit encoding was deprecated),
MockHttpServletResponse#getCharacterEncoding()returns 'ISO-8859-1'.This breaks any test code that inspects or uses the
getCharacterEncoding()directly. But more unexpectedly, it breaksMockHttpServletResponse#getContentAsString(), because the response is decoded with ISO-8859-1 instead of UTF-8. Explicitly usingMockHttpServletResponse#getContentAsString(Charset fallbackCharset)works correctly.The Javadoc for
getContentAsString()is (to me) somewhat ambiguous:"using the charset specified for the response by the application" could imply UTF-8 for 'application/json', because that must always be the value for JSON. If using this interpretation, then the method breaks its Javadoc contract.
Previously, this was fixed for
ContentResultMatchers#json(String)but not forMockHttpServletResponse#getContentAsString()(#23622).Another report was closed by the submitter without any resolution except using an explicit charset (#23851).
If it is not possible to fix this for JSON specifically, I would appreciate if somehow a default value could be set (instead of always defaulting to ISO-8859-1).