应显式导入 java.nio.charset.StandardCharsets 并使用其静态常量（如 StandardCharsets.UTF_8），避免字符串硬编码引发的拼写错误、大小写敏感及运行时异常，提升类型安全与可维护性。
直接使用 StandardCharsets 中的静态常量（如 StandardCharsets.UTF_8）替代字符串字面量（如 "UTF-8"），可彻底避免拼写错误、大小写不一致、非法字符集名导致的 UnsupportedEncodingException 或运行时异常。
避免字符串硬编码带来的典型问题
手动传入字符集名称字符串存在多个隐患：
-
拼写错误：例如写成
"UTf-8"或"UTF_8"，JVM 无法识别，抛出UnsupportedEncodingException（在旧 API 中）或IllegalCharsetNameException（在 NIO 中） -
大小写敏感：虽然多数 JVM 对
"utf8"宽容，但规范要求是"UTF-8"，依赖实现行为不可靠 - 无编译期检查：字符串错误只能在运行时暴露，测试覆盖不到就容易上线出错
- IDE 无法自动补全或导航：不如静态常量便于阅读和维护
优先使用 StandardCharsets 替代 new String(byte[], String) 和 String.getBytes(String)
Java 7 引入 StandardCharsets 后，所有标准字符集均有对应常量。应主动替换易错的字符串参数调用：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- ❌ 不推荐：
new String(bytes, "UTF-8")或str.getBytes("UTF-8") - ✅ 推荐：
new String(bytes, StandardCharsets.UTF_8)或str.getBytes(StandardCharsets.UTF_8) - ✅ 同样适用于
InputStreamReader、OutputStreamWriter、Files.readString()（Java 11+）、Files.write()等需要Charset参数的 API
注意部分老 API 仍只接受字符串，需谨慎过渡
某些遗留接口（如 URLDecoder.decode(String, String)、URLEncoder.encode(String, String)）尚未重载支持 Charset 参数，此时仍需传字符串。建议：
立即学习“Java免费学习笔记（深入）”；
- 用
StandardCharsets.UTF_8.name()获取标准名称，而非手写字符串 —— 利用常量保证正确性 - 封装一层工具方法，统一处理编码/解码逻辑，内部基于
StandardCharsets构建，对外屏蔽字符串细节 - 若项目已升级至 Java 15+，可考虑使用
java.net.URLEncoder.encode(String, Charset)（新增重载）替代旧版
扩展：自定义字符集场景下如何保持安全性
StandardCharsets 仅涵盖 ISO-8859-1、US-ASCII、UTF-8、UTF-16 等 7 种标准集。若必须使用非标字符集（如 GBK、Shift_JIS）：
- 仍应避免硬编码字符串，可定义
public static final Charset GBK = Charset.forName("GBK")在工具类中集中管理 - 在初始化阶段校验字符集是否可用（
Charset.isSupported("GBK")），失败则快速失败并提示明确错误 - 生产环境尽量约束为 UTF-8，减少跨系统字符集兼容风险
