Java 18为什么要指定UTF-8为默认字符集

在Java 18中，将UTF-8指定为标准Java API的默认字符集。有了这一更改，依赖于默认字符集的API将在所有实现、操作系统、区域设置和配置中保持一致。

做这一更改的主要目标：

• 当Java程序的代码依赖于默认字符集时，使其更具可预测性和可移植性。
• 阐明标准Java API在哪里使用默认字符集。
• 在整个标准Java API中对UTF-8进行标准化，但控制台I/O除外。

需要注意的是，这一更改的目标并不是定义新的标准Java API或受支持的JDK API，尽管这项工作可能会发现新的便利方法可能会使现有的API更易于使用，这一更改并不是要弃用或删除依赖默认字符集的标准Java API。

用于读写文件和处理文本的标准Java API允许将字符集作为参数传递。字符集控制Java编程语言的原始字节和16位字符值之间的转换。例如，支持的字符集包括US-ASCII、UTF-8和ISO-8859-1。

如果没有传递字符集参数，则标准的Java API通常使用默认的字符集。JDK在启动时根据运行时环境选择默认的字符集：操作系统、用户的区域设置和其他因素。

因为默认字符集在每个地方都不一样，所以使用默认字符集的API会带来许多不明显的危险，甚至对经验丰富的开发人员也是如此。

考虑这样一个应用程序，它在不传递字符集的情况下创建一个java.io.FileWriter，然后使用它将一些文本写入文件。结果文件将包含一个使用运行应用程序的JDK的默认字符集编码的字节序列。第二个应用程序在不同的机器上运行，或者由同一台机器上的不同用户运行，在不传递字符集的情况下创建一个java.io.FileReader，并使用它来读取该文件中的字节。生成的文本包含使用运行第二个应用程序的JDK的默认字符集解码的字符序列。如果第一个应用程序的JDK和第二个应用程序的JDK之间的默认字符集不同，则生成的文本可能会被损坏或不完整，因为FileReader无法判断它使用了相对于FileWriter的错误字符集来解码文本。

比如这就是一个典型的例子，在MacOS上以UTF-8编码的日语文本文件在Windows上以美英或日语区域设置读取时被损坏：

java.io.FileReader(“hello.txt”) -> “こんにちは” (macOS)
java.io.FileReader(“hello.txt”) -> “??“??“???????? ” (Windows (en-US))
java.io.FileReader(“hello.txt”) -> “縺ォ縺。縺ッ” (Windows (ja-JP)

在JDK 17及更早版本中，默认字符集是在Java运行时才确定的。在MacOS上，除POSIX C语言环境外，它是UTF-8。在其他操作系统上，取决于用户的区域设置，比如：Windows上，它是基于代码页的字符集，如Windows-1252或Windows-31j。如果不清楚Java应用运行环境的默认编码，可以使用这个命令查看当前JDK的默认字符集：

java -XshowSettings:properties -version 2>&1 | grep file.encoding

程序猿DD Tips：在过去的版本中，当读写文件时，没有指明字符集的话，所选择的字符集与操作系统、用户区域等因素相关，而不同的操作系统的默认编码不同，所以很可能会出现读写编码不一致的情况，从而导致程序在不同系统下运行出现乱码问题。所以这一更改可以让Java开发的应用具备更好的移植性。同时，从这一点的改进，也提醒我们，在读写文件的时候，为了你的应用有更好的可移植性，在涉及读写操作的时候，一定要加上编码参数。这样即使在Java 18之前的版本，也能拥有更好的可移植性，同时为将来升级Java 21提供更好的兼容前提。

文章来自https://www.cnblogs.com/didispace/p/16205174.html