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

针对这个问题的短回答就是：没有任何理由保存代码为 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 不想换的，基本上是老项目多，公司也不愿意折腾去维护，自己用户群基本上没有其他语言级的需求，另外也就上面懒得换而已。

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

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

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