所谓的“代码页地狱”：Unicode的意义是什么？

大凡同时使用中日文的人都碰到过一些麻烦的情况：从日本人手中得到的zip或者LZH文件，在中文系统上要么文件名是乱码，要么甚至根本无法解压缩（乱码在中文系统上变出了很多操作系统不允许的问号）；网上的Mp3 ID3信息，中日文系统间无法通用；就算使用内码转换，也会因为GB18030和ShiftJIS之间的不重复区段（如日文中的“・”、半角片假名和很大一部分ShiftJIS特殊符号，中文中的“你”等很多现代汉语常用字）而导致丢失文字。东亚国家的文字编码问题由来已久，它的原因是中国大陆、港台和日本、韩国在70-80年代各自开始使用互相不通用的多字节编码标准。
传统上，为每个区域分别制作的本地化版本操作系统都是默认使用这些互相不通用的编码标准，在这些系统上称作“代码页”。上面举出的这些典型例子，加上很多程序的错误，导致了文字内码大混乱，我称之为“代码页地狱”。
鉴于计算国际化的必然趋势，ISO组织在90年代初确定了统一编码和CJK统合汉字标准，简称为Unicode。这个标准在全世界的实现，是脱离“代码页地狱”的一种非常重要的手段。但是，各操作系统及相关计算元素原则上使用了Unicode标准，但实际上由于依靠代码页的旧软件实在太多，仍然使用了一个有全系统范围的“默认代码页”的代码转换器，这样，代码页地狱实际上没有真正消除。
拿腾讯QQ为例，这个每出一个新版就会强制禁止一些旧版的IM软件，就是个典型的依靠简体中文GB18030 代码页936的程序。这个程序在默认代码页为非936的Windows系统上运行，它的部分不是用Unicode编码的界面文字会全部变成乱码；它使用的通信协议中的文字传输，也不是Unicode，在默认代码页为非936的Windows系统上，在文字送到RichEdit控件时，也会被错误当作Unicode解码，同样全部变成乱码。而从此系统上通过QQ发出的文字，会被系统按系统代码页编码，到他人使用936代码页的系统上，也变成了乱码。而像Windows Live Messenger、Google Talk等IM软件，由于是完全Unicode化的，不会出现这种情况。
再拿音乐管理/iPod管理软件 iTunes 为例，它本身不管是在Mac OS X还是Windows上，都是个Unicode程序；但是，它管理的一类主要文件——MP3中的ID3信息却不总是这样。传统上，MP3文件的ID3信息很少使用Unicode编码，而使用代码页编码。在这些文件被导入iTunes/iPod时，信息在文件本身中并不会被转换为Unicode，而是保持原格式，只是在数据库中写入一个和当前系统（Windows或者Mac OS X）相同的代码页代码，无法自动以正确代码页显示。这样，代码页地狱再一次重现：在系统代码页为936时，导入GB18030编码的MP3文件，播放不会出现任何问题；但是导入ShiftJIS编码的MP3文件，乱码立即出现。将系统代码页改为932，播放ShiftJIS的那些文件完全正常，但是再播放Gb18030的那些，又变成了乱码。如果是在完全不支持东亚语言的英文代码页系统，问题将更为严重。解决这一问题的一个办法就是在正确的代码页下将文件转换为完全Unicode标签的MPEG-4 AAC格式，这样就不再受系统代码页影响；另一个是将MP3文件本身的ID3信息转换为Unicode，但是这样就不能在不支持Unicode的软件和设备（如大多数国内垃圾MP3）上正确显示。
为了应付这一情况，大多数现代系统自身都能切换代码页，甚至可以在应用程序宽度进行动态切换（如AppLocale工具）。但是这个问题要得到消除，唯一办法就是所有人都使用一种内码，使用Unicode。