摘要：因此導(dǎo)致亂碼的真正原因就是各平臺(tái)間對(duì)標(biāo)準(zhǔn)實(shí)現(xiàn)不一致包括實(shí)現(xiàn)的時(shí)間先后不同，以及所代表含義不同。日本幾家公司各自定義了一套標(biāo)準(zhǔn)，用兩個(gè)字節(jié)表示符號(hào)，日本電腦系統(tǒng)的一種編碼編碼是從到。在上找到了與標(biāo)準(zhǔn)的對(duì)應(yīng)關(guān)系。

歡迎關(guān)注個(gè)人網(wǎng)站：http://www.iamaddy.net/2016/07/emoji-unicode-parser/

這是一個(gè)由亂碼引發(fā)的故事。抱歉我暫時(shí)找不到更加慘烈的圖，請(qǐng)相信我，還有更目不忍視的畫面。請(qǐng)看下圖那些框框，那都是些什么鬼！這是要害死強(qiáng)迫癥嗎？如果同時(shí)看到幾十個(gè)框，簡(jiǎn)直讓人崩潰。

問題來(lái)了，這究竟是些什么鬼？

既然是亂碼，當(dāng)然要看編碼，那什么是編碼呢？我們都知道，計(jì)算機(jī)本質(zhì)上不就是01組成的一坨東西在運(yùn)作著么？01這叫二進(jìn)制，也就是最基本最底層的編碼。

那么大家平?？吹降木W(wǎng)頁(yè)也好，APP也好，上面的這些文字符號(hào)是怎么表現(xiàn)出來(lái)的？當(dāng)然是根據(jù)標(biāo)記打印出來(lái)的，但計(jì)算機(jī)只能是二進(jìn)制的存儲(chǔ)，并不能真正存ABCD呀，那就要把字母映射為相應(yīng)的二進(jìn)制。

上個(gè)世紀(jì)60年代，美國(guó)制定了一套字符編碼，對(duì)英語(yǔ)字符與二進(jìn)制位之間的關(guān)系，做了統(tǒng)一規(guī)定。這被稱為ASCII碼，一直沿用至今。

ASCII碼一共規(guī)定了128個(gè)字符的編碼，比如大寫的字母A是65（二進(jìn)制01000001）。這128個(gè)符號(hào)（包括32個(gè)不能打印出來(lái)的控制符號(hào)），只占用了一個(gè)字節(jié)的后面7位，最前面的1位統(tǒng)一規(guī)定為0。但你美國(guó)英文字母少啊，我中文怎么辦呢？全世界其他國(guó)家的字母其他語(yǔ)言怎么辦呢，那就多加一些字節(jié)來(lái)表示咯。

如果有一種編碼，將世界上所有的符號(hào)都納入其中。每一個(gè)符號(hào)都給予一個(gè)獨(dú)一無(wú)二的編碼，那么亂碼問題就會(huì)消失了，這就是Unicode。Unicode規(guī)定了每個(gè)符號(hào)都有自己的二進(jìn)制碼。標(biāo)準(zhǔn)雖是標(biāo)準(zhǔn)，但各平臺(tái)實(shí)現(xiàn)標(biāo)準(zhǔn)的進(jìn)度不一啊，有的各自為政，這就有問題了，就像各大瀏覽器產(chǎn)商，沒給我們前端少帶來(lái)麻煩啊。簡(jiǎn)單點(diǎn)說，雖然你蘋果實(shí)現(xiàn)了這個(gè)標(biāo)準(zhǔn)可以顯示這個(gè)符號(hào)，但我Android沒有，也不知道這個(gè)符號(hào)表達(dá)成啥，所以暫時(shí)給個(gè)框吧。

因此導(dǎo)致亂碼的真正原因：就是各平臺(tái)間對(duì)Unicode標(biāo)準(zhǔn)實(shí)現(xiàn)不一致（包括實(shí)現(xiàn)的時(shí)間先后不同，以及Unicode所代表含義不同）。

那框框的Unicode編碼到底是什么呢？charCodeAt() （這個(gè)方法有局限性，后面說）方法可返回指定位置的字符的 Unicode 編碼。這個(gè)返回值是 0 - 65535 之間的整數(shù)。

