云风的 BLOG: 一种对汉字更环保的 Unicode 编码方案

Windows 早期默认支持的中文编码方案是 GBK ，它是对早期 GB2312 的一个扩展。后来国家又发布了 GB18030 标准，扩展了 GBK ，增加了一些 Unicode 里才有的汉字，这样就可以做到和 Unicode 字符集做完全的映射了。

而后来 Unicode 逐渐成为标准，几乎所有的系统处理多国语言时，都把 Unicode 做为默认设置了。Unicode 有两套编码集，UCS-2 和 UCS-4 ，后者是对前者的补充，虽说字面说写的 4，但实际上只用到了 3 个字节不到。

Windows 的内部其实是用的 UCS-2 标准，并用 UTF-16 来实现。而非 Windows 系统大多采用了 UTF-8 。UTF-8 在很多情况下更有优势，首先它不需要考虑大头小头的问题，其次，数据损坏的时候，不会有半个汉字的问题。并且 UTF-8 可以完整的表达 UCS-4 而不需要有额外的付出。

前几年，处于 Windows 程序员转型期，经过一些痛苦的实践，我终于意识到，VC 提倡的所谓为软件维护 UNICODE 和非 UNICODE 两个版本是件巨傻 X 的事情。之后，我们的程序再也不为内码分版本了，一律采用 UTF-8 。

不过，UTF-8 的设计明显是用英文为主的西方人搞出来的东西。对于中文一点都不环保。所有汉字和中文标点都需要 3 个字节才能表达。而少量欧洲字母可以用 2 字节表达，英文的 ASCII 符号则可以只用单字节。

我不指责这个设计，因为兼容 ASCII 是 UTF-8 的最大优势。其它，则是 KISS 原则下的产物。

不过，若是内部使用的话，如果你介意这 1/3 的储存空间的浪费的话，是不是有改进的余地呢？下面我们来讨论这个问题。

观察 Unicode 的码表我们可以发现，实际大部分汉字是从 U+4E00 开始编码的，到 U+9FFF 结束。U+2000 到 U+3FFF 则有一些汉字标点符号等。稍加设计，我们可以定义出一种编码方案，对 UCS-2 或 UCS-4 做编码，让汉字可以用双字节表达，并保持对 ASCII 的兼容（U+0000 到 U+007F）段依然使用单字节。

作为牺牲，那些欧洲字母和韩文，就委屈到 3 字节甚至更长的编码了。

简述一下对 UCS-2 的编码方案（UCS-4 只需要做点小扩展）。

使用大头方案（Big-endian）
ASCII 部分 U+0000 到 U+007F 保留，用单字节 0x00 ~ 0x7f 表达。
对于 U+2000 到 U+9FFF ，除掉其中的 U+3F00 到 U+3FFF 部分（目前这个部分为空），做一个简单变换：即加上 0x6000 ，把编码转换到 0x8000 到 0xffff 部分。做双字节编码。由于 U+3F00 到 U+3FFFF 被除外（如果是 UCS-4 可以去除 U+3E00 到 U+3FFF），所以 0x9f 将成为一个 magic number 。
对于其它部分：U+0080 到 U+1FFF ，U+3F00 到 U+3FFF ，U+A000 到 U+FFFF ，一律编码到第 2 3 字节。并将第一字节直接设为 0x9F 。

这样，解码成 UCS-2 的算法非常简单（甚至不比 UTF-8 解码更复杂）。缺点是，缺乏 UTF-8 的容错性，有半个汉字的隐患。

这样的编码什么时候会有用？

网络传输时，对字符串做这样的编码（写一个 UTF-8 到这个特定编码方案的互转程序可以在 10 行 C 代码内完成，并非常高效），可以有效减少传输的数据。
如果需要做大规模的数据储存，比如搜索引擎抓取的网页时，可以节省不少储存空间。

至于源代码，和配置文件中，还是推荐使用 UTF-8 ，毕竟编辑器的支持更重要。

C 的实现见这里。

Comments

有点难理解

Posted by: 福利工口姬 | (38) April 16, 2014 04:23 PM

弱弱的问一下，为什么把汉字的那个部分要做转换。加上0x60。直接编码成两个字节不行吗

Posted by: daniel | (37) November 3, 2011 11:05 PM

每个算法都有其特定的应用背景，云风在22楼很好的解释了这一编码的应用情况。该冒泡的时候冒泡、该快排的时候快排、该桶排的时候桶排，没有一个万能的方案

Posted by: 桂林旅游 | (36) May 24, 2009 05:05 PM

我想你对UCS-2和UTF-16的定义搞错了，其实它们都是编码，在U+FFFD之前甚至是一模一样的。区别是UCS-2只是双字节，可容纳65534字符，UTF-16是双字节或者四字节，可以容纳更多字符。由于不支持超过U+FFFD的unicode，UCS-2已经被淘汰了，不过Windows使用的Unicode就是UCS-2。

