在所有字元集中，最知名的可能要数被称为ASCII的7位字元集了。它是美国标準信息交换代码（American Standard Code for Information Interchange）的缩写, 为美国英语通信所设计。它由128个字元组成，包括大小写字母、数字0-9、标点符号、非列印字元（换行符、制表符等4个）以及控制字元（退格、响铃等）组成。

但是，由于它是针对英语设计的，当处理带有音调标号（形如汉语的拼音）的亚洲文字时就会出现问题。因此，创建出了一些包括255个字元的由ASCII扩展的字元集。其中有一种通常被称为IBM字元集，它把值为128-255之间的字元用于画图和画线，以及一些特殊的欧洲字元。另一种8位字元集是ISO 8859-1Latin 1，也简称为ISOLatin-1。它把位于128-255之间的字元用于拉丁字母表中特殊语言字元的编码，也因此而得名。欧洲语言不是地球上的唯一语言，因此亚洲和非洲语言并不能被8位字元集所支持。仅汉语字母表（或pictograms）就有80000以上个字元。但是把汉语、日语和越南语的一些相似的字元结合起来，在不同的语言里，使不同的字元代表不同的字，这样只用2个位元组就可以编码地球上几乎所有地区的文字。因此，创建了UNICODE编码。它通过增加一个高位元组对ISO Latin-1字元集进行扩展，当这些高位元组位为0时，低位元组就是ISO Latin-1字元。UNICODE支持欧洲、非洲、中东、亚洲（包括统一标準的东亚象形汉字和韩国表音文字）。但是，UNICODE并没有提供对诸如Braille(盲文),Cherokee, Ethiopic(衣索比亚语), Khmer(高棉语), Mongolian(蒙古语), Hmong(苗语), Tai Lu, Tai Mau文字的支持。同时它也不支持如Ahom(阿霍姆语), Akkadian(阿卡德语), Aramaic(阿拉米语), Babylonian Cuneiform(古巴比伦楔形文字), Balti(巴尔蒂语), Brahmi(婆罗米文), Etruscan(伊特拉斯坎语), Hittite(西台语/西台语), Javanese(爪哇语), Numidian(努米底亚语), Old Persian Cuneiform(古波斯楔形文字), Syrian(叙利亚语)之类的古老文字。

事实证明，对可以用ASCII表示的字元使用UNICODE并不高效，因为UNICODE比ASCII占用大一倍的空间，而对ASCII来说高位元组的0对他毫无用处。为了解决这个问题，就出现了一些中间格式的字元集，他们被称为通用转换格式，即UTF（Unicode Transformation Format）。常见的UTF格式有：UTF-7, UTF-7.5, UTF-8,UTF-16, 以及 UTF-32。

如果UNICODE字元由2个位元组表示，则编码成UTF-8很可能需要3个位元组。而如果UNICODE字元由4个位元组表示，则编码成UTF-8可能需要6个位元组。用4个或6个位元组去编码一个UNICODE字元可能太多了，但很少会遇到那样的UNICODE字元。

UTF-8编码规则：如果只有一个位元组则其最高二进制位为0；如果是多位元组，其第一个位元组从最高位开始，连续的二进制位值为1的个数决定了其编码的位元组数，其余各位元组均以10开头。UTF-8转换表表示如下：

实际表示ASCII字元的UNICODE字元，将会编码成1个位元组，并且UTF-8表示与ASCII字元表示是一样的。所有其他的UNICODE字元转化成UTF-8将需要至少2个位元组。每个位元组由一个换码序列开始。第一个位元组由唯一的换码序列，由n位连续的1加一位0组成, 首位元组连续的1的个数表示字元编码所需的位元组数。

Unicode转换为UTF-8时，可以将Unicode二进制从低位往高位取出二进制数字，每次取6位，如上述的二进制就可以分别取出为如下示例所示的格式，前面按格式填补，不足8位用0填补。

注：Unicode转换为UTF-8需要的位元组数可以根据这个规则计算：如果Unicode小于0X80（Ascii字元），则转换后为1个位元组。否则转换后的位元组数为Unicode二进制位数+3再除以5。

示例

UNICODE uCA(1100 1010) 编码成UTF-8将需要2个位元组：

uCA -> C3 8A， 过程如下：

uCA(1100 1010)处于0080 ~07FF之间，从上文中的转换表可知对其编码需要2bytes，即两个位元组，其对 应 UTF-8格式为： 110X XXXX10XX XXXX。从此格式中可以看到，对其编码还需要11位，而uCA(1100 1010)仅有8位，这时需要在其二进制数前补0凑成11位: 000 1100 1010, 依次填入110X XXXX 10XX XXXX的空位中， 即得 1100 0011 1000 1010（C38A）。

同理，UNICODE uF03F (1111 0000 0011 1111) 编码成UTF-8将需要3个位元组:

u F03F -> EF 80 BF，对应格式为：1110XXXX10XX XXXX10XX XXXX，编码还需要16位，将1111 0000 0011 1111(F03F)依次填入，可得 1110 1111 1000 0000 1011 1111（EF 80 BF）。

UTF-8编码可以通过禁止位和移位操作快速读写。字元串比较时strcmp()和wcscmp()的返回结果相同，因此使排序变得更加容易。位元组FF和FE在UTF-8编码中永远不会出现，因此他们可以用来表明UTF-16或UTF-32文本（见BOM） UTF-8 是位元组顺序无关的。它的位元组顺序在所有系统中都是一样的，因此它实际上并不需要BOM。

你无法从UNICODE字元数判断出UTF-8文本的位元组数，因为UTF-8是一种变长编码它需要用2个位元组编码那些用扩展ASCII字元集只需1个位元组的字元 ISO Latin-1 是UNICODE的子集，但不是UTF-8的子集 8位字元的UTF-8编码会被email网关过滤，因为internet信息最初设计为7位ASCII码。因此产生了UTF-7编码。 UTF-8 在它的表示中使用值100xxxxx的几率超过50%， 而现存的实现如ISO 2022， 4873， 6429， 和8859系统，会把它错认为是C1 控制码。因此产生了UTF-7.5编码。

java使用UTF-16表示内部文本，并支持用于字元串串列化的非标準的修正UTF-8编码。标準UTF-8和修正的UTF-8有两点不同：

UTF-8保存使用

修正的UTF-8中，null字元编码成2个位元组（1100000010000000）而不是标準的1个位元组（00000000），这样做可以保证编码后的字元串中不会嵌入null字元。因此如果在类C语言中处理字元串，文本不会在第一个null字元时截断（C字元串以'\0'结尾）。

在标準UTF-8编码中，超出基本多语言範围（BMP-Basic Multilingual Plane）的字元被编码为4位元组格式，但是在修正的UTF-8编码中，他们由代理编码对（surrogatepairs）表示，然后这些代理编码对在序列中分别重新编码。结果标準UTF-8编码中需要4个位元组的字元，在修正后的UTF-8编码中将需要6个位元组。