" 追求簡(jiǎn)單的小生活".charCodeAt(0)
// 57614

57614是個(gè)十進(jìn)制數(shù)，對(duì)應(yīng)16進(jìn)制為E10E，Unicode也可以表示為U+E10E。通過這個(gè)網(wǎng)站查詢得知結(jié)果如下：

一頭霧水，PRIVATE USE CODEPOINT這是個(gè)什么意思呢？幸好下面有wiki的解釋：

In Unicode, the Private Use Areas (PUA) are three ranges of code points (U+E000–U+F8FF in the BMP, and in planes 15 and 16) that, by definition, will not be assigned characters by the Unicode Consortium. The code points in these areas can not be considered as standardized characters in Unicode itself. They are intentionally left undefined so that third parties may define their own characters without conflicting with Unicode Consortium assignments. Under the Unicode Stability Policy, the Private Use Areas will remain allocated for that purpose in all future Unicode versions.

咳咳，由于英文水平問題，但我還是勉強(qiáng)翻譯下。大意就是：位于BMP的U+E000–U+F8FF編碼，和第15以及16平面的區(qū)域的編碼，Unicode協(xié)會(huì)表示不會(huì)對(duì)該區(qū)域的編碼指定符號(hào)，且這些區(qū)域編碼不是標(biāo)準(zhǔn)符號(hào)，故意留下未定義的區(qū)域是讓第三方自己去玩。

那什么又是BMP，第一個(gè)平面稱為基本多語(yǔ)言平面（Basic Multilingual Plane, BMP），或稱第零平面（Plane 0）。其他平面稱為輔助平面（Supplementary Planes）。最前面的65536個(gè)字符位，都在BMP中。

好了，回到前面看，U+E10E這個(gè)Unicode剛好落到了（U+E000–U+F8FF）區(qū)間內(nèi)。所以這個(gè)字符是因?yàn)榈谌阶远x的。

網(wǎng)上找到了一份表，http://www.easyapns.com/iphone-emoji-alerts 。U+E10E對(duì)應(yīng)符號(hào)如下：

那框真的是這個(gè)皇冠emoji嗎？因?yàn)槭怯脩絷欠Q，查一下就知道了

事實(shí)證明，確實(shí)沒錯(cuò)。那么既然是emoji表情，為什么iphone（9.3.1）都不能正常解析？這編碼又是怎么被用戶輸入進(jìn)去的？

說到emoji，那我們先來(lái)扒一扒emoji的歷史故事。

emoji表情源于日本，叫做繪（e=圖）文字（moji=字符）。

Emoji were initially used by Japanese mobile operators, NTT DoCoMo, au, and SoftBank Mobile (formerly Vodafone).

日本幾家公司各自定義了一套標(biāo)準(zhǔn)，用兩個(gè)字節(jié)表示符號(hào)，Shift-JIS（日本電腦系統(tǒng)的一種編碼）編碼是從F89F到F9FC。當(dāng)然這已經(jīng)是上世紀(jì)的事情了，其中被廣泛采用的是SoftBank標(biāo)準(zhǔn)，也稱之為SB （SoftBank，這里不是ShaBi的縮寫，咳咳）emoji表情。

發(fā)展到今天，Unicode協(xié)會(huì)把emoji表情納入標(biāo)準(zhǔn)中，但編碼范圍重新劃分了。前面說了，Private Use Areas 是留給第三方用的，不能瞎占用。

在這個(gè)網(wǎng)站查到E10E如下信息：

可以初步懷疑是SoftBank的emoji表情。

恰好手中有臺(tái)舊的華為手機(jī)，有一個(gè)系統(tǒng)自帶的華為輸入法，輸入法里面有一些跟蘋果emoji一樣的表情，只不過數(shù)量沒這么多。下面四個(gè)是華為輸入法鍵盤上的表情：

這四個(gè)表情在Unicode中的標(biāo)準(zhǔn)編碼是：

