-
Notifications
You must be signed in to change notification settings - Fork 38.3k
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
Jackson message converters and codecs do not respect character encoding in canRead/canWrite #25076
Comments
The underlying issues seems to be that As you eluded to Jackson does not support non-unicode encodings and we cannot change that, but we can fix the issue above. This way, you can use a different XML converter (such as the |
Regarding Jacksons support of non-unicode, please also see FasterXML/jackson-dataformat-xml#315. |
Thank you, I will keep an eye on that. For now, my recommendation would be to use a different XML message converter for non-unicode charsets, such as the aforementioned Jaxb2RootElementHttpMessageConverter, which does support other encodings. To do so, you would have to override When the fix for this has been released, it will no longer be necessary to override |
This issue also occurs in the Jackson codecs (i.e. |
Before this commit, AbstractJackson2HttpMessageConverter and subclasses did not check media type encoding in the canRead and canWrite methods. As a result, the converter reported that it can write (for instance) "application/json;charset=ISO-8859-1", but in practice wrote the default charset (UTF-8). This commit fixes that bug. See: gh-25076
Before this commit, Jackson2CodecSupport and subclasses did not check media type encoding in the supportsMimeType method (called from canEncode/canDecode). As a result, the encoder reported that it can write (for instance) "application/json;charset=ISO-8859-1", but in practice wrote the default charset (UTF-8). This commit fixes that bug. Closes: gh-25076
Before this commit, AbstractJackson2HttpMessageConverter and subclasses did not check media type encoding in the canRead and canWrite methods. As a result, the converter reported that it can write (for instance) "application/json;charset=ISO-8859-1", but in practice wrote the default charset (UTF-8). This commit fixes that bug. See: gh-25076
Before this commit, Jackson2CodecSupport and subclasses did not check media type encoding in the supportsMimeType method (called from canEncode/canDecode). As a result, the encoder reported that it can write (for instance) "application/json;charset=ISO-8859-1", but in practice wrote the default charset (UTF-8). This commit fixes that bug. Closes: gh-25076
Before this commit, AbstractJackson2HttpMessageConverter and subclasses did not check media type encoding in the canRead and canWrite methods. As a result, the converter reported that it can write (for instance) "application/json;charset=ISO-8859-1", but in practice wrote the default charset (UTF-8). This commit fixes that bug. See: gh-25076
Fixed. Once Jackson's |
Before this commit, AbstractJackson2HttpMessageConverter and subclasses did not check media type encoding in the canRead and canWrite methods. As a result, the converter reported that it can write (for instance) "application/json;charset=ISO-8859-1", but in practice wrote the default charset (UTF-8). This commit fixes that bug. See: spring-projectsgh-25076
Before this commit, Jackson2CodecSupport and subclasses did not check media type encoding in the supportsMimeType method (called from canEncode/canDecode). As a result, the encoder reported that it can write (for instance) "application/json;charset=ISO-8859-1", but in practice wrote the default charset (UTF-8). This commit fixes that bug. Closes: spring-projectsgh-25076
Is there a way to go back to the behavior before 5.2.7 ? I have a client that send ;charset=ISO-8859-1 but I want to read/write in UTF-8. Somehow force to ignore the charset. |
The only way I can think of is to write a MVC interceptor or HTTP servlet filter to change the request character set for the URL and HTTP method the client uses. |
I am not sure how to modify a header of HttpServletRequest using the MVC interceptor or a Filter without wrapping the request. It's possible? The private method readJavaType reads the charset from the Http request Content-Type. |
Before this commit, AbstractJackson2HttpMessageConverter and subclasses did not check media type encoding in the canRead and canWrite methods. As a result, the converter reported that it can write (for instance) "application/json;charset=ISO-8859-1", but in practice wrote the default charset (UTF-8). This commit fixes that bug. See: spring-projectsgh-25076
Before this commit, Jackson2CodecSupport and subclasses did not check media type encoding in the supportsMimeType method (called from canEncode/canDecode). As a result, the encoder reported that it can write (for instance) "application/json;charset=ISO-8859-1", but in practice wrote the default charset (UTF-8). This commit fixes that bug. Closes: spring-projectsgh-25076
Before this commit, AbstractJackson2HttpMessageConverter and subclasses did not check media type encoding in the canRead and canWrite methods. As a result, the converter reported that it can write (for instance) "application/json;charset=ISO-8859-1", but in practice wrote the default charset (UTF-8). This commit fixes that bug. See: spring-projectsgh-25076
Before this commit, Jackson2CodecSupport and subclasses did not check media type encoding in the supportsMimeType method (called from canEncode/canDecode). As a result, the encoder reported that it can write (for instance) "application/json;charset=ISO-8859-1", but in practice wrote the default charset (UTF-8). This commit fixes that bug. Closes: spring-projectsgh-25076
Affects: org.springframework:spring-web:5.1.15.RELEASE
XML webservices seem to be limited to unicode encodings. Using jackson-dataformat-xml 2.9.8 for a webservice which produces "text/xml;charset=ISO-8859-1" outputs utf-8.
The problem might be located in AbstractJackson2HttpMessageConverter:
JsonEncoding only provides unicode. A workaround would be to override the whole method but it is quite lenghty.
I made a very small reproducer: https://github.com/saimonsez/spring-jackson-xml-encoding-problem
The text was updated successfully, but these errors were encountered: