前言
iOS平台，系统输入法emoji表达。表达式不能在很多其他平台上显示，尤其是在Android。Symbian系统。我决定到底要探索1；我指的是一些知识：
（注意：该博文已经如果读者已经了解utf-8的知识了）
1. 笔者提供的“将字符串转化成unicode和utf-8”的工具。
2. 维基百科utf-16 点击打开
3. 笔者博文，utf-8的介绍 点击打开
4. 笔者博文，完整unicode码表（网页打开较慢） 点击打开
问题描写叙述
开发和产品讨论字符占用的字节数。有人说2个，有人说4个。还有开发说iPhone的表情是iOS自定特定的。以下介绍一下emoji表情。
比方，在输入框输入一个emoji——微笑，然后通过UTF-8转化工具，看看它的编码是什么情况：
能够看到Unicode编码是 D83D-DE03。utf-8的编码是F09F-9883.这个不平常的，以下会具体介绍。
这里须要注意一下：通常utf-8是1到3个字节的，也就是说在Unicode编码空间的第0个平面上。
这里有必要说明一下utf-8的编码规则（很多其它点击这里）如图所看到的：
就上面这个表格。我们举个样例：拿“汉”字的汉来说。
它的unicode是0x6C49。utf8是0xE6B189,带入公式，发现是合乎规则的。
我们再看看“微笑”emoji符号的Unicode：D83D-DE03，已经超过了最大的0X10FFFF了，超过了最大的了怎么回事？？？以下我们依据utf-8的值：F09F-9883.来反推Unicode相应的数值吧，看看到底是为什么：
得出的结果是0x1-F603。我把这个值叫做utf-16.这个结果跟Unicode：D83D-DE03的值相差非常大，所以，中间肯定经过了一些转换步骤。这个转换就是utf-16的代理！
。！
UFT-16
UTF是"Unicode/UCS Transformation Format"的首字母缩写，即把Unicode字符转换为某种格式之意。上面第二张图片展示的是utf-8和unicode的相应表，这仅仅是一个简单的相应。却很好用。
在正常情况下一个Unicode两个字节。在转化uft-8的时候，依据协议。两个两个字节。相应一个uft-8这样完毕转化或者称为映射！
事实上在第0个平面中，专门有一个代理区域，不表示不论什么字符，仅仅用于指向第1到第16个平面中的字符，这段区域是：D800——DFFF.。当中0xD800——0xDBFF是前导代理(lead surrogates).0xDC00——0xDFFF是后尾代理(trail surrogates).
一个代理对儿（前导，后尾），就表示一个utf-16的字符。
就那emoji的微笑来说。前导是代理：D83D；后尾代理是：DE03。依据下图能够得出utf-16的值是：0x1-F603。这就照顾上了。
详细的公式是：0x10000 + (前导-0xD800) * 0x400 + (后导-0xDC00) = utf-16编码。
就我们说的样例emoji而言。代入前导和后导。结果是：0x10000+(0xD83D - 0xD800)*0x400 + (0xDE03-0xDC00) = 0x1F603
作为程序猿的我们，笔者做一个形象的比喻：这对儿（前导代理，后尾代理）就像一个指针，指向了第1——16平面上的每个码位。
经过计算，不难得出：16个平面X每个平面码位65536 = 1,048,576个。前导X后尾代理。能够表示的码位也是1,048,576个（哈！
真是一个完美的解决方式）如上图所看到的。
这样做的优点是：程序依据Unicode的第一个字节来推断：（伪代码）
if(Unicode第一个字节 >=0xD8 && Unicode <=0xDB){
//这是代理区域，表示第1——16平面的字符。每四个字节表示一个单元
}
else{
//这是正常映射区域，表示第0个平面。每两个字节表示一个单元。
}
这种结果是：依据这个协议推断。计算机能够知道两个字节，还是四个自己表示一个字符。
总结
这里说的utf-8和utf-16，事实上本质上是一样的。
仅仅是utf-8是一个直接的映射。而utf-16须要依据代理区的（前导代理，后尾代理）来映射。utf-16比utf-8多了一步而已！
话又说回来：假设不是代理区域的出现，就emoji 微笑的unicode： D83D-DE03为。
计算机甚至不知道这是不是一个字符。或两个字符？
版权声明：本文博客原创文章，博客，未经同意，不得转载。