Unicode

Unicode（中文：万国码、国际码、统一码、单一码）是计算机科学领域里的一项业界标准。它对世界上大部分的文字系统进行了整理、编码，使得电脑可以用更为简单的方式来呈现和处理文字。
Unicode 伴随着通用字符集的标准而发展，同时也以书本的形式对外发表。Unicode 至今仍在不断增修，每个新版本都加入更多新的字符。当前最新的版本为2019年5月公布的12.1.0，已经收录超过13万个字符（第十万个字符在2005年获采纳）。Unicode涵盖的数据除了视觉上的字形、编码方法、标准的字符编码外，还包含了字符特性，如大小写字母。
Unicode发展由非营利机构统一码联盟负责，该机构致力于让Unicode 方案取代既有的字符编码方案。因为既有的方案往往空间非常有限，亦不适用于多语环境。
Unicode备受认可，并广泛地应用于电脑软件的国际化与本地化过程。有很多新科技，如可扩展置标语言（Extensible Markup Language，简称：XML）、Java编程语言以及现代的操作系统，都采用Unicode编码。

起源与发展

Unicode是为了解决传统的字符编码方案的局限而产生的，例 ISO 8859-1所定义的字符虽然在不同的国家中广泛地使用，可是在不同国家间却经常出现不兼容的情况。很多传统的编码方式都有一个共同的问题，即容许电脑处理双语环境（通常使用拉丁字母以及其本地语言），但却无法同时支持多语言环境（指可同时处理多种语言混合的情况）。
Unicode 编码包含了不同写法的字，如“ɑ／a”、“強／强”、“戶／户／戸”。然而在汉字方面引起了一字多形的认定争议（详见中日韩统一表意文字主题）。
在文字处理方面，统一码为每一个字符而非字形定义唯一的代码（即一个整数）。换句话说，统一码以一种抽象的方式（即数字）来处理字符，并将视觉上的演绎工作（例如字体大小、外观形状、字体形态、文体等）留给其他软件来处理，例如网页浏览器或是文字处理器。
当前，几乎所有电脑系统都支持基本拉丁字母，并各自支持不同的其他编码方式。Unicode为了和它们相互兼容，其首256 个字符保留给ISO 8859-1 所定义的字符，使既有的西欧语系文字的转换不需特别考量；并且把大量相同的字符重复编到不同的字符码中去，使得旧有纷杂的编码方式得以和Unicode编码间互相直接转换，而不会丢失任何信息。举例来说，全角格式区段包含了主要的拉丁字母的全角格式，在中文、日文、以及韩文字形当中，这些字符以全角的方式来呈现，而不以常见的半角形式显示，这对竖排文字和等宽排列文字有重要作用。
在表示一个Unicode 的字符时，通常会用“U+”然后紧接着一组十六进制的数字来表示这一个字符。在基本多文种平面（英语：Basic Multilingual Plane，简写 BMP。又称为“零号平面”、plane 0）里的所有字符，要用四个数字（即两个byte，共16 bits，例如 U+4AE0，共支持六万多个字符）；在零号平面以外的字符则需要使用五个或六个数字。旧版的Unicode 标准使用相近的标记方法，但却有些微小差异：在 Unicode 3.0 里使用“U-”然后紧接着八个数字，而“U+”则必须随后紧接着四个数字。

标准

位于美国加州的Unicode组织允许任何愿意支付会费的公司和个人加入，其成员包含了主要的电脑软硬件厂商，例如Adobe系统、苹果公司、惠普、IBM、微软、施乐等。
20世纪80年代末，组成 Unicode 组织的商业机构，和国际合作的国际标准化组织因为电脑普及和信息国际化的前提下，分别各自成立了Unicode 组织和 ISO-10646 工作小组。他们不久便发现对方的存在，大家为着相同的目的而工作。1991 年，Unicode Consortium 与 ISO/IEC JTC1/SC2 同意保持Unicode 码表与ISO 10646 标准保持兼容并密切协调各自标准近一步的扩展。虽然实际上两者的字集编码相同，但实质上两者确实为两个不同的标准。Unicode 1.1 对应于ISO 10646-1:1993，Unicode 3.0 对应于ISO 10646-1:2000，Unicode 3.2 对应于ISO 10646-2:2001，Unicode 4.0 对应于ISO 10646:2003，Unicode 5.0 对应于ISO 10646:2003 及附录1–3。
Unicode 自版本2.0 开始保持了向后兼容，即新的版本仅仅增加字符，原有字符不会被删除或更名。 
统一码联盟在1991 年首次发布了The Unicode Standard。Unicode 的开发结合了国际标准化组织所制定的ISO/IEC 10646，即通用字符集。Unicode 与 ISO/IEC 10646 在编码的运作原理相同，但 The Unicode Standard 包含了更详尽的实现信息、涵盖了更细节的主题，诸如比特编码（bitwise encoding）、校对以及呈现等。The Unicode Standard 也枚举了诸多的字符特性，包含了那些必须支持两种阅读方向的文字（由左至右或由右至左的文字阅读方向，例如阿拉伯文是由右至左）。Unicode 与 ISO/IEC 10646 这两个标准在术语上的使用有些微的不同。
在 2005 年，Unicode 的第十万个字符被引入成为标准之一，该字符被用于马拉雅拉姆语。

