针对这个问题的短回答就是:没有任何理由保存代码为 GBK

将项目的文件或者数据库字符集等设计到编码的地方使用 GBK,会带来很严重的兼容性问题。

保存为 GBK 通常是历史遗留问题,尤其是老的 C/S 架构项目,代码多为 GB2312 / GBK ,在早期的 Java EJB 项目中很多也会使用 GBK。

在 GBK 之前其实有一个更早的 GB2312 编码,这个编码字符集太小,经常乱码,才有了后面的 GBK,GBK 帮助解决了不少问题。

随之 WEB 环境的快速演进,目前项目中包括数据库通常都会使用 UTF-8 编码,包括数据库驱动之间也会使用 UTF-8。

其实很简单,如果你的项目就只是中国国内用用,你的字符集绝大部分是中文和英文,GBK 也差不多够用了。

如果要使用日文,韩文,德文,你怎么办。

页面 UTF-8,数据层 GBK,这里就要涉及到转码,这个是有代价的,其实也根本也没有什么必要,全部用 UTF-8 就行了。

还有就是文件的编码,如果文件编码是 GBK,用编辑器还得为 IDE 设置特定的字符集,不是闲着没事找事嘛,直接用 UTF-8,解决所有问题。

另外操作系统曾经也是不少问题,Unix 类似的系统基本上都是 UTF-8 的配置,你写的项目部署上去就是乱码,这不是闲着蛋疼。

另外 GBK 也不是最新的字符集了,如果非要用应该要使用 GB18030 字符集,这个字符集版本更新。

拿着 GBK 不想换的,基本上是老项目多,公司也不愿意折腾去维护,自己用户群基本上没有其他语言级的需求,另外也就上面懒得换而已。

 

有什么理由将代码保存为 GBK 编码_java

 

其实不仅仅是中文有这个问题,到目前还有很多英文项目还只使用 ISO 8859-1 字符集,这个字符集只能使用英文,不得不说如果选用这个字符集同样也是非常短视的行为。

都 2021 年,这个问题压根就不应该存在了,UTF-8 目前基本是项目的标配。

 

https://www.ossez.com/t/gbk/13661