Initially, the project functions smoothly on tomcat using UTF-8 and jboss eap 6 with UTF-8 page encoding as well. Additionally, the jboss configuration includes:
<servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only" default-encoding="UTF-8">Furthermore, when utilizing encodeURIComponent or serialize, it operates effectively. However, there is a failure when using serialize and adding certain parameters as shown below:
var params = $("#form_viewOrUpdateSchedule").serialize();
params += "&recordId=" + recordId;
params += "&custName=" + custName;
params += "&startTime=" + startTime;
params += "&content="
+ content;
params += "&endTime=" + endTime;
params += "&scheduleDate=" + getScheduleDate();
bodymask();
$.ajax({
url: url,
type: "POST",
data: params,
datatype: "JSON",
contentType : "application/x-www-form-urlencoded; charset=utf-8",
success: function(data) {Moreover, it performs well when using serialize or similar to the following:
var recordId = $("#schedule_list_id").val();
var custName = $("#schedule_list_custName option:selected").val();
var startTime = $("#schedule_list_startTime").val();
var endTime = $("#schedule_list_endTime").val();
var content = $("#schedule_list_content").val();
var startIndex = $("#schedule_list_startTime").get(0).selectedIndex;
var endIndex = $("#schedule_list_endTime").get(0).selectedIndex;
if (startIndex > endIndex) {
alertInfo("提示", "结束时间不能早于开始时间");
return;
}
var params = {}
params.recordId = recordId;
params.custName = custName;
params.startTime = startTime;
params.content = content;
params.endTime = endTime;
params.scheduleDate = getScheduleDate();
$.ajax({
url: url,
type: "POST",
data: params,In addition, jboss eap 7 (now known as WildFly, version 10) relies on undertow instead of tomcat.
Subsequently, a similar issue was raised in , and the difficulty of setting the default character encoding was resolved in WildFly 8.0, mentioned in
Lastly, the question arises as to why the code works seamlessly on tomcat but fails on jboss eap 7 with the aforementioned "thirdly" JavaScript. How can this problem be resolved without modifying the JavaScript code?