• 有什么理由将代码保存为 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

  • 相关阅读:
    Hierarchy Query (Connect by) and ORA600 ([kkqcbydrv:1])
    The Steps to Create a New Oracle Database
    Change Schema Name (II)
    [转]The differences between V$UNDOSTAT and V$ROLLSTAT
    【Oracle Mgmt】Oracle Character Semantics (NLS_LENGTH_SEMANTICS) and etc...
    [Oracle Mgmt]About Oracle Password File
    Show parameter & Table Not exists
    RMAN Recovery Window and Redundancy Concept
    [PLSQL]Are you sure it will be definitely random? (DBMS_RANDOM.SEED)
    IOT, Secondary Index and Mapping Table
  • 原文地址:https://www.cnblogs.com/huyuchengus/p/15120780.html
Copyright © 2020-2023  润新知