关于java:Java-18为什么要指定UTF8为默认字符集

3次阅读

共计 1736 个字符，预计需要花费 5 分钟才能阅读完成。

在 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.bilibili.com/video/BV1YY4y1a7vGopen in new window

如果您学习过程中如遇艰难？能够退出咱们超高品质的技术交换群，参加交换与探讨，更好的学习与提高！另外，不要走开，关注我！继续更新 Java 新个性教程！