Java 中使用 StandardCharsets 避免编码乱码

在Java开发中，字符串编码乱码问题往往源于隐式依赖平台默认字符集（如Windows的GBK与Linux/macOS的UTF-8不一致），导致同一段代码跨环境运行时字节数组生成与解析错配；本文直击痛点，强调必须摒弃无参的`String.getBytes()`和字符串形式的编码指定（如`"UTF-8"`），转而使用`StandardCharsets.UTF_8`等类型安全、无需异常处理且性能更优的静态常量进行显式编解码——无论网络请求、文件读写还是跨系统交互，统一、明确、可预测的UTF-8编码实践，才是规避乱码、保障系统稳定性和可移植性的关键防线。

直接指定字符集，避免依赖平台默认编码。

为什么 String.getBytes() 容易乱码

调用 String.getBytes() 无参重载时，Java 会使用 Charset.defaultCharset()，该值取决于操作系统和 JVM 启动参数（如 -Dfile.encoding）。Windows 常为 GBK，Linux/macOS 通常是 UTF-8。同一段代码在不同环境运行，getBytes() 输出的字节数组可能完全不同，后续若用固定编码解码（比如强制用 UTF-8 解 GBK 编码的字节），必然乱码。

用 StandardCharsets 显式指定编码

java.nio.charset.StandardCharsets 提供了常用字符集的静态常量（如 UTF_8、ISO_8859_1、US_ASCII），类型安全、无需异常处理、性能更好。推荐始终使用带 Charset 参数的重载：

• str.getBytes(StandardCharsets.UTF_8) —— 获取 UTF-8 字节序列
• new String(bytes, StandardCharsets.UTF_8) —— 用 UTF-8 解码字节数组
• 避免 str.getBytes("UTF-8")：字符串形式需抛 UnsupportedEncodingException，且存在拼写风险

典型场景示例

网络传输或文件写入时，编码/解码必须配对：

• 发送 HTTP 请求体：body.getBytes(StandardCharsets.UTF_8)
• 读取响应并解析：new String(responseBytes, StandardCharsets.UTF_8)
• 写文本文件：Files.write(path, content.getBytes(StandardCharsets.UTF_8))
• 读文本文件：Files.readString(path, StandardCharsets.UTF_8)（Java 11+）

额外提醒

即使业务只面向中文环境，也应坚持用 StandardCharsets.UTF_8。UTF-8 兼容 ASCII，支持所有 Unicode 字符，是现代系统事实标准。若旧协议强制要求 GBK，可明确使用 StandardCharsets.ISO_8859_1 或 Charset.forName("GBK")，但务必注释说明原因，不可隐式依赖默认值。

本篇关于《Java 中使用 StandardCharsets 避免编码乱码》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！