本文揭示Jackson序列化含Unicode字符（如µ）时出现Invalid UTF-8 start byte 0xb5的根本原因：并非JSON本身不合法，而是Spring默认StringHttpMessageConverter强制使用ISO-8859-1编码覆盖了UTF-8字节流，导致接收端Jackson按UTF-8解码时遭遇非法起始字节。
本文揭示jackson序列化含unicode字符（如µ）时出现`invalid utf-8 start byte 0xb5`的根本原因：并非json本身不合法，而是spring默认`stringhttpmessageconverter`强制使用iso-8859-1编码覆盖了utf-8字节流，导致接收端jackson按utf-8解码时遭遇非法起始字节。
你遇到的 com.fasterxml.jackson.core.JsonParseException: Invalid UTF-8 start byte 0xb5 错误，表面看是接收方Jackson“无法解析µ”，实则是HTTP消息编码层被静默篡改所致——而罪魁祸首，正是 Spring 框架中一个极易被忽视的默认行为。
? 根本原因：Spring 的 StringHttpMessageConverter 默认 ISO-8859-1
尽管你在请求头中明确声明了：
Content-Type: application/json;charset=UTF-8
且 Jackson（ObjectMapper.writeValueAsString()）输出的 JSON 字符串在 JVM 内部确实是合法 UTF-16/UTF-8 字节序列（µ 编码为 0xC2 0xB5），但 Spring 的 RestTemplate 或 WebMvc 在发送 String 类型请求体时，会委托 StringHttpMessageConverter 进行 HTTP 正文编码。
⚠️ 关键事实：
Spring 5.x 及更早版本中，StringHttpMessageConverter 的默认字符集是 ISO-8859-1，而非 UTF-8。
这意味着：即使你的 String body 包含 Unicode 字符（如 µ），StringHttpMessageConverter 会尝试用 ISO-8859-1 将其编码为字节流——而 µ 在 ISO-8859-1 中对应单字节 0xB5；该字节被直接写入 HTTP 请求体，完全丢失了 UTF-8 所需的双字节结构（0xC2 0xB5）。
于是，接收方服务（Receiver）收到的是：
0x7B 0x22 0x61 0x70 0x69 ... 0xB5 0x73 0x22 0x7D ← 非法 UTF-8 字节流（0xB5 单独出现）
而 Jackson 的 JsonFactory 严格按 UTF-8 解析，发现 0xB5 不是合法 UTF-8 起始字节（它既不是 ASCII 0x00–0x7F，也不是多字节序列的 lead byte 0xC0–0xF4），于是抛出 Invalid UTF-8 start byte 0xb5 —— 错误不在 JSON 内容，而在传输字节已损坏。
✅ 正确解决方案：强制 StringHttpMessageConverter 使用 UTF-8
不要依赖 ESCAPE_NON_ASCII（它只是将 µ 转义为 \u00b5，增加体积且掩盖问题本质）。应从协议层修复编码一致性：
方案一：全局配置（推荐，Spring Boot）
@Configuration
public class WebConfig {
@Bean
public RestTemplate restTemplate() {
RestTemplate restTemplate = new RestTemplate();
// 替换默认 StringHttpMessageConverter，指定 UTF-8
List<HttpMessageConverter<?>> converters = restTemplate.getMessageConverters();
converters.replaceAll(c ->
c instanceof StringHttpMessageConverter
? new StringHttpMessageConverter(StandardCharsets.UTF_8)
: c
);
return restTemplate;
}
}方案二：手动构造 HttpEntity（精准控制）
String body = objectMapper.writeValueAsString(myPojo);
HttpHeaders headers = new HttpHeaders();
headers.setContentType(MediaType.APPLICATION_JSON); // 自动带 charset=UTF-8
HttpEntity<String> entity = new HttpEntity<>(body, headers);
ResponseEntity<String> response = restClient.exchange(
url, HttpMethod.POST, entity, String.class
);✅ 注意：
MediaType.APPLICATION_JSON默认包含charset=UTF-8，且RestTemplate.exchange()会正确调用StringHttpMessageConverter的 UTF-8 实例（前提是未被全局覆盖）。
? 为什么 ESCAPE_NON_ASCII = true “能用”？
它让 Jackson 将所有非 ASCII 字符（包括 µ）转义为 \uXXXX 形式：
{"apiserver.latency.k8s.io/response-write":"1.446\u00b5s"}此时字符串仅含 ASCII 字符，StringHttpMessageConverter 用 ISO-8859-1 编码也不会出错（ASCII 字节 0x5C 0x75 0x30 0x30 0x62 0x35 完全兼容），接收方再解码 \u00b5 还原为 µ。
但这属于绕过问题的临时补丁：增大 payload、降低可读性、且无法解决其他 UTF-8 多字节字符（如中文、emoji）的真实传输需求。
? 总结：三步构建健壮的 JSON Unicode 通信链
-
发送端：确保
StringHttpMessageConverter显式使用UTF-8（而非依赖默认值）； -
接收端：检查
Content-Type头是否被中间件（Nginx、API 网关）篡改或丢弃 charset； -
调试黄金法则：当 JSON 解析失败时，不要先看字符串内容，而要抓包查看原始 HTTP 响应体字节（如用 Wireshark 或
curl -v），验证µ对应的字节是0xC2 0xB5（正确 UTF-8）还是0xB5（ISO-8859-1 污染）。
真正的容错，始于对 HTTP 协议栈每一层编码责任的清醒认知——JSON 是文本，而文本在网络里，永远以字节行走。
