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

如果您学习过程中如遇困难?可以加入我们超高质量的技术交流群,参与交流与讨论,更好的学习与进步!另外,不要走开,关注我!持续更新Java新特性教程

欢迎关注我的公众号:程序猿DD。第一时间了解前沿行业消息、分享深度技术干货、获取优质学习资源

发表评论

相关文章