The spring boot mustache view resolver accepts a charset parameter (via MustacheProperties), but that parameter is only used by the template loader, it is not used as part of the response content type. The default returned content type is text/html (with no charset), since that's the content type set on the ViewResolver in MustacheServletWebConfiguration.
In spring boot 2, this fell back on jetty's default implied charset list, via jetty's MimeTypes.getCharsetInferredFromContentType. By default, jetty returns utf-8 for text/html, which effectively made the response headers contain Content-Type: text/html;charset=utf-8. All was happy.
However, in spring boot 3, this added line totally wipes out jetty's inferred charset list. This causes jetty to fall back to it's hard-coded last resort charset, ISO-8859-1 (see jetty's ServletContextResponse ).
This means that in spring boot 3, all mustache templates are rendered using utf8, but return an iso-8859-1 content type header, which is incorrect and breaks all non-latin characters.
Comment From: mmorrisontx
This bug can be temporary fixed by setting spring.mustache.servlet.content-type: text/html; charset=utf-8
Comment From: mmorrisontx
It seems that this issue doesn't exist in other template systems like freemarker because FreeMarkerProperties extends from AbstractTemplateViewResolverProperties / AbstractViewResolverProperties, which handle this case properly by including their charset in the response from getContentType(). The 'proper' fix might be to refactor MustacheProperties to extend from AbstractTemplateViewResolverProperties as well.