在Java18中,UTF-8被指定为标准JavaAPI的默认字符集。通过此更改,依赖默认字符集的API将在所有实现、操作系统、区域设置和配置中保持一致。进行此更改的主要目标是:当代码依赖于默认字符集时,使Java程序更具可预测性和可移植性。阐明标准JavaAPI在何处使用默认字符集。在整个标准JavaAPI中标准化UTF-8,控制台I/O除外。请注意,此更改的目标不是定义新的标准JavaAPI或受支持的JDKAPI,尽管这项工作可能会发现新的便利方法,这些方法可能会使现有API更易于使用。它无意弃用或删除依赖默认字符集的标准JavaAPI。用于读写文件和操作文本的标准JavaAPI允许将字符集作为参数传递。一个字符集控制着Java编程语言的原始字节和16位字符值之间的转换。例如,支持的字符集包括US-ASCII、UTF-8和ISO-8859-1。如果没有传递字符集参数,标准JavaAPI通常使用默认字符集。JDK在启动时根据运行环境选择默认字符集:操作系统、用户的区域设置和其他因素。由于默认字符集随处不同,使用默认字符集的API会引入许多不明显的危险,即使对于有经验的开发人员也是如此。考虑一个创建java.io.FileWriter而不传递字符集的应用程序,然后使用它来将一些文本写入文件。生成的文件将包含使用运行应用程序的JDK的默认字符集编码的字节序列。第二个应用程序在不同的机器上运行,或者由同一台机器上的不同用户运行,它创建了一个java.io.FileReader而没有传递字符集,并使用它来读取Festival文件中的字符。生成的文本包含使用运行第二个应用程序的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)在JDK17及更早版本中,默认字符集由确定在Java运行时。在MacOS上,除了POSIXC语言环境之外,是UTF-8。在其他操作系统上,它取决于用户的区域设置,例如:在Windows上,它是基于代码页的字符集,比如Windows-1252或者Windows-31j,如果不清楚Java应用运行环境的默认编码,可以使用这个命令查看当前JDK的默认字符集:java-XshowSettings:properties-version2>&1|grepfile.encoding程序员DD小贴士:以往版本读写文件时,如果不指定字符集,选择的字符集与操作系统、用户区等因素有关,默认不同操作系统的编码不同,所以很可能会出现读写编码不一致的情况,导致程序在不同系统下运行时出现乱码。所以这种改变可以使Java开发的应用程序具有更好的可移植性。同时,从这点上的改进也提醒我们,在读写文件的时候,为了让你的应用有更好的Portability,在读写操作的时候,一定要加上encoding参数。这样即使是Java18之前的版本也能有更好的移植性,同时为以后升级到Java21提供更好的兼容性本文配套视频:https://www.bilibili.com/video/BV1YY4y1a7vGopeninnewwindow如果您在学习过程中遇到困难?您可以加入我们超优质的技术交流群,参与交流讨论,更好的学习和进步!另外,不要走,跟我走!持续更新新的Java特性教程!欢迎关注我的公众号:程序员DD。第一时间了解行业前沿资讯,分享深度技术干货,获取优质学习资源