Wikipedia下的解释：
UCS-2 (2-byte Universal Character Set) is an obsolete character encoding which is a predecessor to UTF-16. The UCS-2 encoding form is identical to that of UTF-16, except that it does not support surrogate pairs and therefore can only encode characters in the BMP range U+0000 through U+FFFF. As a consequence it is a fixed-length encoding that always encodes characters into a single 16-bit value. As with UTF-16, there are three related encoding schemes (UCS-2, UCS-2BE, UCS-2LE) that map characters to a specific byte sequence.

Because of the technical similarities and upwards compatibility from UCS-2 to UTF-16, the two encodings are often erroneously conflated and used as if interchangeable, so that strings encoded in UTF-16 are sometimes misidentified as being encoded in UCS-2.

Posted by: RedNax | (35) March 4, 2009 06:10 PM

哈 , magic number 那里是个 bug, 已经改过来了 :) 谢谢

Posted by: Cloud | (34) January 8, 2009 01:26 PM

发现一点小问题:

ASCII字符:
U+0000 .. U+007F 不变,单字节范围00..7F

汉字:
U+2000 .. U+2EFF 高位+60,首字节范围80..8E
U+3000 .. U+9FFF 高位+60,首字节范围90..FF

这里9F被90..FF覆盖了,
首字节可选的只有8F了.

Posted by: Samuel | (33) January 8, 2009 04:49 AM

题目写错了,应该是实现了一种转换格式(Unicode Translation Format)吧?
对于数据传递/保存来讲,汉字确实比较占空间(别拿MS的ansi格式说事哦):如果用UTF16,那纯英文文件就大了两倍(一位变成了两位),纯汉字大小不变;如果用UTF8,那纯汉字文件就多了一半空间(两位变成了三位),纯英文大小不变.这样一来作者的转换方案就实现了只要内容是汉字和英文组合,大小都保持不变了.
BTW:大家讨论的都对不上主题
1)UTF跟文本压缩根本就不是一回事,压缩总有效率问题,在高并发的时候服务器多了不少负担
2)如果是读入UTF8格式串,系统本身也是需要转换成unicode的;现在只是替换成用自己的转换来读取unicode,只不过同时为了通过用也提供了自己的格式跟utf8互相转换?

Posted by: Samuel | (32) January 8, 2009 02:10 AM

UCS 和 UTF 是不同的东西。

如果是为了容错且保持对 ascii 的兼容性，用 UTF-8 最好了。尤其在文件名等特定场合更是如此。

内存中的文本处理，我想，如果涉及中文比较多的情况下，UTF-16 最佳。以 ascii 为主时，UTF-8 更好。其它 UTF 方案都不适合放在内存的数据结构中。

所以，即使有特定的需求，设计新的 UTF ，也以方便转换到 UTF-16 或 UTF-8 为主要指导。

Posted by: Cloud | (31) January 6, 2009 02:01 AM

有点混乱。
既然说的是类似UCS-2的编码，那么自然是以16bit为单位进行的编码，又怎么会有让ASCII保持单字节，而某些区域用3个字节，这种东西？
如果说是以8bit为单位的编码，那么就不应该让ASCII的0值存在其中，因为这样的串很多8bit的系统并不支持，比如C语言里ASIIZ字符串，是以0值为结尾的，这种字节串就难以表达。此外低字节也有很多码值属于控制字符，也是一般8bit软件忌讳的，比如文件名等场合，都不合适。

我之前有过类似设想的文章，让汉字变为2个字节。参见：
http://www.pkucn.com/viewthread.php?tid=164480

Posted by: 桂林旅游 | (30) January 6, 2009 12:15 AM

Posted by: Anonymous | (29) December 26, 2008 10:41 AM

我认为使用压缩技术，比新搞个编码更KISS。

Posted by: Sutra | (28) December 25, 2008 11:55 PM

GB18030就是一种UTF啊，何必自己发明？

Posted by: Anonymous | (27) December 25, 2008 11:31 PM

嗯，这样的编码对上层应用基本是透明，也谈不到什么兼容性的问题。在一些嵌入式设备上看到过类似的解决方案。

Posted by: Bennie | (26) December 25, 2008 11:51 AM

题目误导了

也许应该改成“一种对汉字更环保的文本流编码方案”

Posted by: black | (25) December 25, 2008 02:13 AM

@微子

UTF 和 UCS 是不同层面的东西，Unicode (指 UCS) 本身并不描述具体编码方案。

所以不存在所谓 UTF 到 Unicode 的转换表。（没有也不需要这样的一张表）

握手协议是另一件事，跟我前面回复说的 ip 包头等是一件事。

如果网游的例子不合适的话，可以考虑各种 RPC 协议。即高频交互的长连接上的通讯数据。

Posted by: Cloud | (24) December 24, 2008 06:44 PM

看来我曲解了你的中心意思, 但仍然解释一下.

一段较长信息流的最优压缩是Huffman编码(与熵, 本质都是排序不等式). 几百千字节以上的文件其压缩大小不太依赖于编码. 但小文件及传输确实有影响. 不过, 小的很的话, 怀疑握手协议流就比文件大了.

