在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。第一时间了解行业前沿资讯，分享深度技术干货，获取优质学习资源
