原文地址：http://www.joelonsoftware.com/articles/Unicode.html
作者：Joel Spolsky
译文：http://local.joelonsoftware.com/wiki/Talk:Chinese_(Simplified)
你曾经是否觉得HTML中的"Content-Type"标签充满神秘？虽然你知道这个东西必须出现在HTML中，但对于它到底干吗你可能一无所知。
你是否曾经收到过来自你保加利亚朋友的邮件，到处都是"???? ?????? ??? ????"?
我很失望，因为我发现许多软件开发人员到现在为止都还没有对字符集、编码、Unicode有一个清晰的认识，这是个事实。几年前，在测试FogBUGZ项目时，忽然想看看它能不能接收用日文写的电子邮件。这个世界上会有人用日文写电子邮件？我不知道。测试结果很糟糕。我仔细看了用来解析MIME (Multipurpose Internet Mail Extenisons)格式的邮件所用的ActiveX控件，发现了它在字符集上面做的蠢事。于是我们不得不重新写一段代码，先消除Active控件的错误，然后再完成正确的转换。类似的事情在我研究另一个商业库的时候同样发生了，这个库关于字符编码这部分的实现简直糟透了。我找到它的开发者，把存在问题的包指给他，他却表示对于此无能为力。像很多程序员一样，他只希望这个缺陷会被人们遗忘。
事实并非如他所愿。因为我发现，像PHP这么流行的网页开发工具，竟然在实现上也完全忽略了多种字符编码的存在（译者注：这篇文章写于2003年，现在的 PHP可能已经纠正了这个问题吧），盲目地只使用8个比特来表示字符，于是开发优秀的国际化的Web应用程序变成了一场梦。我想说，受够了。
我申明：在2003年，如果你是一个程序员，但你却对字符、字符集、编码和Unicode一无所知，那么你别让我抓到你。如果落在我手里，我会让你待在潜水艇里剥六个月的洋葱，我发誓。
另外，还有一件事：
在这篇文章里，我所讲的是每一个工作中的程序员都应该知道的知识。所有以为"纯文本 = ASCII码 = 一个字符就是8比特"的人不单单错了，而且错得离谱。如果你仍然坚持使用这种方式编写程序，那么你比一个不相信细菌的存在医生好不到哪里去。所以在你读完这篇文章以前，不要再写半行代码。
在我开始之前，必须说明白，如果你已经了解了国际化，可能你会觉得这篇文章过于简单。没错，我的的确确是想架一座最短的桥，让任何人都可以理解发生了什么事，懂得如何写出可以在非英文语言环境是正常工作的代码。还得指出，字符处理仅仅是软件国际化中的一小部分，但一口吃不成个胖子，今天我们只看什么是字符集。
可能你以为我要开始谈非常古老的字符集如EBCDIC之类的，实际上我不会。EBCDIC与你的生活无关，我们不需要回到那么远。
回到一般远就行了。当Unix刚出来的时候，K&R写了《The C Programming Language》一书，那时一切都很简单。EBCDIC已经惭惭不用，因为需要表示的字符只有那些不带重音的英文字母，ASCII完全可以胜任。ASCII使用数字32到 127来表示所有的英文字母，比如空格是32，字母"A"是65等等。使用7个比特就可以存储所有这样字符。那个时代的大多数计算机使用8个比特来，所以你不但可以存储全部的ASCII，而且还有一个比特可以多出来用作其他。如果你想，你可以把它用作你不可告人的目的。32以下的码字是不可打印的，它们属于控制字符，像7表示响铃，12表示打印机换纸。
所有的一切都看起来那么完美，当然前提你生在一个讲英文的国家。
因为一个字节有8个比特，而现在只用了7个，于是很多人就想到"对呀，我们可以使用128-255的码字来表示其他东西"。麻烦来了，这么多人同时出现了这样的想法，而且将之付诸实践。于是IBM-PC上多了一个叫OEM字符集的东西，它包括了一些在欧洲语言中用到的重音字符，还有一些画图的字符，比如水平线、垂直线等，水平线在右端会带一个小弯钩，垂直线会如何等等。使用这些画图字符你可以画出漂亮的框、画出光滑的线条，在老式的烘干机上的8088电脑上你依然可以看到这些字符。事实上，当PC在美国之外的地方开始销售的时候，OEM字符集就完全乱套了，所有的厂商都开始按照自己的方式使用高128个码字。比如在有些PC上，130表示é，而在另外一些在以色列出售的计算机上，它可能表示的是希伯来字母ג，所以当美国人把包含résumés这样字符的邮件发到以色列时，就为变为rגsumגs。在大多数情况下，比如俄语中，高128个码字可能用作其他更多的用途，那么你如何保证俄语文档的可靠性呢？
最终ANSI标准结束了这种混乱。在标准中，对于低128个码字大家都无异议，差不多就是ASCII了，但对于高128个码字，根据你所在地的不同，会有不同的处理方式。我们称这样相异的编码系统为码页(code pages)。举个例子，比如在以色列发布的DOS中使用的码页是862，而在希腊使用的是737。它们的低128个完全相同，但从128往上，就有了很大差别。MS-DOS的国际版有很多这样的码页，涵盖了从英语到冰岛语各种语言，甚至还有一些"多语言"码页。但是还得说，如果想让希伯来语和希腊语在同一台计算机上和平共处，基本上没有可能。除非你自己写程序，程序中的显示部分直接使用位图。因为希伯来语对高128个码字的解释与希腊语压根不同。
同时，在亚洲，更疯狂的事情正在上演。因为亚洲的字母系统中要上千个字母，8个比特无论如何也是满足不了的。一般的解决方案就是使用DBCS- "双字节字符集"，即有的字母使用一个字节来表示，有的使用两个字节。所以处理字符串时，指针移动到下一个字符比较容易，但移动到上一个字符就变得非常危险了。于是s++或s--不再被鼓励使用，相应的比如Windows下的AnsiNext和AnsiPrev被用来处理这种情况。
可惜，不少人依然坚信一个字节就是一个字符，一个字符就是8个比特。当然，如果你从来都没有试着把一个字符串从一台计算机移到另一台计算机，或者你不用说除英文以外的另一种语言，那么你的坚信不会出问题。但是互联网出现让字符串在计算机间移动变得非常普遍，于是所有的混乱都爆发了。非常幸运，Unicode适时而生。
延伸阅读:
影响ORACLE汉字显示的字符集问题
小谈MySQL字符集
Mysql中校对集utf8_unicode_ci与utf8_general_ci的区别
Google：Unicode(UTF-8)征服ASCII 成互联网最常用编码
讲解MySQL数据库字符集出错的解决方法
ANSI，Unicode，UTF-8网页编码的区别
PHP获取汉字unicode码函数