你可以写一个 UTF-C 到Unicode的转换表, 生成 locale数据, 然后编辑器什么的就可以用了.

Posted by: 微子 | (23) December 24, 2008 06:24 PM

虽然我不太愿意局限在数据压缩层面讨论这个问题。不过既然谈到了，可以说说实际的功用。

比如在网游里，采用 RPC (也可以不是 RPC) 通讯。

网游的包的特点是短小，高频。可能每个连接每次就发一个短字符串，姑且假设有 4 个汉字。那么，UTF-8 编码就是 12 字节。如果我们换种编码，可能就是 8 字节。

但这种短小的包是不能用通用算法压缩的。btw, 关于这个方面的讨论，我曾经也写过一篇 blog : 基于TCP数据流的压缩 http://blog.codingnow.com/2006/01/tcp_stream_compress.html

目前用在大话服务器里。

对于一个连接来说，少了 4 个字节没什么。但是一台服务器同时可能要处理 1000 ~ 10000 个连接。这样带宽就不一样了。

当然，我们没有讨论关于 ip 包封装等等问题。只是指理论带宽消耗。

对于标准压缩算法, 也有 CPU 消耗的问题，内存占用问题等等。

把问题局限在压缩数据方面不是我的本意，也不用在这方面多纠结。

我是想说，UCS 是 UCS , UTF 是 UTF 。可以有 UTF-8 也可以用 UTF-C (UTF-C 我生造的词, 表示对 C 中文的优化）。

特定的 UCS Transformation Format 在特定的场合有自己的优势。这跟压缩数据是两个层次的问题。用了特定的 UTF 并不妨碍继续用数据压缩。

关于实现，我想不超过 10 行 C 代码就可以完成了。只需要大学本科毕业，学习过 1 年 C 语言编程的学生就可以。而且可以保证没有错误。当然，对于已经不再写算法实现的程序员或者"构架师"来说可能有畏惧感。这些人或许写 UTF-8 解码的程序都难以一次写对，必须求助于 google 或开源社区寻求现成的代码。

抛开实现层来说，这是个相对基础的底层工作。好比你有了一个 XML 解析库，工作在上面就可以了。不需要每个人都去解析 XML 。

Posted by: Cloud | (22) December 24, 2008 05:30 PM

云哥的这个建议非常不妥。假如为压缩网络传输数据量，直接压缩就行了，并具有最高的兼容性，假如做为Doc，可被识别最重要，也就是说，可以把9f提案做为建议标准，直到被标准采纳前，依然不应该提倡这样的用法——百害无一利的。

Posted by: AleTiff | (21) December 24, 2008 04:37 PM

又仔细看了一下回复。似乎楼主的目的是减少网络传送时的数据量。

我觉得文章的切入点有些问题：应该是在网络传输层上叠加一个针对特定字符编码的压缩协议，而不是新建一个新的字符编码。这样的话，这种编码就应该仅仅存在于传输层面，用户的输入和输出还是符合标准utf8编码的。

Posted by: Googol | (20) December 24, 2008 04:09 PM

不认同这种方法，太麻烦了。估计加一层gzip或者lzw的压缩算法就能达到比这个效果好的压缩率。

最关键的问题，utf8是通用的，而这种格式除了自己写的程序，别人谁也不认识。

Posted by: Googol | (19) December 24, 2008 04:01 PM

未必有什么意义。

计算机的存储设备、网络带宽的价格只会越来越便宜，跟上证指数差不多。但是，不变的、昂贵的仍然是人力资源成本。

设计出这么一套编码方案，当其他人继续开发时，需要额外的培训（花钱）、额外的代码（更花钱，想想平均一行代码所花的费用是多少）、额外的测试（花钱。不仅是功能，还有兼容性）......而且，每新来一个员工都得接受额外的培训，花更多的时间熟练，才能应用，这花的钱可不一般多。而老员工一离职，已经投入的钱也就扔到水里去了。

与其这样，不如继续用那些成熟的方案吧，至少，一般的程序员不需要培训，也能写出适合那些成熟方案的代码；测试也更容易。这样省下的钱或许比少买几块硬盘、内存或者少用几K带宽省下的钱要多多了。

Posted by: Slash | (18) December 24, 2008 03:21 PM

竟然在cnbeta网站看到你的文章了哦

http://www.cnbeta.com/articles/73166.htm

Posted by: smallfish | (17) December 24, 2008 03:20 PM

Merry christmas!
我订阅了云风的博客，好方便哦，及时看到最新文章

Posted by: 星际工作室 | (16) December 24, 2008 03:04 PM

这样的话可以减少1/3的文字传输量了.

Posted by: cat | (15) December 24, 2008 02:48 PM

要弄清楚 UCS 和 UTF 的区别。文本压缩和 Transformation Format 的区别。

Unicode 定义的是数字和字符的对应关系，如何数字信息如何编码成字节是另一个层次的故事。

GB18030 和 Unicode 是不同的编码。