Java字符编码实战核心是建立“字节流→解码规则→字符流”链路意识,通过文件读写、HTTP请求、数据库交互及编码转换工具四类场景,亲手制造并修复乱码,强调显式指定编码、避免默认陷阱、双重验证一致性。

Java 中字符编码综合实战练习的核心,不是背概念,而是建立“字节流→解码规则→字符流”的完整链路意识。重点在于亲手制造、识别、修复乱码场景,把编码不一致带来的问题暴露出来,再用明确的 API 手段解决。
从文件读写开始练:强制指定编码,绕过默认陷阱
FileReader 和 FileWriter 默认使用系统平台编码(Windows 常为 GBK,Linux/macOS 通常为 UTF-8),极易导致跨环境乱码。实战第一步就是彻底弃用它们,改用 InputStreamReader / OutputStreamWriter 显式传入编码名。
- 准备一个用 GBK 编码保存的文本文件(可用记事本另存为 → 编码选“ANSI”即 GBK)
- 用
new InputStreamReader(new FileInputStream(file), "GBK")正确读取,验证中文正常显示 - 故意错用
"UTF-8"读取同一文件,观察是否出现“锟斤拷”或方块 - 再用
OutputStreamWriter将字符串写入新文件,分别指定"UTF-8"和"GBK",用不同编辑器打开对比效果
模拟网络请求场景:HTTP 头与内容编码联动验证
HTTP 协议中,Content-Type 的 charset 参数必须和实际响应体编码一致。实战可借助简易 HTTP 工具或自己写 Socket 模拟。
- 启动一个本地 HTTP 服务(如 Spring Boot 的 @RestController),返回含中文的 JSON 字符串
- 手动设置响应头:
response.setContentType("application/json; charset=GBK"),但内部用 UTF-8 编码生成响应体 → 观察客户端是否乱码 - 反过来,设 header 为
charset=UTF-8,但用 GBK 编码写响应体 → 同样复现乱码 - 用
HttpURLConnection或OkHttpClient接收响应时,检查getContentType()并按声明的 charset 解码字节流
数据库交互实操:JDBC 连接参数与 SQL 执行双重控制
MySQL 等数据库的乱码常因连接层未对齐。实战需同时配置连接参数和驱动行为。
- JDBC URL 加上
?characterEncoding=utf-8&useUnicode=true(MySQL 8.0+ 还需serverTimezone=UTC) - 插入一条含中文的数据,用命令行 mysql 客户端查一遍,确认存储正确
- 在 Java 中用
PreparedStatement查询该记录,打印rs.getString("name"),看是否乱码 - 若仍乱码,检查 MySQL 服务端配置:
character_set_server和库/表的COLLATION是否为utf8mb4
编码转换工具封装:动手写一个安全的转码方法
很多老系统接口返回 ISO-8859-1 编码的中文(本质是误用),需要转成 UTF-8。这不是简单 new String(bytes, "UTF-8"),而要先按原始编码还原字节,再重新编码。
- 写一个工具方法:
public static String isoToUtf8(String isoStr) - 内部执行:
new String(isoStr.getBytes("ISO-8859-1"), "UTF-8") - 测试输入
"%E4%B8%AD%E6%96%87"(URL 编码)先 decode 成 ISO-8859-1 字符串,再调用该方法转 UTF-8 - 补充异常处理,捕获
UnsupportedEncodingException并给出明确提示
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南











