java中iso-8859-1转utf-8需先按iso-8859-1获取字节再用utf-8解码，不可直接getbytes()；tomcat 8.5+默认支持utf-8，仅旧版本未配uriencoding时才需修复。
Java 中将 ISO-8859-1 编码的字节数组或字符串转为 UTF-8，本质不是“直接转换”，而是先按 ISO-8859-1 解码出原始字节，再用 UTF-8 重新编码为字符串。常见于 Tomcat 默认参数接收、旧系统兼容等场景。避坑关键在于：**别把编码逻辑写死在业务代码里，更别在已知是 UTF-8 的环境重复解码**。
明确数据来源和当前真实编码
很多乱码问题源于误判原始编码。例如：
- Tomcat 8.5+ 默认已支持 UTF-8 请求体（需配置
URIEncoding="UTF-8"），此时request.getParameter("name")返回的就是正确 UTF-8 字符串，无需再做 ISO-8859-1 → UTF-8 转换； - 只有在 Tomcat 未配置 URIEncoding 或老版本（如 7.x）且客户端以 ISO-8859-1 发送时，才可能出现“中文变成乱码字符串”，这时才需要修复解码逻辑。
安全转换的两步法（推荐）
假设你确认 str 是一个用 ISO-8859-1 编码后又被错误当作平台默认编码（如 Windows-GBK）读取的字符串（即它本身是“假字符串”，底层字节其实是 ISO-8859-1 编码的原始字节），应这样还原：
-
第一步：还原字节 —— 把这个“假字符串”按其实际编码（ISO-8859-1）转回原始字节数组：
byte[] bytes = str.getBytes(StandardCharsets.ISO_8859_1); -
第二步：正确解码 —— 用 UTF-8 将字节解释为真正的字符串：
String utf8Str = new String(bytes, StandardCharsets.UTF_8);
⚠️ 注意：不能写成 new String(str.getBytes(), StandardCharsets.UTF_8)，因为 getBytes() 默认用平台编码，会二次失真。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
避免硬编码，统一入口处理
把转换逻辑散落在 Controller 或 Service 层，极易遗漏或重复执行。建议：
- 在 Web 层（如 Spring MVC）通过
@Configuration注册CharacterEncodingFilter，并设encoding="UTF-8"、forceRequestEncoding=true； - 对 Tomcat，确保
server.xml中 Connector 配置含：URIEncoding="UTF-8" useBodyEncodingForURI="true"； - 若必须手动处理（如解析第三方回调参数），封装为工具方法，并加注释说明适用前提，例如： // 仅用于修复 Tomcat 7.x 未配 URIEncoding 时的 request.getParameter() 乱码
检查并关闭“自动转换陷阱”
某些框架或中间件（如旧版 Struts、部分日志拦截器）会在读取请求流时擅自调用 getReader() 或 getParameter()，导致请求体被提前消费且按错误编码解析。后果是后续再读流就为空，或反复转换出错。应对方式：
- 确保请求体只被读取一次；
- 如需多次使用，用
ContentCachingRequestWrapper包装原始 request； - 避免在 Filter 中无意识触发
getParameter()—— 它会强制解析整个 query string 和 body。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
