最终，计算机制造商一起制定了一个标准的方法来描述字符。他们定义使用一个字节的低7位来表示字符，并且制作了如上图所示的对照表来映射七个比特的值到一个字符上。例如，字母A是65，c是99，~是126等等， ASCII码就这样诞生了。原始的ASCII标准定义了从0到127 的字符，这样正好能用七个比特表示。不过好景不长……
为什么选择了7个比特而不是8个来表示一个字符呢？我并不关心。但是一个字节是8个比特，这意味着1个比特并没有被使用，也就是从128到255的编码并没有被制定ASCII标准的人所规定，这些美国人对世界的其它地方一无所知甚至完全不关心。
其它国家的人趁这个机会开始使用128到255范围内的编码来表达自己语言中的字符。例如，144在阿拉伯人的ASCII码中是گ，而在俄罗斯的ASCII码中是ђ。即使在美国，对于未使用区域也有各种各样的利用。IBM PC就出现了“OEM 字体”或”扩展ASCII码”，为用户提供漂亮的图形文字来绘制文本框并支持一些欧洲字符，例如英镑（£）符号。
再强调一遍，ASCII码的问题在于尽管所有人都在0-127号字符的使用上达成了一致，但对于128-255号字符却有很多很多不同的解释。你必须告诉计算机使用哪种风格的ASCII码才能正确显示128-255号的字符。
这对于北美人和不列颠群岛的人来说不算什么问题，因为无论使用哪种风格的ASCII码，拉丁字母的显示都是一样的。英国人还需要面对的问题是原始的ASCII码中不包含英镑符号，但是这个已经无关紧要了。
与此同时，在亚洲有更让人头疼的问题。亚洲语言有更多的字符和字形需要被存储，一个字节已经不够用了。所以他们开始使用两个字节来存储字符，这被称作DBCS（双字节编码方案）。在DBCS中，字符串操作变得很蛋疼，你应该怎么做str++或str–？
这些问题成为了系统开发者的噩梦。例如，MS DOS必须支持所有风格的ASCII码，因为他们想把软件卖到其他国家去。他们提出了「内码表」这一概念。例如，你需要告诉DOS（通过使用”chcp”命令）你想使用保加利亚语的内码表，它才能显示保加利亚字母。内码表的更换会应用到整个系统。这对使用多种语言工作的人来说是一个问题，因为他们必须频繁的在几个内码表之间来回切换。
尽管内码表是一个好主意，但是它不是一个简洁的解决方案，它只是一个hack技术或者说是简单的修正来让编码系统可以工作。
进入Unicode的世界
最终，美国人意识到他们应该提出一种标准方案来展示世界上所有语言中的所有字符，以便缓解程序员的痛苦和避免字符编码引发的第三次世界大战。出于这个目的，Unicode诞生了。