注意，如果使用charCodeAt方法來(lái)獲取Unicode編碼的時(shí)候要注意了，前面我們提到了該方法有缺陷。簡(jiǎn)單的原因就是JavaScript使用的編碼與utf-8不一樣導(dǎo)致，這里不展開講，有興趣可以看這篇文章。ES6提供了新的接口來(lái)獲取碼點(diǎn)，codePointAt。

輸入的結(jié)果展示如下：

iphone6sp 顯示框框

huawei 顯示空白

雖然在兩臺(tái)機(jī)器的表現(xiàn)形式不一樣，但都是無(wú)法正確顯示，那我們看下這到底是什么編碼。

上面四個(gè)編碼落入的區(qū)域也是在（U+E000–U+F8FF）內(nèi)，然后根據(jù)上面的網(wǎng)站查詢，可以確認(rèn)是來(lái)自SoftBank標(biāo)準(zhǔn)的emoji表情了。

所以只要替換這些編碼就好了。

也就是說SoftBank emoji表情現(xiàn)在的系統(tǒng)基本不支持，因?yàn)橐呀?jīng)過時(shí)了。

但為什么用戶還能夠輸入這些SoftBank emoji呢？原因就在于有些手機(jī)輸入法（相對(duì)古老了）廠商對(duì)emoji的實(shí)現(xiàn)還是參照SoftBank的標(biāo)準(zhǔn)。

因此把SoftBank emoji編碼轉(zhuǎn)換為Unicode標(biāo)準(zhǔn)的就是解決之道。在github上找到了SoftBank與標(biāo)準(zhǔn)emoji Unicode的對(duì)應(yīng)關(guān)系。

有兩種解決方案：

1、轉(zhuǎn)換為html實(shí)體編碼

uE10E -> u1F451 -> 👑

優(yōu)點(diǎn)：

高清，依賴系統(tǒng)編碼；

不需要加載css和emoji圖片，省流量。

缺點(diǎn)：

所有平臺(tái)表情不統(tǒng)一，各系統(tǒng)自定義的圖標(biāo)，風(fēng)格不同，但表達(dá)意思基本一樣

部分平臺(tái)不支持emoji

ios:

android:

2、轉(zhuǎn)換為html標(biāo)簽

code 對(duì)應(yīng)emoji圖標(biāo)的classID，用雪碧圖。

優(yōu)點(diǎn)：

所有平臺(tái)表情統(tǒng)一（如果統(tǒng)一算優(yōu)點(diǎn)的話，有爭(zhēng)議，畢竟Android用戶看習(xí)慣了Android表情）。

缺點(diǎn)：

需要加載額外的css和emoji圖標(biāo)；如果要高清（暫時(shí)無(wú)法找到，圖片會(huì)模糊），則圖標(biāo)會(huì)很大。

綜上，結(jié)合方案一二，在Android版本小于4.4的時(shí)候采用方案二，其他采用方案一。

（左邊為處理前，右邊為處理后）

不同系統(tǒng)的處理結(jié)果

問題來(lái)了，如果遇到了其他編碼標(biāo)準(zhǔn)（google， DoCoMo，KDDI 等等）的表情該怎么辦？如果沒有Unicode的與符號(hào)的映射關(guān)系真是白搭，你絲毫沒有辦法。就像你不學(xué)習(xí)英文單詞，你還想看懂英文文章？

emoji表情不斷在豐富，這也給前端（各種終端）工作者帶來(lái)麻煩，只能盡可能的補(bǔ)上已知的。

https://codepoints.net

http://www.unicode.org/faq/private_use.html#pua1

http://www.ruanyifeng.com/blog/2007/10/ascii_unicode_and_utf-8.html

http://blog.csdn.net/binjly/article/details/47321043

http://computerism.ru/emoji-smiles.htm

http://www.ruanyifeng.com/blog/2014/12/unicode.html

http://blog.csdn.net/ugg/article/details/44225723

https://github.com/iamcal/js-emoji

https://github.com/node-modules/emoji

http://www.fileformat.info/info/emoji/softbank.htm

http://caniemoji.com

http://www.easyapns.com/iphone-emoji-alerts

https://en.wikipedia.org/wiki/Emoji

https://mathiasbynens.be/notes/javascript-unicode