JAVA平台中文编码问题讨论(上)-优快云博客

本文探讨了Unicode编码的起源及其解决的问题，并对比了ASCII、GB2312、GBK等编码标准。重点介绍了UTF-8的优点和局限。

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

最近准备在项目组内部准备一个Java平台中文编码问题的讨论，这是大纲的第一部分，第二部分正在准备中。。。。

1 Unicode及其他

1.1 编码由来

每个国家（或区域）都规定了计算机信息交换用的字符编码集，如美国的扩展 ASCII码。由于ASCII码不能满足中文的存储要求，因此中国在ASCII的基础上制订了gb2312码，之后又扩展成了GBK码。台湾为了应对同样的问题提出了BIG5码。与此同时，西欧国家为了实现拉丁字符的存储需求提出了ISO8859-1。

以上动作导致了所谓“本地系统”的产生，归根到底就是同样的字节数据在不同操作系统的电脑上表示成为不同的内容。一旦字节数据在特定的字符集内没有特定的对应字符，则会出现乱码。这就是乱码问题的由来。

为了解决以上的混乱局面，提出了Unicode编码。

1.2 Unicode编码

1.2.1 Unicode企图解决的问题

为了解决本地字符集混乱的问题，国际标准化组织提出了制订了Unicode编码，企图将世界上所有字符在一个字符集中全部包括，然后为每个字符进行编码。这样就可以一劳永逸的解决所有问题。

Unicode的实际情况是包含65535个字符，这个数字意味着世界上的很多字符，比如少数民族文字，康熙大辞典上的很多文字都没有被包含在Unicode字符集中。

1.2.2 Unicode的实际价值

Unicode实际并不能解决所有问题，因此很多软件、很多资料是在Unicode提出之前被开发出来，并且这些系统都运行良好。

Unicode的推广为世界范围内的其他编码之间的转换提供了一条“总线”。

1.2.3 为什么UTF-8

Unicode编码方式只是“看上去很美”，UTF-8为Unicode编码解决如下几个问题：

1. 采用变长的编码方式，所有ASCII编码都是一位的，降低了ASCII码的存储容量。

2. 与ASCII编码完全兼容。

3. 不会出现0x00，解决在C语言中0x00有特殊含义的问题。

4. 采用类似哈夫曼的编码方式，便于检查出错。

另外，如果使用UTF-8编码的话，即使中文系统也可以在英文操作系统上直接显示，如果使用GBK编码，英文操作系统会提示安装东亚语言包。

UTF-8不完美的地方：某些GBK码可能需要三个字节表示，加大的存储体积，降低了传输速度。

1.3 ASCII码（仅做了解）

目前计算机中用得最广泛的字符集及其编码，是由美国国家标准局(ANSI)制定的ASCII码（American Standard Code for Information Interchange，美国标准信息交换码），它已被国际标准化组织（ISO）定为国际标准，称为ISO 646标准。适用于所有拉丁文字字母，ASCII码有7位码和8位码两种形式。

注意：在计算机的存储单元中，一个ASCII码值占一个字节(8个二进制位)，其最高位(b7)用作奇偶校验位。所谓奇偶校验，是指在代码传送过程中用来检验是否出现错误的一种方法，一般分奇校验和偶校验两种。奇校验规定：正确的代码一个字节中1的个数必须是奇数，若非奇数，则在最高位b7添1；偶校验规定：正确的代码一个字节中1的个数必须是偶数，若非偶数，则在最高位b7添1。

1.4 GB2312，GBK码（仅做了解）

GB码，全称是GB2312-80《信息交换用汉字编码字符集基本集》，1980年发布，是中文信息处理的国家标准，在大陆及海外使用简体中文的地区（如新加坡等）是强制使用的唯一中文编码。P-Windows3.2和苹果OS就是以GB2312为基本汉字编码， Windows 95/98则以GBK为基本汉字编码、但兼容支持GB2312。GB码共收录6763个简体汉字、682个符号，其中汉字部分：一级字3755，以拼音排序，二级字3008，以偏旁排序。该标准的制定和应用为规范、推动中文信息化进程起了很大作用。