java字符集安全使用需优先用standardcharsets常量（如utf_8）避免字符串硬编码风险，非标编码如gbk应集中管理并校验，控制台输入须匹配终端真实编码，且注意api兼容性边界。
Java 中字符集的安全使用，核心是避免字符串硬编码、确保编译期校验、统一 Charset 实例复用，并匹配真实运行环境的编码需求。
优先用 StandardCharsets 替代字符串字面量
直接写 "UTF-8" 有拼错（如 "UTf-8"）、大小写不一致（"utf8"）、运行时抛 UnsupportedCharsetException 等风险。StandardCharsets 提供了 7 种标准字符集的静态常量，全部在编译期可验证：
-
StandardCharsets.UTF_8—— 推荐用于绝大多数场景，跨平台兼容性好 -
StandardCharsets.ISO_8859_1—— 常用于 HTTP 头、表单编码等轻量场景 -
StandardCharsets.US_ASCII—— 明确限定只处理 ASCII 字符，适合协议解析
所有接受 Charset 参数的 API（如 String.getBytes(Charset)、new String(byte[], Charset)、InputStreamReader(InputStream, Charset)、Files.readString(path, Charset)）都应传入这些常量，而非字符串。
非标准字符集要集中管理
GBK、GB2312、Big5 等不在 StandardCharsets 中，但也不能散落在各处硬编码：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 在工具类中定义
public static final Charset GBK = Charset.forName("GBK");，并加注释说明适用平台（如“Windows cmd 默认”） - 初始化时做一次校验：
if (!GBK.canEncode()) throw new IllegalStateException("GBK not available"); - 避免在循环或高频路径中反复调用
Charset.forName("GBK")，它会触发内部查找开销
控制台输入必须匹配终端真实编码
System.in 是字节流，InputStreamReader 解码时若 charset 不匹配终端实际编码，必然乱码：
- Linux/macOS/Terminal/PowerShell/Git Bash：通常为 UTF-8 → 用
StandardCharsets.UTF_8 - Windows cmd：默认 GBK → 可用
Charset.forName("GBK")，或先执行chcp 65001切换为 UTF-8 后统一用StandardCharsets.UTF_8 - IDE 内置终端（如 IntelliJ）：需在设置中确认“Terminal Encoding”与代码中指定的 Charset 一致
务必包装成 BufferedReader 使用，提升读取效率，且不要对同一 System.in 多次创建独立的 InputStreamReader。
注意 API 差异与兼容边界
不是所有地方都能直接用 StandardCharsets：
-
URLEncoder.encode(str, "UTF-8")和URLDecoder.decode(str, "UTF-8")在 Java 15+ 才支持Charset重载，旧版本建议用StandardCharsets.UTF_8.name()获取名称，避免手写 -
FileReader/FileWriter不接受Charset，应改用InputStreamReader+FileInputStream或Files.newBufferedReader(path, charset) -
StandardCharsets.UTF_8是线程安全单例，可全局复用，无需每次新建或重复获取
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
