整理 | 张仕影
出品 | CSDN（ID：CSDNnews）

上个月，Oracle 官网发布了 JDK 18/Java 18 正式版。据悉，Java 18 在性能、稳定性和安全性上得到了全面的改进提升，其中包括对平台的九项 JDK 增强（JEP），大大提升了开发人员的工作效率。

已知 JDK 18 版本主要集中在 9 个增强功能上，其中之一即是将 UTF-8 设置为标准 Java API 的默认字符集。在 JDK 17 及更早版本中，默认字符集要在 Java 虚拟机运行时才能确定，所以取决于不同的操作系统、语言环境等因素，在实现和处理方面存在着一些问题。而从 Java 18 开始，依赖于默认字符集的 API 会在所有实现、操作系统、语言环境和配置中保持一致。

默认为 UTF-8 前存在的问题

默认字符集通常是在以下这个函数中计算的：

Charset.defaultCharset() 

在 Javadoc（javadoc 命令是用来生成自己 API 文档的）中有一句话：“默认字符集是在虚拟机运行时确定的，通常根据语言环境和底层操作系统使用的字符集来确定。”这意味着默认字符集在不同的操作系统、地理区域和用户偏好之间可能会有很大差异，也就是说甚至有可能同一台物理机上的两个用户具有不同的默认字符集。

此外，如果我们在构建过程中没有指定任何字符集，那么像 java.io.FileWriter 或 java.io.FileReader 这样较旧的 JDK API 将会使用默认字符集进行写入操作；而在新的版本中，像 java.nio.file.Files 这样的新 API 将默认为 UTF-8。

还有就是许多开发者依靠不受支持的系统属性 file.encoding 在 JVM（Java虚拟机）启动时设置默认字符集。虽然有一些 JVM 可能支持它，但这并不能保证其他 JVM 也支持。

默认为 UTF-8 的好处

Java 18 将 UTF-8 作为所有实现、操作系统、语言环境和配置的默认字符集。那么，所有依赖于默认字符集的 API 将会表现一致，而不需要设置 file.encoding 系统属性，也不需要在创建相应对象时总是指定字符集。我们都知道字符集一致的重要性，而默认为 UTF-8 将能提高我们软件的可靠性和一致性，是一个非常受欢迎的变化。

仍有一些问题存在

如果我们想让 JDK 18 表现得和以前的版本一样，那么我们必须以 -Dfile.encoding=COMPAT 启动 JVM，比如我们有一些无法重新编译的源代码，并且它依赖于和 UTF-8 不同的默认字符集，那就需要这样做。而在所有其他情况下，不必设置此属性。不过要注意，在你使用 -Dfile.encoding=COMPAT 和 java.nio.file.Files 中的函数，而不定义字符集但回退到 UTF-8 的情况下，你会回到原点——你的应用程序的某些部分将以 UTF-8 读取/写入文件，而其他部分则用运行中 JVM 的默认字符集。

在 JDK 17 及之前版本中，我们都可以写入 Charset.forName(“default”) 来获得 JVM 的默认字符集。而在 JDK 18 中，该行代码将会抛出一个 UnsupportedCharsetException。因此，如果我们的源代码中有这句话，或是我们使用任何包含此语句的库，我们的应用程序就会在运行时抛出该异常。

关于该功能的更多具体细节及规范可参考 JEP 400 （https://openjdk.java.net/jeps/400）。

参考链接：https://thejavaguy.org/posts/006-new-in-java-18-utf8-by-default/#compatibility-with-previous-jdks