身为一个中文计算机使用者，我有过太多的无奈，这些无奈是西方人无法体会的。大多数知名的编程语言、操作系统、应用软件，都是西方人开发的，他们往往一开始的时候不会把中日韩（CJK）的语言需求当一回事。
操作系统
二十多年前，为了要让计算机具有快速的「正体」中文环境，每次开机后都必须插入中文磁盘，花一段时间安装倚天中文（或大千、零壹、天龙中文），而且都是16 或24的点阵字型（bitmap font），只要把字放大，就其丑无比。为了要加速中文的加载与显示，必须安装超贵的倚天汉卡，而早期的倚天汉卡只能使用在单色模式。当时，欧美的电 脑使用者，根本不需要这么麻烦，人家开机后就可以直接用计算机了，令我们感到羡慕。
后来Windows 3.x时代，可以方便地使用中文，但是文件名称不能使用中文，进入Windows 95之后才解除此限制，微软平台上的中文问题也渐渐变得比较少了。但其它平台还是存在这个问题，Linux一开始不支持双位语言，BeOS也不支持中 文，我们必须用一些奇门遁甲的方式，辛苦地让这些OS上面显示中文。当中文显示出来的剎那，感动得都快掉泪了。
正体中文的编码最常用的是Big-5，这是一种双字节字符集（Double-Byte Character Set，DBCS），但是不同平台的Big-5字集还不太一样。当我把在Windows平台上写好的文章交给MacOS的排版人员，最后一定要仔细校对排 版后的输出。因为两者的Big-5字集有些小差异，所以有些中文字可能会不一样。
编程语言
经过这段时间大家的努力，现在，至少主流的OS都不会有中文的问题了。但是程序环境可不见得如此，正体中文版Windows上使用CP950编 码，这是混合Big-5和ASCII的变动长度编码方式。对于这种变动长度的编码方式，如果程序环境没有特别处理，常常会发生问题。著名的「许、功、盖」 问题就是如此，这几个中文字的第二个字节都是ASCII的反斜线（\），刚好是某些程序语言的特殊字符，或者脱字序列（Escape Sequence）字符，所以会出现问题，根据这样来推估，还有相当多字都会出问题，包括「厩、琵、崤、泪、豹」。
不同的程序环境可能会有不同的特殊字符。甲语言出问题的可能是「许、功、盖」，乙语言出问题的可能是「扁、夏、抬」，所以每个语言必须用不同的方式处理特殊字符的问题。
幸好我们开始有Unicode，早期的Unicode是16位的，后来又扩充到32位。许多号称支持Unicode的平台，其实并没有 100%支持Unicode。至少在Windows上，当我测试Unicode的中文组字功能时，发现是行不通的。例如：「2FF1 4E95 86D9」无法呈现正确组合出来的1个中文字，而是3个中文字。这是因为Windows API的TextOut() 函式与DrawText() 函式（以及相关函式）没有处理中文组字。
Java虽然一开始就支持Unicode，但是前几年在AWT/Swing上显示的中文很不美观，程序设计上也会遇到一些问题。我就常常收到读 者的E-mail，询问如何在Java上解决特定的中文问题。这几年下来，这些问题似乎在Java上都已经渐渐消失了。.NET平台上的语言对于DBCS 与Unicode的支持也不错。但是Java和.NET毕竟都是跨国大公司的产品，所以有考虑到DBCS与Unicode，是很自然的。Ruby就比较特 别了，由于Ruby是日本人设计的编程语言，所以Ruby一开始就有考虑到东亚的语言。
应用软件与中文乱码
平台有支持中文，编程语言兼容于中文，但开发出来的应用程序却不见得如此，所以有的应用程序只要遇到中文，一律变成乱码，但是这样的例子已经越来越少了。
之所以会看到乱码，就是「编码」和「译码」的方式不同所造成的。比方说，用DBCS的中文编码，却用ASCII译码，把每个中文字当作两个「扩充ASCII」字符显示；或者，把简体中文GB2312编码的内容，当作正体中文Big-5译码显示，当然会看到不知所云的内容。
就算程序支持多种编码，也会因为收到的内容没有标示编码，而造成译码错误。我的Office 2003收件匣，只要收到简体中文标题的邮件，标题就会呈现乱码。没想到几个月后，我养成一种功力，我可以从邮件标题的中文乱码解读出简体中文一些常用词 汇。比方说，当我看到邮件标题为「绊珂汜斓疑」，我就知道其实这几个正体中文字编码对应到简体中文是「蔡先生你好」。我考虑把这项了不起的「阅读乱码」华加入我的履历表中。
蔡学镛－专职作家
清华大学资讯工程硕士，曾任华硕集团软件工程师、元智大学信息系讲师、美商欧莱礼出版社技术编辑、台湾微软特约专栏作家,程序员杂志专栏作家。