编码
编码是信息从一种形式或格式转换为另一种形式的过程。解码，是编码的逆过程。
[编辑]扩展定义
对于特定的上下文，编码有一些更具体的意义。
编码(Encoding)在认知上是解释传入的刺激的一种基本知觉的过程。技术上来说，这是一个复杂的、多阶段的转换过程，从较为客观的感觉输入（例如光、声）到主观上有意义的体验。
字符编码(Character encoding)是一套法则，使用该法则能够对自然语言的字符的一个集合（如字母表或音节表），与其他东西的一个集合（如号码或电脉冲）进行配对。
文字编码(Text encoding)使用一种标记语言来标记一篇文字的结构和其他特征，以方便计算机进行处理。
语义编码(Semantics encoding)，以正式语言乙对正式语言甲进行语义编码，即是使用语言乙表达语言甲所有的词汇（如程序或说明）的一种方法。
电子编码(Electronic encoding)是将一个信号转换成为一个代码，这种代码是被优化过的以利于传输或存储。转换工作通常由一个编解码器完成。
神经编码(Neural encoding)是指信息在神经元中被如何描绘的方法。
记忆编码(Memory encoding)是把感觉转换成记忆的过程。
加密(Encryption)是为了保密而对信息进行转换的过程。
译码(Transcoding)是将编码从一种格式转换到另一种格式的过程。
－－－－－－－－－－－－－－－
字符集
字符集，或称字集，是指文字的集合；将固定数目的文字编序，以方便作通讯、教育、资讯处理等用途。
字符集通常有两种，一是专为电脑资讯处理而设，如：ASCII、Unicode、GB 2312、大五码(Big5)、CNS 11643等。一是作其他用途的，如教育用的生字表、通讯用的电报码等。
字符集和编码(Encoding)不同。字符集只是文字的集合，不一定适合作网络传送、处理，有时须经编码(Encode)，将字元对应至所属的特定二元表示法后，才能应用。如CNS 11643和GB 2312可以使用ISO/IEC 2022、EUC等标准编码。Unicode可依不同需要以UTF-8、UTF-16、UTF-32等方法编码。有些字符集如Big5通常不须额外编码即可使用，故Big5既是字符集又是编码。
[编辑]常用电脑字符集
ASCII
ISO/IEC 10646/Unicode
GB 2312
GBK
GB 18030
Big5
香港增补字符集（HKSCS，是Big5的扩充版本）
国家标准中文交换码 (CNS 11643)
CCCII
JIS X 0201（半角日语假名）
JIS X 0208（日语汉字字集，可以使用ISO/IEC 2022、Shift_JIS或EUC编码）
ISO/IEC 8859
[编辑]常用教育、出版、特殊用途字符集
中国大陆
现代汉语常用字表
现代汉语通用字表
台湾
常用国字标准字体表
次常用国字标准字体表
香港
常用字字形表
日本
常用汉字
当用汉字
教育汉字
人名用汉字
[编辑]常用通讯用字符集
中文电码
[编辑]另见
－－－－－－－－－－－－－
字符编码
字符编码(Character encoding)、字集码或字符集由编码组成，编码使得某一字符序列匹配于一指定集合中某一东西，例如可能显示为一种自然数序列，交流所用的字母表或者字音表）到一个给定的集合中的其它东西，如一个自然数序列、8位字节或者电脉冲，以便于文本在计算机中存储和通过通信网络的发送。常见的例子包括将拉丁字母表编码成一些列长短发报电键的摩斯电码和ASCII，ASCII将字母、数字和其它符号(编码方式)编码成整数和用7位二进制表示的这个整数，通常使用另外一个扩充的0位以便于用8位字节存储。
在计算机技术发展的早期，诸如ASCII（1963年）和EBCDIC（1964年）这样字符集的引入开始成为标准化的过程。这些字符集的局限很快就变得很明显，于是人们开发了许多临时的方法来扩展它们。对于支持包括东亚CJK字符家族在内的多用写作系统的需求要求支持更大量的字符，并且需要一种系统而不是临时的方法实现这些字符的编码。
目录 [隐藏]
1 简单字符集
2 现代编码模型
3 字符编码历史
4 流行的字符编码
5 字符转换工具
6 参见
7 外部连接
[编辑]简单字符集
按照惯例人们认为字符集和字符编码是同义词，因为使用同样的标准来定义提供什么字符并且这些字符如何编码到一系列的代码单元（通常一个字符一个单元）。由于历史的原因，MIME和使用这种编码的系统使用术语字符集来表示用于将一组字符编码成一系列八位字节数据的整个系统。
[编辑]现代编码模型
一起构成多数现代字符编码模型的Unicode和它的对应标准ISO/IEC 10646 通用字符集没有遵从这种观点，相反它们将字符编码思想分为：有什么字符、它们的编号、这些编号如何编码成一系列的“码元”（有限大小的数字）以及最后这些单元如何编码位8位字节流。这个分解所用的思想是建立一个能够用不同方法编码的一个通用字符集。为了正确地表示这个模型需要更多比“字符集”和“字符编码”更为精确的术语表示。现代模型中所用的术语列在下面：
字符表(Character Set)是一个系统支持的所有抽象字符的总和。字符表可以是封闭的，也就是说不允许添加新的符号，除非创建一个新的标准（ASCII和多数ISO/IEC 8859系列都是这样的例子）；字符表也可以是开放的，允许添加新的符号（Unicode和一定程度上视窗代码页是这方面的例子）。特定字符表中的字符反映了如何将书写系统分解成线性信息单元的决定。例如拉丁、希腊和斯拉夫字母表自然分为字母、数字、变音符号、标点和如空格这样一些少数特殊字符，它们都能按照一种简单的线性序列排列（尽管对它们的处理需要另外的规则，如带有变音符号的字母这样的特定序列如何解释——但这不属于字符表的范畴）。为方便起见，这样的字符表可以包括预先编号的字母和变音符号的组合。其它的书写系统，如阿拉伯语和希伯莱语，由于要适应双向文字和在不同情形下按照不同方式交叉在一起的字形，就使用更为复杂的符号表表示。
编码字符集(CCS:Coded Character Set)定义了如何使用称为码点的非负整数表示一个字符表。例如，在一个给定的字符表中，表示大写拉丁字母“A”的字符被赋予整数65、字符“B”是66，如此继续下去。一个完整的字符集和对应的整数一起称为“编码字符集”。多个编码字符集可以表示同样的字符表，例如ISO-8859-1和IBM的代码页037和500覆盖同样的字符表但是将它们映射为不同的代码。在一个编码字符集中，每个码点仅仅表示一个字符。
字符编码形式（CEF:Character Encoding Form）定义将编码字符集的整数代码转换成有限大小整数代码值以有利于使用固定位的二进制表示数字的形式（比如，几乎任何的计算机系统）的系统存储。例如，使用16位单元存储数字信息的系统每个单元只能够直接表示从0到65,536的数值，但是如果使用多个16位单元就能够表示更大的整数。这就是CEF的作用：它定义一种从0到140万的范围的单个 码点映射到一些列列的范围在0到65,5356的单个或多个 码值的方法。
最简单的CEF系统就是简单地选择足够大的单位以保证编码字符集中的所有数值能够直接编码（一个码点对应一个码值）。这对于能够用8位表示的编码字符集（如多数传统的非CJK编码所作的那样）是合理的，对于能够使用16位表示的编码字符集（如早期的Unicode版本）来说也足够合理。但是，随着编码字符集的大小增加（例如，现代Unicode每个字符至少需要21位），这变得越来越没有效率，并且很难让现有系统适应更大的码值。因此，许多使用Unicode后来新近版本的系统或者使用将Unicode码点映射位变长8位字节序列的UTF-8，或者使用将码点映射为变长16位字的UTF-16。
字符编码机制（CES:Character Encoding Scheme）定义固定大小的整数代码如何映射到适合基于8位字节数据的文件系统存储或者基于8位字节网络传输。在多数使用Unicode的场合，一个简单的字符编码机制用来指定每个整数的字节顺序是大字节在先排列顺序或者小字节在先排列顺序（即使对于UTF-8来说并不需要这些）。然而，有些复杂的字符编码机制使用转义序列在几种简单编码机制（如ISO/IEC 2022）和用于减小每个单元所用字节数的压缩机制（如SCSU、BOCU和Punycode）之间切换。
[编辑]字符编码历史
[编辑]字符转换工具
linux:
utrac - 将整个文件内容从一种字符编码转换到另外一种 ()
convmv - 将文件名从一种字符编码转到另外一种 ()
[编辑]参见
-------------------
ASCII
维基百科，自由的百科全书
ASCII（American Standard Code for Information Interchange，美国信息互换标准代码）是基于拉丁字母的一套电脑编码系统。它主要用于显示现代英语和其他西欧语言。它是现今最通用的单字节编码系统，并等同于国际标准ISO/IEC 646。
ASCII第一次以规范标准的型态发表是在1967年，最后一次更新则是在1986年，至今为止共定义了128个字元，其中33个字元无法显示（这是以现今作业系统为依归，但在DOS模式下可显示出一些诸如笑脸、扑克牌花式等8-bit符号），且这33个字元多数都已是陈废的控制字元，控制字元的用途主要是用来操控已经处理过的文字，在33个字元之外的是95个可显示的字元，包含用键盘敲下空白键所产生的空白字元也算1个可显示字元（显示为空白）。
--------------------
通用字符集
维基百科，自由的百科全书
通用字符集（Universal Character Set，UCS）是由ISO制定的ISO 10646（或称ISO/IEC 10646）标准所定义的字符编码方式，采用4字节编码。
通用字符集又称Universal Multiple-Octet Coded Character Set，中国大陆译为通用多八位编码字符集，台湾译为广用多八位元编码字元集。
--------------------
Unicode
维基百科，自由的百科全书
在电脑科学领域中，Unicode（统一码、万国码、单一码、标准万国码）是业界的一种标准，它可以使电脑得以呈现世界上数十种文字的系统。Unicode 是基于通用字元集（Universal Character Set）的标准来发展，并且同时也以书本的形式（The Unicode Standard，目前第五版由Addison-Wesley Professional出版，ISBN-10: 0321480910）对外发表。Unicode包含了超过十万个字符（在2005年，Unicode的第十万个字元被采纳且认可成为标准之一）、一组可用以作为视觉参考的代码图表、一套编码方法与一组标准字元编码、一套包含了上标字、下标字等字元特性的列举等。
Unicode组织（The Unicode Consortium）是由一个非营利性的机构所运作，并主导Unicode的后续发展，其目标在于：将既有的字元编码方案，以 Unicode0编码方案来加以取代，特别是既有的方案在多语环境下，皆仅有有限的空间以及不相容的问题。
Unicode在字元集认可的成功，使其得以在电脑软体的国际化与本地化领域中，广泛且具优势的被采用。这标准已在近年来的多种新科技当中被加以采用，包含了可扩展置标语言（XML）、Java程式语言、以及最新的作业系统中。
-----起源与发展
Unicode是由于传统的字元编码方式的局限性而产生的，例如 ISO 8859 所定义的字元虽然在不同的国家中广泛地使用，可是在不同国家间却经常出现不相容的情况。很多传统的编码方式都具有一个共通的问题，即其容许电脑进行双语环境式的处理（通常使用拉丁字母以及其本地语言），但却无法同时支援多语言环境式的处理（指可同时处理混合多种语言的情况）。
Unicode试图将字位（字素，graphemes）与类字位字元加以认定与编码，而非以不同的字形（glyphs）来加以区分。然而在汉字的个案来看，这样方式有时会引起一字多形的认定争议（详见中日韩统一表意文字主题）。
在文字处理方面，Unicode的功用是为每一个字元提供一个唯一的代码（即一组数字），而不是一种字形。换句话说，Unicode是将字元以一种抽象的方式来呈现，而将视觉上的演绎工作（例如字体大小、外观形状、字体形态、文体等）留给其他软件来处理，例如网页浏览器或是文字处理器。
为了使Unicode与已存在和广泛使用的旧有编码互相兼容，尤其是差不多所有电脑系统都支援的基本拉丁字母部分，所以Unicode 的首256字元仍旧保留给ISO 8859-1 所定义的字元}}，使既有的西欧语系文字的转换不需特别考量；另方面因相同的原因，Unicode 把大量相同的字元重复编到不同的字元码中去，使得旧有纷杂的编码方式得以和 Unicode 编码间互相直接转换，而不会遗失任何资讯。举例来说，全形格式区段包含了主要的拉丁字母的全形格式，在中文、日文、以及韩文字形当中，这些字元以全形的方式来呈现，而不以常见的半形形式显示，这对竖排文字和等宽排列文字有重要作用。
在表达一个 Unicode 的字元时，通常会用“U+”然后紧接着一组十六进位的数字来表示这一个字元。在基本多文种平面（Basic Multilingual Plane，简称 BMP）里的所有字元，只要使用四位十六进制数（例如 U+4AE0，共支持六万多个字符）来表示，但在 BMP 以外的字元则需要使用五位或六位十六进制数了。旧版的 Unicode 标准使用相近的标记方法，但却有些微的差异，例如在 Unicode 3.0 里使用“U-”然后紧接着八位数，而“U+”则必须随后紧接着四位数，以表示仅限于代表一个字元单位（code unit），而非字元（code point）。
------标准
位于美国加州的 Unicode 组织允许任何愿意支付会员费用的公司或是个人加入，其成员包含了主要的电脑软硬体厂商，例如奥多比系统（Adobe Systems）、苹果公司（Apple）、惠普（HP）、IBM、微软（Microsoft）、全录/施乐（Xerox）等。
Unicode 组织在 1991 年首次发布了 The Unicode Standard（ISBN 0-321-18578-1）。 Unicode 的开发结合了国际标准化组织（International Organization for Standardization，简称 ISO）所制定的ISO/IEC 10646，即通用字元集（Universal Character Set，简称 UCS）。Unicode 与 ISO/IEC 10646 在编码的运作原理相同，但 The Unicode Standard 包含了更详尽的实现资讯、涵盖了更细节的主题，诸如字元编码（bitwise encoding）、校对以及呈现等。 The Unicode Standard 也列举了诸多的字元特性，包含了那些必须支援双方向呈现的文字（由左至右或由右至左的文字呈现方向，例如阿拉伯文是由右至左）。 Unicode 与 ISO/IEC 10646 两个标准在术语上的使用有些微的不同。
在西元 2005 年， Unicode 的第十万个字元被输入成为标准之一，其为马来亚拉姆语（Malayalam，印度西南部沿海居民的语言）的 Praslesham（പ്രശ്ലേഷം）。
-----Unicode 的编码和实现
大概来说，Unicode 编码系统可分为编码方式和实现方式两个层次。
[编辑]编码方式
Unicode 的编码方式与 ISO 10646 的通用字符集（Universal Character Set，UCS）概念相对应，目前实际应用的 Unicode 版本对应于 UCS-2，使用16位的编码空间。也就是每个字符占用2个字节。这样理论上一共最多可以表示 216 即 65536 个字符。基本满足各种语言的使用。实际上目前版本的 Unicode 尚未填充满这16位编码，保留了大量空间作为特殊使用或将来扩展。
上述16位 Unicode 字符构成基本多文种平面（Basic Multilingual Plane，简称 BMP）。最新（但未实际广泛使用）的 Unicode 版本定义了16个辅助平面，两者合起来至少需要占据21位的编码空间，比3字节略少。但事实上辅助平面字符仍然占用4字节编码空间，与 UCS-4 保持一致。未来版本会扩充到 ISO 10646-1 实现级别3，即涵盖 UCS-4 的所有字符。UCS-4 是一个更大的尚未填充完全的31位字符集，加上恒为0的首位，共需占据32位，即4字节。理论上最多能表示 231 个字符，完全可以涵盖一切语言所用的符号。
BMP 字符的 Unicode 编码表示为 U+hhhh，其中每个 h 代表一个十六进制数位。与 UCS-2 编码完全相同。对应的4字节 UCS-4 编码后两个字节一致，前两个字节的所有位均为0。
关于 Unicode 和 ISO 10646 及 UCS 的详细关系 ，请参看通用字符集。
[编辑]实现方式
Unicode 的实现方式不同于编码方式。一个字符的 Unicode 编码是确定的。但是在实际传输过程中，由于不同系统平台的设计不一定一致，以及出于节省空间的目的，对 Unicode 编码的实现方式有所不同。Unicode 的实现方式称为Unicode转换格式（Unicode Translation Format，简称为 UTF）。
例如，如果一个仅包含基本7位ASCII字符的 Unicode 文件，如果每个字符都使用2字节的原 Unicode 编码传输，其第一字节的8位始终为0。这就造成了比较大的浪费。对于这种情况，可以使用 UTF-8 编码，这是一种变长编码，它将基本7位ASCII字符仍用7位编码表示，占用一个字节（首位补0）。而遇到与其他 Unicode 字符混合的情况，将按一定算法转换，每个字符使用1-3个字节编码，并利用首位为0或1进行识别。这样对以7位ASCII字符为主的西文文档就大大节省了编码长度（具体方案参见UTF-8）。类似的，对未来会出现的需要4个字节的辅助平面字符和其他 UCS-4 扩充字符，2字节编码的 UTF-16 也需要通过一定的算法进行转换。
再如，如果直接使用与 Unicode 编码一致（仅限于 BMP 字符）的 UTF-16 编码，由于每个字符占用了两个字节，在Macintosh (Mac)机和PC机上，对字节顺序的理解是不一致的。这时同一字节流可能会被解释为不同内容，如某字符为十六进制编码4E59，按两个字节拆分为4E和59，在Mac上读取时是从低字节开始，那么在Mac OS会认为此4E59编码为594E，找到的字符为“奎”，而在Windows上从高字节开始读取，则编码为 U+4E59 的字符为“乙”。就是说在Windows下以UTF-16编码保存一个字符“乙”，在Mac OS里打开会显示成“奎”。此类情况说明UTF-16的编码顺序若不加以人为定义就可能发生混淆，于是在 UTF-16 编码实现方式中使用了大尾序（Big-Endian， 简写为UTF-16 BE）、小尾序（Little-Endian, 简写为UTF-16 LE）的概念，以及可附加的BOM（Byte Order Mark）解决方案，目前在PC机上的Windows系统和Linux系统对于UTF-16编码默认使用UTF-16 LE。（具体方案参见UTF-16）
此外 Unicode 的实现方式还包括 UTF-7、Punycode、CESU-8、SCSU、UTF-32等，这些实现方式有些仅在一定的国家和地区使用，有些则属于未来的规划方式。目前通用的实现方式是 UTF-16小尾序（BOM）、UTF-16大尾序（BOM）和 UTF-8。在微软公司Windows XP操作系统附带的记事本（Notepad）中，“另存为”对话框可以选择的四种编码方式除去非 Unicode 编码的ANSI（对于英文系统即ASCII编码，中文系统则为GB2312或Big5编码） 外，其余三种为“Unicode”（对应UTF-16 LE）、“Unicode big endian”（对应UTF-16 BE）和“UTF-8”。
目前辅助平面的工作主要集中在第二和第三平面的中日韩统一表意文字中，因此包括GBK、GB18030、Big5等简体中文、繁体中文、日文、韩文以及越南喃字的各种编码与 Unicode 的协调性被重点关注。考虑到 Unicode 最终要涵盖所有的字符，从某种意义而言，这些编码方式也可视作 Unicode 的出现于其之前的既成事实的实现方式，如同ASCII及其扩展Latin-1一样，后两者的字符在16位 Unicode 编码空间中的编码第一字节各位全为0，第二字节编码与原编码完全一致。但上述东亚语言编码与 Unicode 编码的对应关系要复杂得多。
非 Unicode 环境
在非 Unicode 环境下，由于不同国家和地区采用的字符集不一致，很可能出现无法正常显示所有字符的情况。微软公司使用了代码页（Codepage）转换表的技术来过渡性的部分解决这一问题，即通过指定的转换表将非 Unicode 的字符编码转换为同一字符对应的系统内部使用的 Unicode 编码。可以在“语言与区域设置”中选择一个代码页作为非 Unicode 编码所采用的默认编码方式，如936为简体中文GBK，950为正体中文Big5（皆指PC上使用的）。在这种情况下，一些非英语的欧洲语言编写的软件和文档很可能出现乱码。而将代码页设置为相应语言中文处理又会出现问题，这一情况无法避免。从根本上说，完全采用统一编码才是解决之道，但目前尚无法做到这一点。
代码页技术现在广泛为各种平台所采用。UTF-7 的代码页是65000，UTF-8 的代码页是65001。
[编辑]XML 和 Unicode
XML及其子集XHTML采用UTF-8作为标准字集，理论上我们可以在各种支持XML标准的浏览器上显示任何地区文字的网页，只要电脑本身安装有合适的字体即可。可以利用&#nnn;的格式显示特定的字符。nnn代表该字符的十进制 Unicode 代码。如果采用十六进制代码，在编码之前加上x字符即可。但部分旧版本的浏览器可能无法识别十六进制代码。
过去电脑编码的8位标准，使每个国家都只按国家使用的字符而编定各自的编码系统；而对于部份字符系统比较复杂的语言，如越南语，又或者东亚国家的大型字符集，都不能在8位的环境下好好显示。若连自己的语言也未必可以好好显示，遑论显示其他国家的文字。然而，现在于HTML和XML，我们可以利用&#nnn;的格式显示特定的字符。nnn代表该字符的十进位Unicode代码。如果想采用十六进位代码的话，要在编码之前加上x字符。
只是最近才有在文本中对十六进制的支持，那么旧版本的浏览器显示那些字符或许可能有问题-大概首先会遇到的一个问题只是在对于大于8位Unicode字符的显示。解决这个问题的普遍做法仍然是将其中的十六进制码转换成一个十进制码（例如：用♠代替♠）。
也有一些字符集标准将一些常用的标志存放在字符内码外面，那么你可能使用象—这样的文本标志来表示一个长划（—）的情况，即使它的字符内码已经被使用，这些标准也不包含那个字符。
然而部分由于Unicode版本发展原因，很多浏览器只能显示UCS-2完整字符集，也即现在使用的Unicode版本中的一个小子集。下表可以检验您的浏览器怎样显示各种各样的Unicode代码：
代码 字符标准名称（英语） 在浏览器上的显示
A 大写拉丁字母"A" A
ß 小写拉丁字母"Sharp S" ß
þ 小写拉丁字母"Thorn" t
Δ 大写希腊字母"Delta" Δ
Й 大写斯拉夫字母"Short I" Й
ק 希伯来字母"Qof" ק
م 阿拉伯字母 "Meem" م
๗ 泰文数字 7 ๗
ቐ 埃塞俄比亚音节文字"Qha" ቐ
あ 日语平假名 "A" あ
ア 日语片假名 "A" ア
叶 简体汉字 "叶" 叶
葉 正体汉字 "葉" 葉
엽 韩国音节文字 "Yeob" 엽
一些多语言支持的网页浏览器，比如微软Windows系统的Internet Explorer5.5，以及跨平台的浏览器 Mozilla／Netscape 6，可以在安装时根据需要动态地使用相应的字符集，预先安装了合适的语言包，就可以同时显示页面上的各种Unicode字符。MSIE 5.5还提出用户可以在需要新字体时，即装即用。另外的浏览器如Netscape Navigator 4.77，则只能显示跟页面编码相应字符集中的文字。当你使用后一种浏览器时，你不大可能预先安装所有的字体，即使有了字体，浏览器也不一定能将这些字体完全应用起来。可能遇到的情况是，这种浏览器只能够显示部分文字，因为它们是按照标准进行编码，尽管理论上在兼容的系统中，只要有了相应的字体，就可以正确显示。一种变通的办法，是将某些少见的字符，通过“名称实体引用”的方式来使用。
[编辑]输入方法
[编辑]中文输入法
截至2009年3月，可以使用微软拼音2003或2007版本海峰五笔9.3版本，新注音输入法 和 VimIM 进行输入。
微软拼音 在输入法激活状态下，单击语言栏上的“功能菜单”按钮，指向“辅助输入法”即可发现“Unicode码输入方式”，利用它可以通过直接输入Unicode相应十六进制值的方式输入相应文字。例如中文“偦”输入“5066”，朝鲜语文字“셅”输入“c145”（不需要在前面加0x或x）。
海峰五笔 此输入法已经直接支持通过五笔码输入方式输入Unicode内的任意中日韩汉字，但无法使用键入Unicode码的方式输入。例如汉字（Unicode部分）“㗎”为“keks”，CJK扩展B区的“𣿱”为“iyho”和CJK扩展C区的“𫇛”为“muih”。
新注音输入法 在输入法启动状态时，打入键盘上的“多功能前导字元键”（及通用键盘上之“`”），第一次使用会弹出说明。输入Unicode字元“偦”则是在键盘上键入“`U5066”。而韩语中的“셅”，则输入“`UC145”。而要输入日语自制汉字“峠”，则是“`U5CE0”。
VimIM 在 Vim 环境中，可以直接键入十进制或十六进制 Unicode 码。既不需要激活输入法，也不需要码表。
[编辑]日文输入法
使用Microsoft IME 2007，可以在IME PAD里找到UNICODE的点击表。点击字符即可输入。选择字体可以预览字符效果。
[编辑]其他
除了输入法外，操作系统也会提供另外几种方法输入 Unicode。像是Windows 2000之后的 Windows 系统就提供一个可点击的字符映射表。又或者在Microsoft Word下，按下 Alt 键不放，输入 0 和某个字符的 Unicode 编码（十进制），再松开 Alt 键即可得到该字符，如Alt + 033865会得到 Unicode 字元叶。另外按Alt + X 组合键，MS Word 也会将光标前面的字符同其十六进制的四位 Unicode 编码进行互相转换。
[编辑]汉字问题
Unicode的汉字处理方法一直备受抨击。有指这种把数万汉字逐一编码的方式，非常浪费资源，要把汉字加到Unicode标准中也不容易。也有批评处理Unicode中汉字编码的专家，并不是真正研究汉字的学者。[1]从早期的中文电脑时期开始，已有研究以部件产生汉字（动态组字），取代汉字逐一编码方法。
[编辑]Unicode 编码表
Unicode 编码表
BMP SMP SIP SSP
0000—0FFF 8000—8FFF 10000—10FFF 20000—20FFF 28000—28FFF E0000—E0FFF
1000—1FFF 9000—9FFF 21000—21FFF 29000—29FFF
2000—2FFF A000—AFFF 12000—12FFF 22000—22FFF 2A000—2AFFF
3000—3FFF B000—BFFF 23000—23FFF
4000—4FFF C000—CFFF 24000—24FFF 2F000—2FFFF
5000—5FFF D000—DFFF 1D000—1DFFF 25000—25FFF
6000—6FFF E000—EFFF 26000—26FFF
7000—7FFF F000—FFFF 1F000—1FFFF 27000—27FFF
[编辑]相关条目
－－－－－－－－－－－－
UTF-8
维基百科，自由的百科全书
此条目可能需要进行清理，以符合维基百科的质量标准。（2007年12月31日）
请尽量协助改善这篇条目，详细信息请参见讨论页。
UTF-8（8 位元 Universal Character Set／Unicode Transformation Format）是一种针对 Unicode 的可变长度字元编码。它可以用来表示 Unicode 标准中的任何字元，且其编码中的第一个位元组仍与 ASCII 相容，这使得原来处理 ASCII 字元的软体无须或只须做少部份修改，即可继续使用。因此，它逐渐成为电子邮件、网页及其他储存或传送文字的应用中，优先采用的编码。
UTF-8 使用一至四个位元组为每个字符编码：
128 个 US-ASCII 字符只需一个位元组编码（Unicode 范围由 U+0000 至 U+007F）。
带有附加符号的拉丁文、希腊文、西里尔字母、亚美尼亚语、希伯来文、阿拉伯文、叙利亚文及它拿字母则需要二个位元组编码（Unicode 范围由 U+0080 至 U+07FF）。
其他基本多文种平面（BMP）中的字元（这包含了大部分常用字）使用三个位元组编码。
其他极少使用的 Unicode 辅助平面的字元使用四位元组编码。
对上述提及的第四种字元而言，UTF-8 使用四个位元组来编码似乎太耗费资源了。但 UTF-8 对所有常用的字元都可以用三个位元组表示，而且它的另一种选择，UTF-16编码，对前述的第四种字符同样需要四个位元组来编码，所以要决定 UTF-8 或 UTF-16 哪种编码比较有效率，还要视所使用的字元的分布范围而定。不过，如果使用一些传统的压缩系统，比如 DEFLATE，则这些不同编码系统间的的差异就变得微不足道了。若顾及传统压缩算法在压缩较短文字上的效果不大，可以考虑使用 Standard Compression Scheme for Unicode（SCSU）。
网际网路工程工作小组（IETF）要求所有网际网路协议都必须支援 UTF-8 编码。[1] 互联网邮件联盟（IMC）建议所有电子邮件软件都支援 UTF-8编码。所有主要的电子邮件软体中，只有 Eudora 不支援 UTF-8 编码。[1]
目录 [隐藏]
1 历史
2 描述
3 UTF-8的衍生物
3.1 Windows
3.2 Java
3.3 变种 UTF-8
3.4 Mac OS X
4 设计UTF-8的理由
5 过长的资料排列（overlong forms）、输入无效及保安的考虑
6 优点及缺点
7 使用UTF-8的原因
8 UTF-8的编码方式
9 UTF-8的特性
10 UTF-8编码的缺点
10.1 不利于正则表达式检索
10.2 其他
11 注释
12 参考
13 由统一码联盟出版的书
14 外部链接
[编辑]历史
1992年初，为建立良好的位元组串编码系统（byte-stream encoding）以供多位元组字元集（multi-byte character sets）使用，开始了一个正式的研究。ISO/IEC 10646的初稿中有一个非必须的附录，名为UTF。当中包含了一个供32位元的字元使用的位元组串编码系统。这个编码方式的性能并不令人满意，但它提出了将0-127的范围保留给ASCII以相容旧系统的概念。
1992年7月，X/Open委员会XoJIG开始寻求一个较佳的编码系统。Unix系统实验室（UNIX System Laboratories, USL）的Dave Prosser为此提出了一个编码系统的建议。它具备可更快速实作的特性，并引入一项新的改进。其中，7位元的ASCII符号只代表原来的意思，所有多位元组序列则会包含第8位元的符号，也就是所谓的最高有效位元（Most significant bit）。
1992年8月，这个建议由IBMX/Open的代表流传到一些感兴趣的团体。与此同时，贝尔实验室Plan 9作业系统工作小组的肯·汤普逊对这编码系统作出重大的修改，让编码可以自我同步（self-synchronizing），使得不必从字串的开首读取，也能找出字符间的分界。1992年9月2日，肯·汤普逊和Rob Pike一起在美国新泽西州一架餐车的餐桌垫上描绘出此设计的要点。接下来的日子，Pike及汤普逊将它实现，并将这编码系统完全应用在Plan 9当中，及后他将有关成果回馈X/Open。
1993年1月25-29日的在圣地牙哥举行的USENIX会议首次正式介绍UTF-8。
自1996年起，微软的CAB（MS Cabinet）规格在UTF-8标准正式落实前就明确容许在任何地方使用UTF-8编码系统。但有关的编码器实际上从来没有实作这方面的规格。
[编辑]描述
目前有好几份关于UTF-8详细规格的文件，但这些文件在定义上有些许的不同：
RFC 3629 / STD 63（2003），这份文件制定了UTF-8是标准的网际网路协议元素
第四版，The Unicode Standard，§3.9－§3.10（2003）
ISO/IEC 10646-1:2000附加文件D（2000）
它们取代了以下那些被淘汰的定义：
ISO/IEC 10646-1:1993修正案2／附加文件R（1996）
第二版，The Unicode Standard，附录A（1996）
RFC 2044（1996）
RFC 2279（1998）
第三版，The Unicode Standard，§2.3（2000）及勘误表#1：UTF-8 Shortest Form（2000）
Unicode Standard 附加文件#27: Unicode 3.1（2001）
事实上，所有定义的基本原理都是相同的，它们之间最主要的不同是支援的字元范围及无效输入的处理方法。
Unicode字元的位元被分割为数个部分，并分配到UTF-8的位元组串中较低的位元的位置。在U+0080的以下字元都使用内含其字元的单位元组编码。这些编码正好对应7位元的ASCII字符。在其他情况，有可能需要多达4个字元组来表示一个字元。这些多位元组的最高有效位元会设定成1，以防止与7位元的ASCII字符混淆，并保持标准的位元组主导字串（standard byte-oriented string）运作顺利。
代码范围
十六进制 标量值(scalar value)
二进制 UTF-8
二进制／十六进制 注释
000000 - 00007F
128个代码 00000000 00000000 0zzzzzzz 0zzzzzzz(00-7F) ASCII字元范围，位元组由零开始
七个z 七个z
000080 - 0007FF
1920个代码 00000000 00000yyy yyzzzzzz 110yyyyy(C2-DF) 10zzzzzz(80-BF) 第一个位元组由110开始，接着的位元组由10开始
三个y；二个y；六个z 五个y；六个z
000800 - 00D7FF
00E000 - 00FFFF
61440个代码 [Note 1] 00000000 xxxxyyyy yyzzzzzz 1110xxxx(E0-EF) 10yyyyyy 10zzzzzz 第一个位元组由1110开始，接着的位元组由10开始
四个x；四个y；二个y；六个z 四个x；六个y；六个z
010000 - 10FFFF
1048576个代码 000wwwxx xxxxyyyy yyzzzzzz 11110www(F0-F4) 10xxxxxx 10yyyyyy 10zzzzzz 由11110开始，接着的位元组由10开始
三个w；二个x；四个x；四个y；二个y；六个z 三个w；六个x；六个y；六个z
Note 1 Unicode在范围D800-DFFF中不存在任何字元，基本多文种平面中约定了这个范围用于UTF-16扩展标识辅助平面（两个UTF-16表示一个辅助平面字符）。当然，任何编码都是可以被转换到这个范围，但在unicode中他们并不代表任何合法的值。
例如，希伯来语字母 aleph（א）的Unicode代码是 U+05D0，按照以下方法改成 UTF-8:
它属于 U+0080到U+07FF区域，这个表说明它使用双字节，110yyyyy 10zzzzzz.
十六进制 的 0x05D0换算成二进制就是 101-1101-0000.
这11位数按顺序放入"y"部分和"z"部分：11010111 10010000.
最后结果就是双字节，用十六进制写起来就是 0xD7 0x90，这就是这个字符aleph（א）的UTF-8编码。
所以开始的128个字元（US-ASCII）只需一字节，接下来的1920个字符需要双字节编码，包括带附加符号的拉丁字母，希腊字母，西里尔字母，科普特语字母，亚美尼亚语字母，希伯来文字母和阿拉伯字母的字元。基本多文种平面中其余的字元使用三个字节，剩余字符使用四个字节。
根据这种方式可以处理更大数量的字元。原来的规范允许长达6字节的序列，可以覆盖到31位元（通用字符集原来的极限）。尽管如此，2003年11月UTF-8 被 RFC 3629 重新规范，只能使用原来Unicode定义的区域， U+0000到U+10FFFF。根据这些规范，以下字节值将无法出现在合法 UTF-8序列中：
编码（二进制） 编码（十六进制） 注释
1100000x C0, C1 过长编码：双字节序列的头字节，但码点<= 127
1111111x FE, FF 无法达到：7 或8字节序列的头字节
111110xx
1111110x F8, F9, FA, FB, FC, FD 被RFC 3629规范：5 或 6字节序列的头字节
11110101
1111011x F5, F6, F7 被RFC 3629规范：码点超过10FFFF的头字节
[编辑]UTF-8的衍生物
[编辑]Windows
虽然不是标准，但许多Windows 程序（包括Windows 笔记本）在UTF-8编码的档案的开首加入一段位元组串EF BB BF。这是位元组顺序记号 U+FEFF 的 UTF-8 编码结果。对于没有预期要处理UTF-8的文字编辑器和浏览器会显示成 ISO-8859-1 字符串 ""。
[编辑]Java
在通常用法下，Java程序语言在通过InputStreamReader 和OutputStreamWriter读取和写入串的时候支持标准UTF-8。但是，Java也支持一种非标准的变体UTF-8，供对象的系列化，Java本地界面和在class文件中的嵌入常数时使用的modified UTF-8。
[编辑]变种 UTF-8
标准和变种的UTF-8有两个不同点。第一，空字符（null character，U+0000）使用双字节的 0xc0 0x80，而不是单字节的 0x00。这保证了在已编码字串中没有嵌入空字节。因为C语言等语言程序中，单字节空字符是用来标志字串结尾的。当已编码字串放到这样的语言中处理，一个嵌入的空字符将把字串一刀两断。
第二个不同点是基本多文种平面之外字符的编码的方法。在标准UTF-8中，这些字符使用4字节形式编码，而在改正的UTF-8中，这些字符和UTF-16一样首先表示为代理对（surrogate pairs），然后再像CESU-8那样按照代理对分别编码。这样改正的原因更是微妙。Java中的字符为16位长，因此一些Unicode字符需要两个Java字符来表示。语言的这个性质盖过了Unicode的增补平面的要求。尽管如此，为了要保持良好的向后兼容、要改变也不容易了。这个改正的编码系统保证了一个已编码字串可以一次编为一个UTF-16码，而不是一次一个Unicode码点。 不幸的是，这也意味着UTF-8中需要4字节的字符在变种UTF-8中变成需要6字节。
因为变种UTF-8并 不是 UTF-8，所以用户在交换信息和使用互联网的时候需要特别注意不要误把变种UTF-8当成UTF-8数据。
[编辑]Mac OS X
Mac OS X操作系统使用正式分解万国码（canonically decomposed Unicode），在文件系统中使用UTF-8编码进行文件命名，这做法通常被称为UTF-8-MAC。正式分解万国码中，预分解字符是被禁止使用的，必须以组合字符取代。
这种方法使分类变得非常简单，但是会搞混那些使用预分解字符为标准、组合字符用来显示特殊字符的软件。Mac系统的这种NFD数据是万国码规范化（Unicode normalization）的一种格式。而其他系统，包括Windows和 Linux，使用万国码规范的NFC形式，也是W3C标准使用的形式。所以NFD数据必须典型的转换成NFC才能被其他平台或者网络使用。
在此有关于此问题的讨论 Apple Q&A 1173。
[编辑]设计UTF-8的理由
UTF-8的设计有以下的多字元组序列的特质：
单位元组字符的最高有效位元永远为0。
多位元组序列中的首个字元组的几个最高有效位元决定了序列的长度。最高有效位为110的是2位元组序列，而1110的是三位元组序列，如此类推。
多位元组序列中其余的位元组中的首两个最高有效位元为10。
UTF-8的这些特质，保证了一个字符的位元组序列不会包含在另一个字符的位元组序列中。这确保了以位元组为基础的部份字串比对（sub-string match）方法可以适用于在文字中搜寻字或词。有些比较旧的可变长度8位元编码（如Shift JIS）没有这个特质，故字串比对的算法变得相当复杂。虽然这增加了UTF-8编码的字串的信息冗余，但是利多于弊。另外，资料压缩并非Unicode 的目的，所以不可混为一谈。即使在传送过程中有部份位元组因错误或干扰而完全遗失，还是有可能在下一个字符的起点重新同步，令受损范围受到限制。
另一方面，由于其位元组序列设计，如果一个疑似为字符串的序列被验证为UTF-8编码，那么我们可以有把握地说它是UTF-8字符串。一段两位元组随机序列碰巧为合法的UTF-8而非ASCII 的机率为32分1。对于三位元组序列的机率为256分3，对更长的序列的机率就更低了。
[编辑]过长的资料排列（overlong forms）、输入无效及保安的考虑
[编辑]优点及缺点
关于字符串长度的一个注解：
总体来说，在Unicode字符串中不可能由码点数量决定显示它所需要的长度，或者显示字符串之后在文本缓冲区中光标应该放置的位置；组合字符、变宽字体、不可打印字符和从右至左的文字都是其归因。
所以尽管在UTF-8字符串中字元数量与码点数量的关系比UTF-32更为复杂，在实际中很少会遇到有不同的情形。
总体
优点
UTF-8是ASCII的一个超集。因为一个纯ASCII字符串也是一个合法的UTF-8字符串，所以现存的ASCII文本不需要转换。为传统的扩展ASCII字符集设计的软件通常可以不经修改或很少修改就能与UTF-8一起使用。
使用标准的面向字节的排序例程对UTF-8排序将产生与基于Unicode代码点排序相同的结果。（尽管这只有有限的有用性，因为在任何特定语言或文化下都不太可能有仍可接受的文字排列顺序。）
UTF-8和UTF-16都是可扩展标记语言文档的标准编码。所有其它编码都必须通过显式或文本声明来指定。[2]
任何面向字节的字符串搜索算法都可以用于UTF-8的数据（只要输入仅由完整的UTF-8字符组成）。但是，对于包含字符记数的正则表达式或其它结构必须小心。
UTF-8字符串可以由一个简单的算法可靠地识别出来。就是，一个字符串在任何其它编码中表现为合法的UTF-8的可能性很低，并随字符串长度增长而减小。举例说，字元值C0,C1,F5至FF从来没有出现。为了更好的可靠性，可以使用正则表达式来统计非法过长和替代值（可以查看W3 FAQ: Multilingual Forms上的验证UTF-8字符串的正则表达式）。
缺点
一份写得很差（并且与当前标准的版本不兼容）的UTF-8解析器可能会接受一些不同的伪UTF-8表示并将它们转换到相同的Unicode输出上。这为设计用于处理八位表示的校验例程提供了一种遗漏信息的方式。
[编辑]使用UTF-8的原因
ASCII转换成UCS-2，在编码前插入一个0x0。用这些编码，会含括一些控制符，比如 " 或 '/'，这在UNIX和一些C函数中，将会产生严重错误。因此可以肯定，UCS-2不适合作为Unicode的外部编码，也因此诞生了UTF-8。
[编辑]UTF-8的编码方式
UTF-8是UNICODE的一种变长度的编码表达方式 《一般UNICODE为双位元组（指UCS2）》，它由Ken Thompson于1992年建立，现在已经标准化为RFC 3629。UTF-8就是以8位为单元对UCS进行编码，而UTF-8不使用大尾序和小尾序的形式，每个使用UTF-8储存的字符，除了第一个字节外，其余字节的头两个位元都是以 "10" 开始，使文字处理器能够较快地找出每个字符的开始位置。
但为了与以前的ASCII码相容（ASCII为一个位元组），因此 UTF-8 选择了使用可变长度字节来储存 Unicode：
Unicode和UTF-8之间的转换关系表
UCS-4编码 UTF-8字节流
U-00000000 – U-0000007F: 0xxxxxxx
U-00000080 – U-000007FF: 110xxxxx 10xxxxxx
U-00000800 – U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
U-00010000 – U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 – U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 – U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
在ASCII码的范围，用一个位元组表示，超出ASCII码的范围就用位元组表示，这就形成了我们上面看到的UTF-8的表示方法，这様的好处是当UNICODE文件中只有ASCII码时，储存的文件都为一个位元组，所以就是普通的ASCII文件无异，读取的时候也是如此，所以能与以前的ASCII文件相容。
大于ASCII码的，就会由上面的第一位元组的前几位表示该unicode字元的长度，比如110xxxxxx前三位的二进位表示告诉我们这是个 2BYTE的UNICODE字元；1110xxxx是个三位的UNICODE字元，依此类推；xxx 的位置由字符编码数的二进制表示的位填入。越靠右的 x 具有越少的特殊意义。只用最短的那个足够表达一个字符编码数的多字节串。注意在多字节串中，第一个字节的开头"1"的数目就是整个串中字节的数目。。
ASCII字母继续使用1字节储存，重音文字、希腊字母或西里尔字母等使用2字节来储存，而常用的汉字就要使用3字节。辅助平面字元则使用4字节。
在UTF-8文件的开首，很多时都放置一个U+FEFF字符（UTF-8 以 EF,BB,BF 代表），以显示这个文字档案是以UTF-8编码。
[编辑]UTF-8的特性
UTF-8图表说明
UTF-8
Smallest code point 0000
Largest code point 10FFFF
Code unit size 8 bits
Byte order N/A
Minimal bytes/character 1
Maximal bytes/character 4
UCS 字符 U+0000 到 U+007F (ASCII) 被编码为字节 0x00 到 0x7F（ASCII 兼容），这也意味着只包含 7 位 ASCII 字符的文件在 ASCII 和 UTF-8 两种编码方式下是一样的。
所有 >U+007F 的 UCS 字符被编码为一个多个字节的串，每个字节都有标记位集。因此，ASCII 字节 (0x00-0x7F) 不可能作为任何其他字符的一部分。
表示非 ASCII 字符的多字节串的第一个字节总是在 0xC0 到 0xFD 的范围里，并指出这个字符包含多少个字节。多字节串的其余字节都在 0x80 到 0xBF 范围里，这使得重新同步非常容易，并使编码无国界，且很少受丢失字节的影响。
可以编入所有可能的 231个 UCS 代码
UTF-8 编码字符理论上可以最多到 6 个字节长，然而 16 位 BMP 字符最多只用到 3 字节长。
Bigendian UCS-4 字节串的排列顺序是预定的。
字节 0xFE 和 0xFF 在 UTF-8 编码中从未用到，同时，UTF-8以位元组为编码单元，它的位元组顺序在所有系统中都是一様的，没有位元组序的问题，也因此它实际上并不需要BOM。
与 UTF-16 或其他 Unicode 编码相比，对于不支援 Unicode 和 XML 的系统，UTF-8 更不容易造成问题。
【注】
UTF为UCS / Unicode Transformation Format“Unicode转换格式”的缩写。
UCS的中文全称为：信息技术--通用多八位编码字符集 (Universal Multi-octet Coded Character Set)，由ISO/IEC 10646 标准描述。
[编辑]UTF-8编码的缺点
[编辑]不利于正则表达式检索
正则表达式可以进行很多英文高级的模糊检索。例如，[a-h]表示a到h间所有字母。
同样GBK编码的中文也可以这样利用正则表达式，比如在只知道一个字的读音而不知道怎么写的情况下，也可用正则表达式检索，因为GBK编码是按读音排序的。只是UTF-8不是按读音排序的，所以会对正则表达式检索造成不利影响。但是这种使用方式并未考虑中文中的破音字，因此影响不大。Unicode是按部首排序的，因此在只知道一个字的部首而不知道如何发音的情况下，UTF-8 可用正则表达式检索而GBK不行。
[编辑]其他
与其他 Unicode 编码相比，特别是UTF-16，在 UTF-8 中 ASCII 字元占用的空间只有一半，可是在一些字元的 UTF-8 编码占用的空间就要多出，特别是中文、日文和韩文（CJK）这样的象形文字，所以具体因素因文档而异，但不论哪种情况，差别都不可能很明显。
[编辑]
－－－－－－－－－－
GBK
维基百科，自由的百科全书
GBK全名为汉字内码扩展规范，英文名Chinese Internal Code Specification。K 即是“扩展”所对应的汉语拼音（KuoZhan11）中“扩”字的声母。GBK 来自中国国家标准代码GB 13000.1-93。
目录 [隐藏]
1 概况
2 后续
3 参见
4 外部链结
[编辑]概况
1993年，Unicode 1.1版本推出，收录了中国大陆、台湾、日本及韩国通用字符集的汉字，总共有20,902个。
中国大陆订定了等同于Unicode 1.1版本的“GB 13000.1-93”“信息技术 通用多八位编码字符集（UCS）第一部分：体系结构与基本多文种平面”。
由于GB 2312-80只收录了6763个汉字，有不少汉字，如部分在GB 2312-80推出以后才简化的汉字（如“啰”），部分人名用字（如中国前总理朱镕基的“镕”字），台湾及香港使用的繁体字，日语及朝鲜语汉字等，并未有收录在内。中文电脑开发商，于是利用了GB 2312-80未有使用的编码空间，收录了所有出现在Unicode 1.1及GB 13000.1-93之中的汉字，制定了GBK编码。
根据西方资料，GBK最初是由微软对GB2312的扩展，也就是CP936字码表 (Code Page 936)的扩展（原来的CP936和GB 2312-80一模一样），最初出现于Windows 95简体中文版中，由于Windows产品的流行和在大陆广泛被使用，中华人民共和国国家有关部门将其作为技术规范。注意GBK并非国家正式标准，只是国家技术监督局标准化司、电子工业部科技与质量监督司发布的“技术规范指导性文件”。虽然GBK收录了所有Unicode 1.1及GB 13000.1-93之中的汉字，但是编码方式与Unicode 1.1及GB 13000.1-93不同。仅仅是GB 2312到GB 13000.1-93之间的过渡方案。
[编辑]后续
中华人民共和国国家质量技术监督局于2000年3月17日推出了GB 18030-2000标准，以取代GBK。GB 18030-2000除了保留了全部GBK编码的汉字外，还增加了大约一百个汉字及四位元组编码空间。请参看GB 18030-2000。