Unicode 的编码和实现

大概来说，Unicode 编码系统可分为编码方式和实现方式两个层次。

编码方式

统一码的编码方式与ISO 10646 的通用字符集概念相对应。当前实际应用的统一码版本对应于UCS-2，使用 16 位的编码空间。也就是每个字符占用2 个字节。这样理论上一共最多可以表示2¹⁶（即 65536）个字符。基本满足各种语言的使用。实际上当前版本的统一码并未完全使用这16 位编码，而是保留了大量空间以作为特殊使用或将来扩展。
上述 16 位统一码字符构成基本多文种平面。最新（但未实际广泛使用）的统一码版本定义了16 个辅助平面，两者合起来至少需要占据21 位的编码空间，比 3 字节略少。但事实上辅助平面字符仍然占用4 字节编码空间，与 UCS-4 保持一致。未来版本会扩充到ISO 10646-1 实现级别3，即涵盖UCS-4 的所有字符。UCS-4 是一个更大的尚未填充完全的31 位字符集，加上恒为0 的首位，共需占据32 位，即 4 字节。理论上最多能表示2³¹个字符，完全可以涵盖一切语言所用的符号。
基本多文种平面的字符的编码为U+hhhh，其中每个h 代表一个十六进制数字，与 UCS-2 编码完全相同。而其对应的4 字节UCS-4 编码后两个字节一致，前两个字节则所有位均为0。
关于统一码和ISO 10646 及 UCS 的详细关系，见通用字符集。

实现方式

Unicode 的实现方式不同于编码方式。一个字符的Unicode 编码是确定的。但是在实际传输过程中，由于不同系统平台的设计不一定一致，以及出于节省空间的目的，对 Unicode 编码的实现方式有所不同。Unicode 的实现方式称为Unicode转换格式（Unicode Transformation 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 编码，由于每个字符占用了两个字节，在麦金塔电脑（Mac）机和个人电脑上，对字节顺序的理解是不一致的。这时同一字节流可能会被解释为不同内容，如某字符为十六进制编码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）的概念，以及可附加的字节顺序记号解决方案，当前在PC 机上的Windows 系统和Linux 系统对于UTF-16 编码默认使用UTF-16 LE。（具体方案参见UTF-16）
此外 Unicode 的实现方式还包括UTF-7、Punycode、CESU-8、SCSU、UTF-32、GB18030 等，这些实现方式有些仅在一定的国家和地区使用，有些则属于未来的规划方式。当前通用的实现方式是UTF-16 小端序（LE）、UTF-16 大端序（BE）和 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为简体中文GB码，950为繁体中文Big5（皆指PC上使用的）。在这种情况下，一些非英语的欧洲语言编写的软件和文档很可能出现乱码。而将代码页设置为相应语言中文处理又会出现问题，这一情况无法避免。只有完全采用统一编码才能彻底解决这些问题，但当前尚无法做到这一点。
代码页技术现在广泛为各种平台所采用。UTF-7 的代码页是65000，UTF-8 的代码页是65001。

日文输入法

使用 Microsoft IME 2007，可以在IME PAD里找到Unicode的点击表。点击字符即可输入。选择字体可以预览字符效果。

其他

除了输入法外，操作系统也会提供另外几种方法输入Unicode。像是Windows 2000 之后的Windows 系统就提供一个可点击的字符映射表。又或者在Microsoft Word 下，按下Alt 键不放，输入 0 和某个字符的Unicode 编码（十进制），再松开Alt 键即可得到该字符，如Alt + 033865会得到Unicode 字符叶。另外按Alt + X组合键，MS Word 也会将光标前面的字符同其十六进制的四位Unicode 编码进行互相转换。