1. 引言：理解HTTP请求中的字符编码挑战
在现代web开发中，utf-8已成为主流的字符编码标准。然而，在处理遗留系统或与不支持utf-8的客户端交互时，spring boot应用程序可能需要兼容其他字符编码，例如windows-1252。当服务器收到一个声称使用特定编码（如windows-1252）的请求，但实际请求体内容却以不同编码（如utf-8）发送时，便会出现字符乱码问题，即所谓的“mojibake”。本文将深入探讨这一问题，并提供准确的测试与解决方案。
2. Spring Boot对请求编码的默认处理
Spring Boot应用程序通常使用内嵌的Servlet容器（如Tomcat、Jetty或Undertow）。这些容器在接收HTTP请求时，会检查Content-Type请求头中的charset参数。如果该参数存在，容器会尝试使用指定的字符集来解码请求体。如果未指定charset，则通常会回退到容器的默认编码（在Spring Boot 2.x及更高版本中，默认通常是UTF-8）。
Spring Boot通过HttpMessageConverter（例如MappingJackson2HttpMessageConverter用于JSON）来处理请求体的反序列化。当Servlet容器正确地将原始字节流解码为Java字符串后，HttpMessageConverter便能接收到正确的字符数据进行处理。这意味着，在大多数情况下，Spring Boot本身无需额外的复杂配置即可正确处理声明了非UTF-8编码的请求。
3. 常见的测试误区：cURL与字符编码
许多开发者在模拟不同编码的HTTP请求时，常会遇到一个普遍的误区：即使在Content-Type头中明确指定了charset，但如果请求体数据本身并未按照该编码生成，仍会导致服务器端解码失败。
考虑以下使用cURL发送Windows-1252编码请求的示例：
curl --request POST \
--url http://localhost:8080/string-encoding/v1/my-string \
--header 'Content-Type: application/json; charset=Windows-1252' \
--data '{
"text": "Apenas um teste técnico çâãéüûà"
}'上述cURL命令的问题在于，--data参数后面的字符串字面量通常会由执行cURL的终端以其默认编码（通常是UTF-8）进行编码并发送。这意味着，即使Content-Type头声明了charset=Windows-1252，实际发送的字节流却是UTF-8编码的。当服务器接收到这些UTF-8编码的字节，并尝试使用Windows-1252进行解码时，就会产生乱码（例如，UTF-8中的ç被误解码为Windows-1252中的ç）。
4. 正确模拟非UTF-8编码的HTTP请求
要准确测试Spring Boot应用程序对非UTF-8编码请求的处理能力，关键在于确保发送的请求体内容与Content-Type头中声明的charset完全一致。最可靠的方法是将请求体内容写入一个文件，并确保该文件以目标编码保存，然后使用cURL读取该文件内容发送。
步骤一：创建并保存编码文件
使用一个支持选择编码的文本编辑器（如Notepad++、VS Code、Sublime Text等），创建一个JSON文件，并将其内容保存为Windows-1252编码。
例如，创建一个名为test-1252.json的文件，内容如下：
{
"text": "Apenas um teste técnico çâãéüûà"
}请务必将此文件保存为Windows-1252（或CP1252）编码。
步骤二：使用cURL发送文件内容
使用cURL的-d @filename选项来发送文件内容。这会指示cURL读取文件的原始字节流并将其作为请求体发送。
curl -d @test-1252.json \ -H "Content-Type: application/json; charset=Windows-1252" \ http://localhost:8080/string-encoding/v1/my-string
通过这种方式，客户端发送的字节流将真正是Windows-1252编码的。如果Spring Boot应用程序配置正确（如前所述，默认情况下通常是），它将能够根据Content-Type头中的charset=Windows-1252参数正确地解码请求体，从而避免乱码。
5. 验证与调试
为了验证Spring Boot应用程序是否正确接收并解码了请求，可以在控制器层或自定义的Filter中打印HttpServletRequest的字符编码和请求体内容：
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RestController;
import javax.servlet.http.HttpServletRequest;
@RestController
public class StringTestController {
@PostMapping("/string-encoding/v1/my-string")
public MyString postString(HttpServletRequest request, @RequestBody MyString myString) {
try {
// 获取请求的字符编码
String requestEncoding = request.getCharacterEncoding();
System.out.println("Received Request Encoding: " + requestEncoding);
System.out.println("Received Text (from @RequestBody): " + myString.getText());
// 也可以尝试直接从输入流读取，但通常不推荐，因为@RequestBody已经处理了
// String body = request.getReader().lines().collect(Collectors.joining(System.lineSeparator()));
// System.out.println("Raw Body (from Reader): " + body);
} catch (Exception e) {
e.printStackTrace();
}
return myString; // 返回处理后的对象，验证是否正确
}
}
// 示例DTO
class MyString {
private String text;
public String getText() {
return text;
}
public void setText(String text) {
this.text = text;
}
@Override
public String toString() {
return "MyString{text='" + text + "'}";
}
}当使用正确的cURL命令发送Windows-1252编码的请求时，应用程序的日志应显示Received Request Encoding: Windows-1252，并且Received Text (from @RequestBody)应显示正确的非乱码字符串。
注意事项：
- server.servlet.encoding.charset: 这个Spring Boot属性主要用于设置当客户端未指定charset时，服务器使用的默认编码，以及响应的编码。它不会强制覆盖客户端在Content-Type头中明确声明的charset。
- server.servlet.encoding.force: 如果设置为true，它会强制请求和响应使用server.servlet.encoding.charset指定的编码，即使客户端或浏览器指定了其他编码。但在处理外部客户端发送的特定编码请求时，通常不建议强制，因为这可能导致客户端发送的数据被错误解码。
- 客户端行为: 确保客户端（无论是遗留应用还是其他系统）在发送请求时，其请求体内容的实际编码与Content-Type头中的charset声明完全一致，是解决此类问题的根本。
6. 总结
Spring Boot及其底层Servlet容器在处理HTTP请求时，能够很好地识别并应用Content-Type头中声明的字符编码。导致乱码问题的根本原因往往不在于Spring Boot的配置缺陷，而在于测试方法未能准确模拟客户端发送的实际编码。通过创建并发送正确编码的文件，开发者可以有效地验证应用程序对多编码请求的处理能力。理解并遵循HTTP协议中关于字符编码的规范，是构建健壮、兼容性强的Web应用程序的关键。
