关于jdk18乱码问题详解

博客开篇演示Java乱码问题,提出将Project Encoding改为GBK可解决。接着分析JDK17和JDK18,JDK17解码和编码一致不会乱码,JDK18因不直接用系统默认字符集,即使file.encoding为utf - 8,charset为GBK也会导致乱码。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

开篇直接步入正题,演示乱码:

        一个简单的测试方法+允许环境+文件编码

这是运行结果:乱码。

解决方案如下:只要把Project Encoding 改为GBK就能解决问题(其他不用改)。

看到这里我相信很多小伙伴就能解决问题了,下面谈一下我对这个系统打印的理解。希望能够帮助大家(新人勿喷。)

先谈一下jdk17:

我用这个测试类测试过,他无论是用utf-8还是使用gbk都不会产生乱码,于是我尝试观察源码有如下发现:

1.通过查阅源码,我发现最后对于打印的实现是通过charout实现的,

2.初始化时,如果你没有传入具体的字符集名称,他会加载一个默认的字符集。

3.而默认字符集的加载它回去加载系统配置的file.encoding,没有的话就是utf-8

所以我们就能够发现他不出乱码的原因了,解码和编码一致就不会产生乱码。

然后我们看一下jdk18:

他并不是直接使用系统的默认字符集,然后呢即使file.encoding=utf-8,而charset却是GBK

然后就导致乱码。这就是我的见解,欢迎大家交流。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值