Mixing
Wrong encoding using POST method from jsp to jsp on a Tomcat server
I'm currently learning JEE and within an exercise I just need to send text data from a .jsp file to another, using a basic form with a POST method. In this form, I want to be able to use accented characters, so I use <%@page pageEncoding="UTF-8" %> on top of my jsp files, they also have both the <meta charset="utf-8"> tags and my IDE (Eclipse) is configurated to encode everything in UTF-8.
The problem is that at the end of the line, when I try to display my characters using EL, the accented characters (and the other ones I guess) are encoded in ISO-8859-1.
Which is really peculiar here is that when sending data using a GET method, I don't have any problem at all. Same result when I pass a String in the request via an attribute set in a servlet.
In fact I already solved the problem by sending the request to a servlet and calling request.setCharacterEncoding("utf-8") in a doPost method (let's precise that calling request.getCharacterEncoding() before that gives me null), but I'd like to understand what exactly is happening here. I guess it comes from a server misconfiguration, but when I check the web.xml file of my server config I have these lines :
<filter>
<filter-name>setCharacterEncodingFilter</filter-name>
<filter-class>org.apache.catalina.filters.SetCharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<async-supported>true</async-supported>
</filter>
My confusion comes from the fact that nobody ever told me to use the request.setCharacterEncoding("utf-8"), and that it does not appear normal to me that I would have to do so, so I guess the question would be : do I absolutely have to use it ? Why ? Shouldn't the encoding be handled by configuration of the server ?
I'm using Tomcat 9 for the server, and I'm under Ubuntu (don't know if it helps).
java tomcat post encoding
asked Nov 20 '18 at 15:28
OoalkmanOoalkman
83
add a comment |
I'm currently learning JEE and within an exercise I just need to send text data from a .jsp file to another, using a basic form with a POST method. In this form, I want to be able to use accented characters, so I use <%@page pageEncoding="UTF-8" %> on top of my jsp files, they also have both the <meta charset="utf-8"> tags and my IDE (Eclipse) is configurated to encode everything in UTF-8.
The problem is that at the end of the line, when I try to display my characters using EL, the accented characters (and the other ones I guess) are encoded in ISO-8859-1.
Which is really peculiar here is that when sending data using a GET method, I don't have any problem at all. Same result when I pass a String in the request via an attribute set in a servlet.
In fact I already solved the problem by sending the request to a servlet and calling request.setCharacterEncoding("utf-8") in a doPost method (let's precise that calling request.getCharacterEncoding() before that gives me null), but I'd like to understand what exactly is happening here. I guess it comes from a server misconfiguration, but when I check the web.xml file of my server config I have these lines :
<filter>
<filter-name>setCharacterEncodingFilter</filter-name>
<filter-class>org.apache.catalina.filters.SetCharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<async-supported>true</async-supported>
</filter>
My confusion comes from the fact that nobody ever told me to use the request.setCharacterEncoding("utf-8"), and that it does not appear normal to me that I would have to do so, so I guess the question would be : do I absolutely have to use it ? Why ? Shouldn't the encoding be handled by configuration of the server ?
I'm using Tomcat 9 for the server, and I'm under Ubuntu (don't know if it helps).
java tomcat post encoding
asked Nov 20 '18 at 15:28
OoalkmanOoalkman
83
Possible duplicate of UTF-8 encoding a servlet form submission with Tomcat
– Selaron
Nov 20 '18 at 15:39
It is indeed the same problem, but it does not really gives an answer to my question (which I have precised in editing my initial post). There are some general concepts that I actually don't understand and I would like to have a more complete answer. Maybe should I post on the thread you have linked ?
– Ooalkman
Nov 20 '18 at 15:56
No, if you still feel it's a different problem it's legit to enhance your question as detailed as possible and hope for an answer. Don't use comment function for chat or extended discussion on other questions.
– Selaron
Nov 20 '18 at 16:00
You are asking for the 'why'. Found a quite detailed explanation here: balusc.omnifaces.org/2009/05/…
– Selaron
Nov 20 '18 at 19:18
Thank you so much, that was exactly what I was looking for !
– Ooalkman
Nov 20 '18 at 21:21
add a comment |
I'm currently learning JEE and within an exercise I just need to send text data from a .jsp file to another, using a basic form with a POST method. In this form, I want to be able to use accented characters, so I use <%@page pageEncoding="UTF-8" %> on top of my jsp files, they also have both the <meta charset="utf-8"> tags and my IDE (Eclipse) is configurated to encode everything in UTF-8.
The problem is that at the end of the line, when I try to display my characters using EL, the accented characters (and the other ones I guess) are encoded in ISO-8859-1.
Which is really peculiar here is that when sending data using a GET method, I don't have any problem at all. Same result when I pass a String in the request via an attribute set in a servlet.
In fact I already solved the problem by sending the request to a servlet and calling request.setCharacterEncoding("utf-8") in a doPost method (let's precise that calling request.getCharacterEncoding() before that gives me null), but I'd like to understand what exactly is happening here. I guess it comes from a server misconfiguration, but when I check the web.xml file of my server config I have these lines :
<filter>
<filter-name>setCharacterEncodingFilter</filter-name>
<filter-class>org.apache.catalina.filters.SetCharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<async-supported>true</async-supported>
</filter>
My confusion comes from the fact that nobody ever told me to use the request.setCharacterEncoding("utf-8"), and that it does not appear normal to me that I would have to do so, so I guess the question would be : do I absolutely have to use it ? Why ? Shouldn't the encoding be handled by configuration of the server ?
I'm using Tomcat 9 for the server, and I'm under Ubuntu (don't know if it helps).
java tomcat post encoding
asked Nov 20 '18 at 15:28
OoalkmanOoalkman
83
I'm currently learning JEE and within an exercise I just need to send text data from a .jsp file to another, using a basic form with a POST method. In this form, I want to be able to use accented characters, so I use <%@page pageEncoding="UTF-8" %> on top of my jsp files, they also have both the <meta charset="utf-8"> tags and my IDE (Eclipse) is configurated to encode everything in UTF-8.
The problem is that at the end of the line, when I try to display my characters using EL, the accented characters (and the other ones I guess) are encoded in ISO-8859-1.
Which is really peculiar here is that when sending data using a GET method, I don't have any problem at all. Same result when I pass a String in the request via an attribute set in a servlet.
In fact I already solved the problem by sending the request to a servlet and calling request.setCharacterEncoding("utf-8") in a doPost method (let's precise that calling request.getCharacterEncoding() before that gives me null), but I'd like to understand what exactly is happening here. I guess it comes from a server misconfiguration, but when I check the web.xml file of my server config I have these lines :
<filter>
<filter-name>setCharacterEncodingFilter</filter-name>
<filter-class>org.apache.catalina.filters.SetCharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<async-supported>true</async-supported>
</filter>
My confusion comes from the fact that nobody ever told me to use the request.setCharacterEncoding("utf-8"), and that it does not appear normal to me that I would have to do so, so I guess the question would be : do I absolutely have to use it ? Why ? Shouldn't the encoding be handled by configuration of the server ?
I'm using Tomcat 9 for the server, and I'm under Ubuntu (don't know if it helps).
java tomcat post encoding
java tomcat post encoding
asked Nov 20 '18 at 15:28
OoalkmanOoalkman
83
asked Nov 20 '18 at 15:28
OoalkmanOoalkman
83
edited Nov 20 '18 at 15:48
Ooalkman
asked Nov 20 '18 at 15:28
OoalkmanOoalkman
83
asked Nov 20 '18 at 15:28
OoalkmanOoalkman
83
asked Nov 20 '18 at 15:28
OoalkmanOoalkman
83
83
Possible duplicate of UTF-8 encoding a servlet form submission with Tomcat
– Selaron
Nov 20 '18 at 15:39
It is indeed the same problem, but it does not really gives an answer to my question (which I have precised in editing my initial post). There are some general concepts that I actually don't understand and I would like to have a more complete answer. Maybe should I post on the thread you have linked ?
– Ooalkman
Nov 20 '18 at 15:56
No, if you still feel it's a different problem it's legit to enhance your question as detailed as possible and hope for an answer. Don't use comment function for chat or extended discussion on other questions.
– Selaron
Nov 20 '18 at 16:00
You are asking for the 'why'. Found a quite detailed explanation here: balusc.omnifaces.org/2009/05/…
– Selaron
Nov 20 '18 at 19:18
Thank you so much, that was exactly what I was looking for !
– Ooalkman
Nov 20 '18 at 21:21
add a comment |
Possible duplicate of UTF-8 encoding a servlet form submission with Tomcat
– Selaron
Nov 20 '18 at 15:39
It is indeed the same problem, but it does not really gives an answer to my question (which I have precised in editing my initial post). There are some general concepts that I actually don't understand and I would like to have a more complete answer. Maybe should I post on the thread you have linked ?
– Ooalkman
Nov 20 '18 at 15:56
No, if you still feel it's a different problem it's legit to enhance your question as detailed as possible and hope for an answer. Don't use comment function for chat or extended discussion on other questions.
– Selaron
Nov 20 '18 at 16:00
You are asking for the 'why'. Found a quite detailed explanation here: balusc.omnifaces.org/2009/05/…
– Selaron
Nov 20 '18 at 19:18
Thank you so much, that was exactly what I was looking for !
– Ooalkman
Nov 20 '18 at 21:21
Possible duplicate of UTF-8 encoding a servlet form submission with Tomcat
– Selaron
Nov 20 '18 at 15:39
Possible duplicate of UTF-8 encoding a servlet form submission with Tomcat
– Selaron
Nov 20 '18 at 15:39
It is indeed the same problem, but it does not really gives an answer to my question (which I have precised in editing my initial post). There are some general concepts that I actually don't understand and I would like to have a more complete answer. Maybe should I post on the thread you have linked ?
– Ooalkman
Nov 20 '18 at 15:56
It is indeed the same problem, but it does not really gives an answer to my question (which I have precised in editing my initial post). There are some general concepts that I actually don't understand and I would like to have a more complete answer. Maybe should I post on the thread you have linked ?
– Ooalkman
Nov 20 '18 at 15:56
No, if you still feel it's a different problem it's legit to enhance your question as detailed as possible and hope for an answer. Don't use comment function for chat or extended discussion on other questions.
– Selaron
Nov 20 '18 at 16:00
No, if you still feel it's a different problem it's legit to enhance your question as detailed as possible and hope for an answer. Don't use comment function for chat or extended discussion on other questions.
– Selaron
Nov 20 '18 at 16:00
You are asking for the 'why'. Found a quite detailed explanation here: balusc.omnifaces.org/2009/05/…
– Selaron
Nov 20 '18 at 19:18
You are asking for the 'why'. Found a quite detailed explanation here: balusc.omnifaces.org/2009/05/…
– Selaron
Nov 20 '18 at 19:18
Thank you so much, that was exactly what I was looking for !
– Ooalkman
Nov 20 '18 at 21:21
Thank you so much, that was exactly what I was looking for !
– Ooalkman
Nov 20 '18 at 21:21
add a comment |
1 Answer
1
active
oldest
votes
The answer is here (thanks to Selaron) : http://balusc.omnifaces.org/2009/05/unicode-how-to-get-characters-right.html
URL-decoding POST request parameters is a story apart. The webbrowser
is namely supposed to send the charset used in the Content-Type
request header. However, most webbrowsers doesn't do it. Those
webbrowsers will just use the same character encoding as the page with
the form was delivered with, i.e. it's the same charset as specified
in Content-Type header of the HTTP response or the tag.
Basically the problem comes from the navigator, which should pass the encoding charset it used within the header request but does not do it. Since Tomcat is not given any charset to decode the request, it decides on its own to do it ISO-8859-1 style by default. And apparently, you can't configure that ! So you just have to force it by indicating the encoding charset was UTF-8.
I guess the guy who wrote the lectures I'm following had a better navigator, because he never mentioned that problem. Anyway, now I feel a lot better ! Thanks a lot !
answered Nov 20 '18 at 21:28
OoalkmanOoalkman
83
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53396303%2fwrong-encoding-using-post-method-from-jsp-to-jsp-on-a-tomcat-server%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The answer is here (thanks to Selaron) : http://balusc.omnifaces.org/2009/05/unicode-how-to-get-characters-right.html
URL-decoding POST request parameters is a story apart. The webbrowser
is namely supposed to send the charset used in the Content-Type
request header. However, most webbrowsers doesn't do it. Those
webbrowsers will just use the same character encoding as the page with
the form was delivered with, i.e. it's the same charset as specified
in Content-Type header of the HTTP response or the tag.
Basically the problem comes from the navigator, which should pass the encoding charset it used within the header request but does not do it. Since Tomcat is not given any charset to decode the request, it decides on its own to do it ISO-8859-1 style by default. And apparently, you can't configure that ! So you just have to force it by indicating the encoding charset was UTF-8.
I guess the guy who wrote the lectures I'm following had a better navigator, because he never mentioned that problem. Anyway, now I feel a lot better ! Thanks a lot !
answered Nov 20 '18 at 21:28
OoalkmanOoalkman
83
add a comment |
The answer is here (thanks to Selaron) : http://balusc.omnifaces.org/2009/05/unicode-how-to-get-characters-right.html
URL-decoding POST request parameters is a story apart. The webbrowser
is namely supposed to send the charset used in the Content-Type
request header. However, most webbrowsers doesn't do it. Those
webbrowsers will just use the same character encoding as the page with
the form was delivered with, i.e. it's the same charset as specified
in Content-Type header of the HTTP response or the tag.
Basically the problem comes from the navigator, which should pass the encoding charset it used within the header request but does not do it. Since Tomcat is not given any charset to decode the request, it decides on its own to do it ISO-8859-1 style by default. And apparently, you can't configure that ! So you just have to force it by indicating the encoding charset was UTF-8.
I guess the guy who wrote the lectures I'm following had a better navigator, because he never mentioned that problem. Anyway, now I feel a lot better ! Thanks a lot !
answered Nov 20 '18 at 21:28
OoalkmanOoalkman
83
add a comment |
The answer is here (thanks to Selaron) : http://balusc.omnifaces.org/2009/05/unicode-how-to-get-characters-right.html
URL-decoding POST request parameters is a story apart. The webbrowser
is namely supposed to send the charset used in the Content-Type
request header. However, most webbrowsers doesn't do it. Those
webbrowsers will just use the same character encoding as the page with
the form was delivered with, i.e. it's the same charset as specified
in Content-Type header of the HTTP response or the tag.
Basically the problem comes from the navigator, which should pass the encoding charset it used within the header request but does not do it. Since Tomcat is not given any charset to decode the request, it decides on its own to do it ISO-8859-1 style by default. And apparently, you can't configure that ! So you just have to force it by indicating the encoding charset was UTF-8.
I guess the guy who wrote the lectures I'm following had a better navigator, because he never mentioned that problem. Anyway, now I feel a lot better ! Thanks a lot !
answered Nov 20 '18 at 21:28
OoalkmanOoalkman
83
The answer is here (thanks to Selaron) : http://balusc.omnifaces.org/2009/05/unicode-how-to-get-characters-right.html
URL-decoding POST request parameters is a story apart. The webbrowser
is namely supposed to send the charset used in the Content-Type
request header. However, most webbrowsers doesn't do it. Those
webbrowsers will just use the same character encoding as the page with
the form was delivered with, i.e. it's the same charset as specified
in Content-Type header of the HTTP response or the tag.
Basically the problem comes from the navigator, which should pass the encoding charset it used within the header request but does not do it. Since Tomcat is not given any charset to decode the request, it decides on its own to do it ISO-8859-1 style by default. And apparently, you can't configure that ! So you just have to force it by indicating the encoding charset was UTF-8.
I guess the guy who wrote the lectures I'm following had a better navigator, because he never mentioned that problem. Anyway, now I feel a lot better ! Thanks a lot !
answered Nov 20 '18 at 21:28
OoalkmanOoalkman
83
answered Nov 20 '18 at 21:28
OoalkmanOoalkman
83
answered Nov 20 '18 at 21:28
OoalkmanOoalkman
83
answered Nov 20 '18 at 21:28
OoalkmanOoalkman
83
83
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53396303%2fwrong-encoding-using-post-method-from-jsp-to-jsp-on-a-tomcat-server%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Possible duplicate of UTF-8 encoding a servlet form submission with Tomcat
– Selaron
Nov 20 '18 at 15:39
It is indeed the same problem, but it does not really gives an answer to my question (which I have precised in editing my initial post). There are some general concepts that I actually don't understand and I would like to have a more complete answer. Maybe should I post on the thread you have linked ?
– Ooalkman
Nov 20 '18 at 15:56
No, if you still feel it's a different problem it's legit to enhance your question as detailed as possible and hope for an answer. Don't use comment function for chat or extended discussion on other questions.
– Selaron
Nov 20 '18 at 16:00
You are asking for the 'why'. Found a quite detailed explanation here: balusc.omnifaces.org/2009/05/…
– Selaron
Nov 20 '18 at 19:18
Thank you so much, that was exactly what I was looking for !
– Ooalkman
Nov 20 '18 at 21:21