本文由字節(jié)教育-成人與創(chuàng)新前端團(tuán)隊(duì)分享顷霹，本文有修訂和改動翘盖。
1朦蕴、引言
作為開發(fā)人員指厌，工作中我們可能會遇到以下問題：
1）可能你知道 JavaScript 中 '??'.length = 2刊愚，但 '????????'.length 呢？
2）困惑于 Unicode 和 UTF-8 的關(guān)系踩验？
3）學(xué)計(jì)算機(jī)時(shí)會遇到這樣的提問：一個(gè)漢字是幾個(gè)字節(jié)鸥诽？
4）讀取二進(jìn)制數(shù)據(jù)時(shí)，為何有大端序小端序的分別牡借？
5）為何 UTF-8 文件最好存儲為無 BOM 頭格式？
6）數(shù)據(jù)亂碼時(shí)總會看到“錕斤拷”袭异、“燙燙燙”钠龙，這是什么鬼？
以上這些問題都涉及到計(jì)算機(jī)中基礎(chǔ)的知識點(diǎn)——字符集及字符編碼的概念，本篇將從前端開發(fā)人員的視解碴里，讓你徹底搞清并理解這些問題的本質(zhì)沈矿。
2、系列文章
本文是系列文章中的第?5?篇并闲，本系列總目錄如下：
《字符編碼技術(shù)專題(一)：快速理解ASCII细睡、Unicode谷羞、GBK和UTF-8》
《字符編碼技術(shù)專題(二)：史詩級計(jì)算機(jī)字符編碼知識入門帝火，一文即懂！》
《字符編碼技術(shù)專題(三)：徹底搞懂字符亂碼的本質(zhì)湃缎，一篇就夠犀填！》
《字符編碼技術(shù)專題(四)：史上最通俗大小端字節(jié)序詳解，一文即懂嗓违！》
《字符編碼技術(shù)專題(五)：前端必讀的計(jì)算機(jī)字符編碼知識入門》（* 本文）
3九巡、什么是字符集與字符編碼
首先通過 wiki 中關(guān)于字符編碼（Character_encoding）的定義來引入幾個(gè)概念：
Character encoding is the process of assigning numbers to graphical characters, especially the written characters of human language, allowing them to be stored, transmitted, and transformed using digital computers.
The numerical values that make up a character encoding are known as "code points" and collectively comprise a "code space", a "code page", or a "character map".
字符編碼是將數(shù)字分配給圖形字符的過程，特別是人類語言的書寫字符蹂季，使它們能夠使用計(jì)算機(jī)進(jìn)行存儲冕广、傳輸和轉(zhuǎn)換。組成字符編碼的數(shù)值稱為“碼位”偿洁，它們共同組成“代碼空間”撒汉、“代碼頁”或“字符映射”。
這里所說的代碼頁（Code Page）其實(shí)就可以理解為編碼字符集（coded character set）涕滋，如 Unicode睬辐、GBK 字符集等。
簡單來說：字符編碼就是將字符映射為固定的碼位值宾肺，存儲在對應(yīng)的編碼字符集中溯饵。在不同的字符集中，同一個(gè)字符的碼位不同锨用。其中碼位也有翻譯成碼點(diǎn)或者內(nèi)碼丰刊。
4、ASCII 字符集
我們知道在計(jì)算機(jī)存儲數(shù)據(jù)時(shí)要使用二進(jìn)制進(jìn)行表示增拥。而最初計(jì)算機(jī)只在美國使用啄巧，因此人們要考慮如何使用二進(jìn)制來表達(dá) 52 個(gè)英文字母(包括大小寫)、阿拉伯?dāng)?shù)字(0-9)以及常用的符號(如! @ # $ 等)跪者。
于是便有從電報(bào)碼發(fā)展而來的 ASCII（American Standard Code for Information Interchange棵帽，美國信息交換標(biāo)準(zhǔn)代碼）(發(fā)音 /??ski/)編碼。它定義了英文字符和二進(jìn)制的對應(yīng)關(guān)系渣玲，一直沿用至今逗概。
它采用了單字節(jié)編碼方案（SBCS） ，一個(gè)字節(jié)的首位 bit 為 0忘衍，用其余 7 個(gè) bit 來表示 128 個(gè)字符（范圍 0x00-0x7F）逾苫。
具體是：
1）其中 0-31 和 127 (0x00-0x1F 和 0x7F) 為控制字符卿城，共 33 個(gè)。這些字符是不可見的铅搓，用于進(jìn)行終端的換行瑟押、響鈴、刪除等動作星掰；
2）32-126 (0x20-0x7E) 位可見字符多望，共 95 個(gè)，存儲了空格氢烘、0-9 十個(gè)阿拉伯?dāng)?shù)字怀偷、52 個(gè)大小寫英文字母，以及標(biāo)點(diǎn)播玖、運(yùn)算符號等椎工。
雖然現(xiàn)代英語使用 128 個(gè)字符就足夠了，但表示其他語言就遠(yuǎn)遠(yuǎn)不夠了蜀踏。因此當(dāng) ASCII 進(jìn)入歐洲后维蒙，又被擴(kuò)展為了 EASCII(Extended ASCII)，將 7 bit 擴(kuò)展為 8 bit果覆，并且前 127 個(gè)編碼含義和 ASCII 保持一致颅痊。
但 256 個(gè)字符依舊無法解決眾多使用拉丁字母的語言（主要是歐洲語言）問題。于是又?jǐn)U展出了 15 個(gè) ISO 8859 字符集随静。
舉幾個(gè)字符集作為了解：
ISO/IEC 8859-1 (Latin-1) - 西歐語言
ISO/IEC 8859-2 (Latin-2) - 中歐語言
ISO/IEC 8859-3 (Latin-3) - 南歐語言
ISO/IEC 8859-4 (Latin-4) - 北歐語言
...
5八千、中文字符集
5.1概述
前面講到拉丁文所使用是 ASCII 和 EASCII，但在亞洲——主要是中日韓(CJK)——光常用漢字就 6000 多個(gè)燎猛，而漢字總共有 5恋捆、6 萬之多，單靠一個(gè)字節(jié)是遠(yuǎn)遠(yuǎn)沒辦法做到的重绷。
因此聰明的中國人（也可能是日本人）就想到使用雙字節(jié)編碼（DBCS） 來表示一個(gè)漢字沸停，這樣理論上 2 個(gè)字節(jié)可以表達(dá) 65535 個(gè)字符（當(dāng)然很理論，實(shí)際上要少很多）昭卓。
這樣就可以表示大部分常用字符了愤钾，接下來就要講到和中文有關(guān)的 GB 系列（如 GB2312、GBK候醒、GB18030）的字符集了能颁。
其實(shí) GB 就是“國標(biāo)”漢語拼音的首字母，而 GBK 就是“國標(biāo)擴(kuò)展”的意思倒淫，而 GB18030 是在保留 GBK 編碼基礎(chǔ)上再度擴(kuò)展為可變的 4 字節(jié)編碼空間的編碼規(guī)范伙菊。
這里我們著重介紹下 GB2312 的編碼結(jié)構(gòu)。
5.2GB/T 2312
GB2312 全稱《信息交換用漢字編碼字符集·基本集》，收錄了 6763 個(gè)漢字镜硕，682 個(gè)拉丁运翼、希臘、日文假名等字符兴枯。就將其中漢字覆蓋了大陸 99.75% 的使用頻率血淌，足夠大部分的場景使用的。
同時(shí)還把 ASCII 中標(biāo)點(diǎn)符號财剖、阿拉伯?dāng)?shù)字悠夯、英文字符用雙字節(jié)收錄在內(nèi)，這里為了區(qū)別于 ASCII 中的字符峰伙，就將其做成了與漢字等寬的正方型效果（即拉丁字母的兩倍寬）疗疟，以表示和編碼存儲方式一一對應(yīng)。因?yàn)樽址幋a和字寬的對應(yīng)關(guān)系瞳氓，我們這就稱這類字符為「全角」字符，而 ASCII 中的字符則為「半角」字符栓袖。（這種叫法源于日本匣摘，因?yàn)樵谌毡局小敖恰庇小胺綁K”的意思）
接下來看看如何編碼的。規(guī)范將收錄的漢字分成 94 個(gè)區(qū)，每個(gè)區(qū)又包含 94 個(gè)漢字，用所在的區(qū)位來表示一個(gè)字符（這種方法也稱為區(qū)位碼） 种远。每個(gè)字符用 2 個(gè)字節(jié)表示彩掐，其中第一個(gè)字節(jié)稱為「高位字節(jié)」表示分區(qū)號，第二個(gè)字節(jié)稱為「低位字節(jié)」表示區(qū)段內(nèi)的碼位甘改。另外實(shí)際 GB2312 僅用了 87 個(gè)區(qū)，88-94 區(qū)保留待擴(kuò)展。
為了避開 ASCII 中前面的 31 個(gè)不可見控制符和空格嘴办，在區(qū)位碼基礎(chǔ)上 +32（0x20），這樣獲得的編碼就稱為 ISO-2022 國標(biāo)碼买鸽。
但是實(shí)際使用時(shí)涧郊，英文字符和漢字混用的情況很常見，國標(biāo)碼僅避讓開了控制字符眼五，依然和 ASCII 的英文字符有重合妆艘，因此決定在國標(biāo)碼的基礎(chǔ)上將單字節(jié)的最高位 bit 存為 1，即在國標(biāo)碼上 +128（0x80）看幼，也就是區(qū)位碼上 +160 （0xA0）批旺，這樣就完美的避讓開了 ASCII 字符區(qū)間。
這樣種編碼就叫做 EUC-CN 機(jī)內(nèi)碼：
EUC-CN 機(jī)內(nèi)碼 = 區(qū)位碼 + 160
而目前 GB2312 所采用的就是 EUC 這種主流編碼方式诵姜，以便于兼容 ASCII 碼汽煮。同時(shí)也可以根據(jù)最高位 bit 來判斷是讀取 1 個(gè)字符（ASCII）還是 2 個(gè)字符來進(jìn)行解析。在 GB2312 內(nèi)，高位字節(jié)范圍 0xA1-0xF7（01-87 區(qū)+160 或 0xA0）逗物，低位字節(jié)范圍 0xA1-0xFE（01-94 + 160 或 0xA0）搬卒。
以“節(jié)”為例：
1）區(qū)位碼是 29-58；
2）EUC 編碼就是 <29+160, 58+160> = <189, 218>翎卓；
3）十六進(jìn)制就是 <0xBD, 0xDA>契邀。
5.3GBK/GB18030
但是新的問題來了，GB2312 僅收入了 6763 個(gè)常用的漢字失暴，一些在標(biāo)準(zhǔn)推出以后的簡化字（如 啰）坯门、港澳臺使用的的繁體字、某些領(lǐng)導(dǎo)人的名字（朱镕基的镕）逗扒，以及各地區(qū)戶籍中用到奇奇怪怪的名字古戴、古籍中的漢字都沒法正確表示。
因此在 GB2312 的基礎(chǔ)上又?jǐn)U展出了 GBK 和 GB18030矩肩，并且向下兼容（嚴(yán)格來講 GB18030 完全兼容 GB2312,基本兼容 GBK）现恼。
GBK 的基本原理就是繼續(xù)擴(kuò)展了 GB2312 中未使用的雙字節(jié)空間，字符多達(dá) 23940 個(gè)黍檩。而 GB18030 則更為激進(jìn)叉袍，干脆將存儲空間變成可變的 1、2刽酱、4 字節(jié)喳逛，理論上可以存儲 161 萬個(gè)字符，完全涵蓋 Unicode 范圍棵里。同時(shí) GB18030 還收錄了中日韓润文、繁體字、少數(shù)民族文字等多種語言殿怜。
5.4Big5
于此同時(shí)典蝌，海峽對岸的程序員也發(fā)明出了一套自己的繁體中文標(biāo)準(zhǔn)，由于起初項(xiàng)目名稱是「五大中文套裝軟件」稳捆，因此稱為 Big5赠法，也叫大五碼。記得當(dāng)年想要玩臺灣“流入”的游戲乔夯，MagicWin 這類的轉(zhuǎn)碼軟件是裝機(jī)必備砖织。
6、Unicode 字符集
隨著世界各個(gè)地區(qū)編碼方式越來越多末荐，給不同地區(qū)間數(shù)據(jù)傳輸造成非常大的困難侧纯，比如一個(gè)從中國發(fā)送到日本郵件的，在不知道其編碼的情況下甲脏，就會出現(xiàn)亂碼眶熬。
因此終于有人開始想用一種更加通用的方案妹笆，來涵蓋世界上所有的字符和符號——這就是 Unicode，如其名字本身的含義一樣娜氏。
首先 Unicode 也采用了 16 位的編碼空間拳缠，即 2 個(gè)字節(jié)表示一個(gè)字符，用 "U+"接 4 個(gè)十六進(jìn)制數(shù)字表示（例如U+4AE0）贸弥，每個(gè)字符分配一個(gè)唯一的「碼點(diǎn)」（CodePoint窟坐，也稱碼位）。同時(shí)又定義了 17 個(gè)編組绵疲，每組稱為一個(gè)「平面」（Plane）哲鸳。這樣字符范圍從?0x00000 - 0x10FFFF，這樣就可以最多表示?17 * 65536?也就是 100多萬個(gè)字符盔憨，完全可以存儲全世界所有的語言和符號了徙菠。
這其中將常用的字符存放在第一個(gè)編組，即 0 號平面（Plane 0）郁岩，也稱之為「基本多文種平面 」（BMP - Basic Multilingual Plane）婿奔，其范圍是 0x0000 - 0xFFFF 。而 1-16 號平面被稱為「輔助平面」（Supplementary Planes）驯用，用于存儲很少使用的文字或者圖形符號（emoji 表情符號就存于這些平面）脸秽，其范圍是 0x10000-0x10FFFF。
Unicode 字符表的范圍涵蓋的字符和符號非常廣蝴乔，不僅收錄了表情符號、麻將驮樊、音樂符號等表意符號外薇正，還收錄了一些早已不再使用的文字，比如甲骨文囚衔、古埃及的圣書體挖腰，甚至收錄了為影視劇而創(chuàng)造的語言——克林貢語。并且還在持續(xù)更新中练湿，截止此文完成猴仑，最近的一次更新是在2022年9月。
但是這里有個(gè)比較嚴(yán)重的問題：
1）不同碼位的字符使用不同的字符長度肥哎，但計(jì)算機(jī)無法知道到底是按照 2 個(gè)還是 4 個(gè)字符解析辽俗；
2）即便只使用英文字符前一個(gè)字節(jié)也必須是 0，嚴(yán)重浪費(fèi)了空間篡诽。
由于這個(gè)問題導(dǎo)致 Unicode 的在初期完全沒法推廣崖飘，直到互聯(lián)網(wǎng)的普及，急需一種對 Unicode 字符的編碼方式出現(xiàn)杈女，這就是 ****UTF（Unicode Transformation Format）朱浴。在 UTF 中又出現(xiàn)了 UTF-8吊圾、UTF-16、UTF-32 這些不同的編碼方式翰蠢。
7、UTF-32
首先梁沧，人們想到的就是干脆所有字符直接用 4 個(gè)字節(jié)存儲檀何，不足 4 位的就補(bǔ) 0 代替。但是這樣簡單粗暴趁尼，尤其僅使用英文的數(shù)據(jù)埃碱，會造成了空間的極大浪費(fèi)。
比如拉丁字母 A 的 Unicode 碼點(diǎn)為?U+0065酥泞，十六進(jìn)制為 0x41砚殿，如果使用 UTF-32 編碼就是?0x00000041。
于是人們又開始設(shè)計(jì)一種可以節(jié)省空間的編碼方式——UTF-8芝囤。
8似炎、UTF-8
UTF-8 最大的特點(diǎn)是可變長編碼，它使用 1-4 個(gè)字節(jié)表示一個(gè)字符悯姊。
它的編碼方式如下：
1）由于 Unicode 在 0+0000-0+007F 范圍和 ASCII 完全相同羡藐，因此使用單字節(jié)表示（這樣 ASCII 和 UTF-8 的編碼一樣，是完全兼容的）悯许。
2）在大于 0+007F 的字符時(shí)仆嗦，是由 1 個(gè)前導(dǎo)字節(jié)（leading bytes）和 n 個(gè)（n >=1 ）尾字節(jié)（trailing bytes）的多字節(jié)結(jié)構(gòu)組成。前導(dǎo)字節(jié)從最左側(cè)起用 1來表示這個(gè)字符有多少位先壕，直到遇到 0 為止瘩扼。尾字節(jié)前兩位都是 10，其余的 bit 位就是可用編碼空間垃僚。
比如：
1）第一個(gè)字節(jié)是 0xxxxxxx集绰，就表示該字符只有 1 個(gè)字節(jié)；
2）第一個(gè)字節(jié)是 110xxxxx谆棺，表示該字符有 2 個(gè)字節(jié)栽燕，第二個(gè)字節(jié)是 10xxxxx；
3）第一個(gè)字符是 1110xxxx改淑，表示該字符有 3 個(gè)字節(jié)碍岔，后面字節(jié)分別是 10xxxxx 10xxxxx；
4）第一個(gè)字節(jié)是 11110xxx溅固，表示該字節(jié)有 4 個(gè)字節(jié)，后面字節(jié)分別是 10xxxxx 10xxxxx 10xxxxx询吴。
這里 x 就表示可用的編碼空間，這也就是 UTF-8 中 8 表示至少 8 位表示一個(gè)字符猛计，同時(shí)也是以 8 位為一組實(shí)現(xiàn)可變字節(jié)的編碼方式。（這里之所以跳過了 10xxxxxx勾拉，是因?yàn)?10 表示尾字節(jié)）
以下就是完整編碼方式，當(dāng)然 5盗温、6 字節(jié)的編碼方式不會出現(xiàn)，因?yàn)橐呀?jīng)遠(yuǎn)超 Unicode 最大碼點(diǎn)范圍 U+10FFFF 了斧蜕。
接下來我們用“兔” 和 emoji “🐰” 來舉例批销，來說明下 UTF-8 是如何編碼的均芽。
兔：
1）碼點(diǎn)為 U+5154掀宋；
2）二進(jìn)制表示為 101000101010100布朦；
3）從末尾按 6 個(gè) bit 分組 101 000101 010100；
4）需要 3 個(gè)字節(jié)澄惊，則開頭插入 1110掸驱，中間不足 8 位用 0 補(bǔ)足，剩余前面插入 10，則得到 11100101 10000101 10010100鬼癣；
5）轉(zhuǎn)為十六進(jìn)制待秃，E5 85 94章郁。
🐰 的 emoji：
1）碼點(diǎn)為 U+1F430暖庄；
2）二進(jìn)制為 11111010000110000培廓；
3）從末尾按 6 個(gè) bit 分組 11111 010000 110000医舆；
4）第一部分為 5 位蔬将，插入 1110 位后占 9 位霞怀，超出一個(gè)字節(jié)廉沮，所以前面補(bǔ)一個(gè)字節(jié)滞时，用 4 個(gè)字節(jié)表示坪稽。不足 8 位的用 0 補(bǔ)足窒百。則得到 11110000 10011111 10010000 10110000篙梢；
5）轉(zhuǎn)為十六進(jìn)制渤滞，F(xiàn)0 9F 90 B0震糖；
由于 JS 中 encodeURI 是按照 UTF-8 進(jìn)行百分號編碼吊说，因此感興趣的同學(xué)可以進(jìn)行驗(yàn)證下（代碼如下所示）。
encodeURI('兔');
// %E5%85%94
encodeURI('🐰');
// %F0%9F%90%B0
除了相對于 4 字節(jié)編碼更省空間外雅宾，UTF-8 編碼還有以下比較優(yōu)秀的特性眉抬。
1）ASCII 是 UTF-8 的一個(gè)子集蜀变，一個(gè)純 ASCII 字符串也是一個(gè)合法的 UTF-8 字符串。因此現(xiàn)存的 ASCII 數(shù)據(jù)可以不經(jīng)修改即可使用寒瓦。
2）單字節(jié)范圍 0x00-0x7F杂腰，而多字節(jié)的前導(dǎo)字節(jié)范圍總是在?0xC0-0xFD颈墅，尾字節(jié)都在?0x80-0xBF?中，三者完全沒有重疊芹橡。通過范圍就可以確定字節(jié)的類型煎殷，如果字節(jié)流在傳輸時(shí)中斷豪直，不完整的字節(jié)也不會被解碼弓乙。這樣數(shù)據(jù)有損壞暇韧、丟失，影響的范圍也會很小涂乌。試想下湾盒，如果有一個(gè)按照每 4 個(gè)字節(jié)為一組的編碼方法历涝，如果丟失了第一個(gè)字節(jié)的數(shù)據(jù)，那么繼續(xù)按照 4 字節(jié)一組的方式讀取數(shù)據(jù)分衫，后面的數(shù)據(jù)都將無法讀取蚪战。
3）另外由于前導(dǎo)字節(jié)和尾字節(jié)范圍互不重疊邀桑，即便從一個(gè)字符的某個(gè)中間字節(jié)開始讀取，也不會錯(cuò)把它和下一個(gè)字符拼接錯(cuò)捏萍。這種特性也叫自同步碼令杈。比如逗噩，“兔子”的編碼為?E5 85 94 / E5 AD 90机打，你不會錯(cuò)把?85 94 E5?或者?AD 90?當(dāng)做一個(gè)字符残邀，因?yàn)楦静淮嬖谶@樣規(guī)則的 UTF-8 編碼芥挣。
4）僅通過首字節(jié)就能確定整體字節(jié)長度，而無需等待下一個(gè)字節(jié)的讀取蹋砚。
5）理論 6 個(gè)字節(jié)可以存放 2^31 個(gè)字符坝咐，即 21 億個(gè)字符！即便是 4 字節(jié)也可以存放 200 多萬個(gè)字符泽篮。其范圍已超 Unicode 的容量了帽撑。
6）UTF-8 中未使用 0xFE 和 0xFF。
7）UTF-8 字節(jié)串的排列順序是固定的专筷，和系統(tǒng)無關(guān)磷蛹。沒有字節(jié)序（即是按大端序還是小端序的先后順序）的問題。因此也無需使用 BOM 頭（雖然其 BOM 頭是 0xEF 0xBB 0xBF槽驶，但僅表示 UTF-8 編碼格式掂铐，不表示字節(jié)順序）。
雖然 UTF-8 有諸多優(yōu)勢辱姨，但是也有缺點(diǎn)：
1）中日韓文字至少需要 3 個(gè)字節(jié)存儲雨涛，比 GBK 這類雙字節(jié)存儲要多一個(gè)字節(jié)；
2）由于其是變長字節(jié)侣肄，一個(gè)字符可能是 1稼锅、2、3 個(gè)字節(jié)锥债，因此當(dāng)計(jì)算一組字節(jié)中包含多少個(gè)字符登夫，就要從頭遍歷恼策，才能確定到底有多少個(gè)字符。當(dāng)我們需要獲取指定位置的字符時(shí)狮斗，依然要從頭遍歷碳褒。這也為程序的實(shí)現(xiàn)帶來了很大的麻煩。
因此：一些程序在內(nèi)部處理字符串時(shí)专酗，就使用了另外一種編碼方式 UTF-16，其中 JavaScript佑笋、Python 就使用了這種編碼方式來存儲字符串蒋纬。
9、UTF-16
UTF-16 也采用了變長的編碼方式碾阁。使用 2 個(gè)或者 4 個(gè)字節(jié)表示一個(gè)字符宪睹。
其規(guī)則是：
1）在基本平面 BMP 內(nèi)（U+0000 至 U+FFFF）的字符用 2 個(gè)字節(jié)表示亭病；
2）在輔助平面內(nèi)（U+10000 至 U+10FFFF）的字符用 4 個(gè)字節(jié)表示。
其中 BMP 的字符直接使用 Unicode 碼點(diǎn)對應(yīng)即可，比如“兔”的碼點(diǎn)?U+5154，UTF-16 編碼就是?0x5154迹蛤。
可是 BMP 外盗飒，要如何使用 4 個(gè)字節(jié)表示呢？假如我們使用 UTF-32 的方式宣渗，直接使用碼點(diǎn)映射會遇到什么問題？
還以“🐰”為例鞍恢，其碼點(diǎn)是 U+1F430。如果直接映射為 0x0001F430旭寿，頭 2 個(gè)字節(jié) 0x0001 對應(yīng)的字符在 BMP 中已經(jīng)存在肩祥，這樣在讀取數(shù)據(jù)時(shí)就無法區(qū)分到底是按照 2 字節(jié)解析，還是按照 4 個(gè)字節(jié)解析了将饺。
幸而在 BMP 中，從 U+D800 到 U+DFFF 是一個(gè)永遠(yuǎn)保留不做映射的空段掖蛤，于是 UTF-16 將輔助平面內(nèi)的字符 —— 共需要 20 個(gè) bit 表示（由 0x10FFFF - 0x100000 = 0xFFFFF 計(jì)算得來） —— 拆分成 2 段，前 10 個(gè) bit 位映射到 U+D800 - U+DBFF（正好 1024 個(gè)）器赞，后 10 個(gè) bit 映射到 0xDC00 - 0xDFFF（也正好 1024 個(gè)）。這樣剛好就可以在范圍互不重復(fù)的情況下潘懊，用 4 個(gè)字節(jié)表示一個(gè)字符了。
這種用 4 個(gè)字節(jié)表示的方式，就被稱作「代理對」（Surrogate Pair）奢啥，高位的 10 bit 被稱為「前導(dǎo)代理」（lead surrogates）桩盲，低位 10 bit 被稱為「后尾代理」（trail surrogates）捞蛋。
其具體的算法如下：
1）BMP 內(nèi)字符，直接使用碼點(diǎn)作為對應(yīng)的字節(jié)搬设，長度為 2 個(gè)字節(jié)；
2）輔助面內(nèi)的字符：
a. 碼位減去 0x10000；
b. 高位的 10 bit 的值加上 0xD800 阀蒂，得到前導(dǎo)代理；
c. 低位的 10 bit 的值加上 0xDC00 弟蚀，得到后尾代理蚤霞。
用公式計(jì)算如下：
// 高位
H = Math.floor((c-0x10000) / 0x400)+0xD800
// 低位
L = (c - 0x10000) % 0x400 + 0xDC00
我們依舊使用“🐰”來舉例，看下 UTF-16 是如何進(jìn)行編碼的义钉。
🐰：
1）碼點(diǎn)為 U+1F430昧绣；
2）減去 0x10000捶闸，為 0xF430夜畴；
3）二進(jìn)制為 1111010000110000；
4）前 10 bit 111101删壮，十六進(jìn)制 0x3D贪绘。后 10 bit 0000110000，十六進(jìn)制 0x30央碟；
5）分別加上 0xD800 和 0xDC00税灌，得到 0xD83D 和 0xDC30；
6）最終得到 D8 3D DC 30亿虽。
JS 中 escape 方法（已不推薦菱涤，這里僅驗(yàn)證用）返回的就是 UTF-16 編碼，可以進(jìn)行驗(yàn)證：
escape('🐰')
// %uD83D%uDC30
同時(shí) ES6 中支持用 Unicode 碼點(diǎn)和 UTF-16 編碼表示一個(gè)字符洛勉，也可驗(yàn)證：
'\u{1F430}'== '\uD83D\uDC30'
// true
由于前導(dǎo)代理粘秆、后尾代理、BMP 中的有效字符的碼位收毫，三者互不重疊攻走，因此在檢查字符時(shí)殷勘，可以很容易的確定字符的邊界。這也意味著 UTF-16 也是一種自同步的編碼方式陋气，這點(diǎn)和 UTF-8 是一樣的劳吠。
UTF-16 相對于 UTF-8 更容易進(jìn)行隨機(jī)訪問和索引，是因?yàn)?UTF-16 中每個(gè)字符都使用固定的2個(gè)或4個(gè)字節(jié)表示巩趁，因此可以通過簡單的數(shù)學(xué)運(yùn)算來快速計(jì)算出每個(gè)字符的位置痒玩。而 UTF-8 需要解析整個(gè)數(shù)據(jù)流才能確定每個(gè)字符的位置，這使得 UTF-8 在進(jìn)行隨機(jī)訪問和索引時(shí)比 UTF-16 更加復(fù)雜和耗時(shí)议慰。
10蠢古、UCS-2
在談及 UTF-16 時(shí)，通常會涉及到 UCS-2 的概念别凹，這里著重講下兩者的區(qū)別草讶。
UCS-2 是 Universal Character Set coded in 2 octets 的簡稱，由于 1989 年 UCS 標(biāo)準(zhǔn)發(fā)布時(shí)炉菲，只有 Unicode 基本面字符堕战，因此使用 2 個(gè)字節(jié)就可以表示一個(gè)字符了。
而 1996 年 UTF-16 發(fā)布時(shí)拍霜，已經(jīng)擴(kuò)展出了輔助平面嘱丢，可使用代理對方式表示輔助平面的字符了，因此 UTF-16 已明確表示是 UCS-2 的超集祠饺。
所以目前 UCS-2 已經(jīng)是過時(shí)的叫法了越驻，UTF-16 已經(jīng)取代了 UCS-2 的概念。
如果某個(gè)程序說自己支持 UCS-2 可能就意味著僅支持 BMP 內(nèi)的字符集道偷。
11缀旁、大端序和小端序
將字符轉(zhuǎn)換為 UTF-16（或 UTF-32） 后，在使用時(shí)需要讀取并存儲在內(nèi)存中勺鸦。以“乙”字為例并巍，轉(zhuǎn)成 UTF-16 后，編碼為?0x4E59换途，需要用 2 個(gè)字節(jié)來存儲——0x4E 0x59履澳。
如果 4E 在前，59 在后怀跛，我們就稱作為大端序（Big-Endian）：
內(nèi)存地址???? 內(nèi)存值
0x00000000? 4E
0x00000001? 59
反之 59 在前距贷，4E 在后，就稱之為小端序（Little-Endian）：
內(nèi)存地址???? 內(nèi)存值
0x00000000? 59
0x00000001? 4E
之所以會有這樣不同的存儲方式吻谋，是因?yàn)橛械南到y(tǒng)或者處理器忠蝗，在處理多字節(jié)數(shù)據(jù)時(shí)，會從低位內(nèi)存地址到高位內(nèi)存地址的順序讀取數(shù)據(jù)漓拾，因此為了保證讀取后數(shù)據(jù)的正確阁最，就采用了不同字節(jié)序（Endianness）的方式戒祠。
為了標(biāo)識一段數(shù)據(jù)的字節(jié)序，通常使用字節(jié)順序標(biāo)記 （Byte-Order Mark速种，BOM）來進(jìn)行標(biāo)識姜盈。通常 BOM 會出現(xiàn)在文件、字節(jié)流的頭部配阵，用來標(biāo)識接下來數(shù)據(jù)的字節(jié)順序馏颂。
在 UTF-16，0xFEFF 表示大端序棋傍，0xFFFE 表示小端序救拉。
我們來驗(yàn)證下，使用 VSCode 安裝 HexEditor 插件瘫拣，然后新建一個(gè)空白文件亿絮，輸入“乙”和“🐰”，然后分別使用兩種編序麸拄，通過 HexEditor 查看派昧。
UTF-16 BE：
UTF-16 LE：
另外 UTF-8 也存在 BOM 頭，值為?0xEF 0xBB 0xBF拢切。但它只用來標(biāo)識文件的編碼方式斗锭，而不用來說明字節(jié)順序。因?yàn)?UTF-8 本身有著固定的編碼順序失球，字節(jié)序?qū)τ?UTF-8 來說毫無意義。
在實(shí)際使用中帮毁，也應(yīng)該盡量避免帶 BOM 頭的 UTF-8实苞，因?yàn)?BOM 頭可能會影響一些程序的解析器（如 Unix下的Shebang）的處理。
另外由于 UTF-8 是一種稀疏的編碼烈疚，很大一部分可能的字符組合不會產(chǎn)生有效的 UTF-8 文本黔牵，因此許多程序的在解析 UTF-8 文件時(shí)，使用啟發(fā)式的分析方法可以很有把握地檢測出文件是否使用 UTF-8爷肝，而無需加入 BOM猾浦。
PS：關(guān)于大小端字節(jié)序問題，可以詳讀另一篇《史上最通俗大小端字節(jié)序詳解灯抛，一文即懂金赦！》。
12对嚼、錕斤拷燙燙燙
12.1概述
“錕斤拷”和“燙燙燙”恐怕是程序界中最經(jīng)典的故事（事故）之一了夹抗，了解了前面的編碼知識，就會很容易理解它的由來了纵竖。
12.2錕斤拷
由于 Unicode 字符集在不斷更新中漠烧，因此會出現(xiàn) A 系統(tǒng)發(fā)送的字符杏愤，在 B 系統(tǒng)中無法識別的情況。
于是 Unicode 規(guī)定對于無法識別的字符已脓，一律使用 ?（0xFFFD） （Replacement character） 字符來代替珊楼。
而?0xFFFD?在 UTF-8 編碼下為?0xEF 0xBF 0xBD，當(dāng)多 ? 出現(xiàn)時(shí)度液，就會產(chǎn)生連續(xù)的?0xEF 0xBF 0xBD 0xEF 0xBF 0xBD厕宗。
如果這些字符又被使用了 GB 編碼的程序中打開，就會按照 GB 雙字節(jié)編碼將其解析恨诱。這樣剛好就對應(yīng)了 「0xEFBF 錕」 媳瞪、「0xBDEF 斤」、「0xBFBD 拷」 這幾個(gè)字照宝。
12.3燙燙燙
C\C++ 編譯器在 debug 模式下蛇受，引入的一種內(nèi)存保護(hù)機(jī)制，會給特定的內(nèi)存賦一個(gè)特定的初值厕鹃。其中未被初始化的棧內(nèi)存兢仰，會被寫入 0XCC。當(dāng)連續(xù)的 0xCCCC 在 GB 編碼下就是「0xCCCC 燙」了剂碴。
當(dāng)然一千人眼中有一千個(gè)哈姆雷特把将，程序員也是如此察蹲。比如臺灣是“嚙踝蕭”亚兄，而日本是“フフフフフフ”了膳叨。
13、JavaScript 與 Unicode
13.1薛定諤的 length
前面我們提到 JavaScript 中 '😁'.length = 2悉默，要說明這個(gè)問題之前跟磨，先簡單介紹下 JavaScript 與編碼的歷史僵蛛。
1990 年 UCS-2 編碼發(fā)布姿鸿，1995 年 JavaScript 誕生相速，第一個(gè) JS 解釋器被使用旺隙，1996 年 UTF-16 發(fā)布周拐。
從時(shí)間線上來看 JavaScript 解釋器只能采用了 UCS-2 的編碼方式勾给。而 length 統(tǒng)計(jì)的是代碼單元而非真正的字符數(shù)量桩警，因此按照 UCS-2 的編碼方式，每個(gè)字符由 2 個(gè)字節(jié)構(gòu)成术瓮，即兩個(gè) 2 字節(jié)組成字符的 length = 1康聂。
而 ?? 是輔助平面的字符，其 UTF-16 的編碼為?D8 3D DE 01胞四，因此 JavaScript 會把它當(dāng)做?0xD83D?和?0xDE01?兩個(gè)字符恬汁。這也就是 length = 2 的原因。
除 length 以外，JavaScript 中和字符串處理相關(guān)的函數(shù)欲诺，大都存在這類問題谆刨。
如：
vars = "🐰";
s.length // 2
s.charAt(0) // '\uD83D'
s.charAt(1) // '\uDC30'
s.charCodeAt(0) // 55357
s.charCodeAt(1) // 56368
vars = "🐰子";
s.substring(1); // '\uDC30子'
s.slice(1); // '\uDC30子'
/^.$/.test('🐰') // false
13.2ES6 的字符處理
但在 ES6 中，大大增強(qiáng)了對 Unicode 的支持约巷，提供了新的方法解決了以上問題。
為了保持兼容旱捧，length 屬性還是原來的行為方式独郎。為了得到字符串的正確長度踩麦，可以采用如下的方式：
[...str].length;
// or
Array.from(str).length
原 Unicode 表示字符法，僅支持 \uxxxx 的表示氓癌，僅支持 \u0000 - \uffff 范圍谓谦。如：“兔”也可以用 \u5154 表示：
vara = '\u5154';
a == '兔'// true
而超出 \uffff 的部分需要使用雙字節(jié)方式表示，如：“🐰”需要用 \uD83D\uDC30 表示顽铸，而不能用碼位值 \u1F430 表示：
vara = ' \uD83D\uDC30';
a == '🐰'// true
vara = '\u1F430';
// '?0'
而在 ES6 中只要將碼點(diǎn)放入 {} 中茁计，即可正確表示其含義：
vara = '\u{1F430}';
// 🐰
ES6 新增了幾個(gè)專門處理 4 字節(jié)碼點(diǎn)的函數(shù)，如：
1）String.fromCodePoint()：從 Unicode 碼點(diǎn)返回對應(yīng)字符谓松；
2）String.prototype.codePointAt()：從字符返回對應(yīng)的碼點(diǎn)星压；
3）String.prototype.at()：返回字符串給定位置的字符。
ES6 正則提供了 u 修飾符鬼譬，對正則表達(dá)式添加 4 字節(jié)碼點(diǎn)的支持：
// '\u{1F430}'
/^.$/.test('🐰'); // false
/^.$/u.test('🐰'); // true
vars = '\u0065\u0323\u0301'; // '??'
/^.$/.test(s); // false
/^.$/u.test(s); // false
13.3length 依舊不準(zhǔn)的合成字符
上面解釋了為什么 length=2娜膘，是否意味著 length 非 1 即 2 呢？別急优质，我們運(yùn)行下 '👨👩👧👦'.length竣贪。
居然 length=11，為什么整整齊齊的一家人要這么長巩螃？這到底發(fā)生了什么演怎？
要解釋這個(gè)問題，就要講到 Unicode 的合成字符（combining character）避乏。
在一些語言中爷耀，會在字符的上面添加一些符號，以表示不同的發(fā)音或表示不同的含義拍皮。例如：漢語拼音有 ā 的音標(biāo)歹叮、ü 上面的兩點(diǎn)，法語和西班牙語中的 é 表示重音铆帽，越南國語字中的 ? 表示一個(gè)字母咆耿。
而在 Unicode 中有兩種表示方法：
1）使用一個(gè)獨(dú)立的碼點(diǎn)，例如 ? 的碼點(diǎn)為 U+00D4爹橱；
2）使用基本字符+**附加符號**組合的方式（如 O 的碼點(diǎn)是 U+004F萨螺，揚(yáng)抑符 ? 的碼點(diǎn)是 U+0302，組合后同樣展示 ?愧驱，其表意與第一種相同）慰技。
'\u00d4'
// ?
'\u004f\u0302'
// ?
這兩種方式表示雖然在視覺和語義上含義相同，但是在 js 中卻無法理解：
'\u004f\u0302'== '\u00d4'
// false
因此冯键，在 ES6 中提供了?String.prototype.normalize()惹盼，用來將字符的不同表示方法統(tǒng)一為同樣的形式庸汗，稱為 Unicode 正規(guī)化（該方法有局限性惫确，后文會講）。
'\u004f\u0302'.normalize() == '\u00d4'
// true
'\u004f\u0302'.normalize().codePointAt(0).toString(16)
// 'd4'
那么回到 '👨👩👧👦'.length 問題上來，這個(gè) emoji 就使用了合成符號表示（這個(gè)表情沒有單獨(dú)的碼點(diǎn)）改化，其組合是由 7 個(gè) Unicode 組合而成掩蛤，分別是 ['👨', '', '👩', '', '👧', '', '👦']， 使用了 U+ 200D 零寬連字符（Zero-Width Joiner陈肛，ZWJ）將四個(gè) emoji 鏈接揍鸟。
這類表情也被稱為 Emoji ZWJ Sequences ：
而 👨 👩 👧 👦 的 length 分別為 2，而零寬連字符的 length 為 1句旱，因此最終 length 就是 24 + 31 = 11阳藻。
通過下面的方式也可以驗(yàn)證其組合：
[...'👨👩👧👦']
// ['👨', '', '👩', '', '👧', '', '👦']
'\u{1F468}\u{200D}\u{1F469}\u200D\u{1F467}\u200D\u{1F466}'
// 👨👩👧👦
當(dāng)然這里想通過 normalize() 判斷是否等價(jià)是不行的，首先 👨👩👧👦 沒有獨(dú)立的碼點(diǎn)谈撒， 其次該方法目前不能識別三個(gè)或三個(gè)以上字符的合成腥泥。
[...'👨👩👧👦'.normalize()];
// ['👨', '', '👩', '', '👧', '', '👦']
// '\u0065\u0323\u0301' => '??'
[...'??'.normalize()]
// ['?', '?']
13.4合成字符的大麻煩
上面提到關(guān)于 Unicode 的問題不僅限于 JavaScript，在 Python啃匿、Java 等語言中也會遇到蛔外。通常這類合成符號在實(shí)際開發(fā)中會造成很多棘手的問題。
13.4.1）input 的 maxlength：
在設(shè)置 input 的 maxLength 屬性時(shí)溯乒，就會遇到不同瀏覽器的差異夹厌。
<input maxlength="10">
Chrome 將 👨👩👧👦 粘貼后，會按照 String.prototype.length 進(jìn)行裁剪裆悄，多出的字符會被裁剪掉：
例子在這里：Safari（PC 16.3+Moblie）則會按照實(shí)際字符個(gè)數(shù)計(jì)算：
在華為默認(rèn)的瀏覽器測試矛纹，行為和 Chrome 的相同：
該問題在開發(fā)多語言業(yè)務(wù)中，可能會更加明顯（如后臺的字符數(shù)限制灯帮、前端展示等）崖技。如果希望正確計(jì)算需要使用三方庫，例如：https://github.com/orling/grapheme-splitter?（拋磚引玉钟哥，未驗(yàn)證覆蓋情況）迎献。
13.4.2）帶音標(biāo)的文字：
在一些場景下，會有多個(gè)附加音標(biāo)修飾一個(gè)字符的情況腻贰。例如 '??' 是由字母“e” \u0065吁恍、尖音符 “??” ****\u0301 、 下句點(diǎn) ****“??” \u0323 ****組成播演。其中后兩個(gè)音標(biāo)的順序可互換冀瓦， 甚至也可以是 '?' + '?' 或者 'é' + '?' 的組合。
'\u0065\u0301\u0323'; // ??
'\u0065\u0323\u0301'; // ??
'\u1eb9\u0301'; // '?' + '?'
'\u00e9\u0323'; // 'é' + '?'
這時(shí)要使用正則匹配字符變得異常復(fù)雜写烤。
雖然 Unicode 屬性轉(zhuǎn)義表達(dá)式（Unicode property escapes）翼闽，但可惜的是ES2018 以前的版本并不支持，因此可以考慮使用 XRegExp 來實(shí)現(xiàn)洲炊。
// 例子在這里
varreg = XRegExp('\pL\pM*', 'g');
XRegExp.match('??', reg);
// ["??"]
其中 \pL 和 \pM 的含義如下：
1）\p{L} or \p{Letter}: any kind of letter from any language感局，匹配一個(gè)字母尼啡；
2）\p{M} or \p{Mark}: a character intended to be combined with another character (e.g. accents, umlauts, enclosing boxes, etc.). 匹配附加符號。
雖然在 ES2018 中引入了 Unicode 屬性轉(zhuǎn)義符询微，但在瀏覽端上依然要考慮使用 XRegExp 來實(shí)現(xiàn)崖瞭，當(dāng)然可以考慮在服務(wù)端處理，因?yàn)?Python 3.6撑毛、Perl 5.24 书聚、Ruby 2.4 、.NET 4.6藻雌、Go 10 等已經(jīng)支持這些表達(dá)式了雌续，當(dāng)然不同語言的支持程度可能略有不同。
13.5數(shù)據(jù)庫中存儲表情
另外在數(shù)據(jù)庫存儲時(shí)使用了不同的表示方式存儲同一含義的字符胯杭，會導(dǎo)致檢索失敗西雀。MySQL 存儲時(shí)也要考慮使用 utf8mb4_unicode 編碼格式，才能正確存儲表情符歉摧。
14艇肴、本文小結(jié)
最后關(guān)于 Unicode 字符編碼模型，可以概況為四個(gè)層級叁温。
1）抽象字符庫（ACR, Abstract Character Repertoire）：即要編碼的字符再悼，比如某些字母表和符號集。這一層級會將語言中的字符進(jìn)行抽象膝但。
2）編碼字符集（CCS, Coded Character Set）：從抽象字符庫到一組非負(fù)整數(shù)（即代碼點(diǎn)）的映射冲九。這一層級可以理解為字符到 Unicode 碼點(diǎn)映射的過程。
3）字符編碼形式（CEF, Character Encoding Form）：從代碼點(diǎn)到特定寬度（比如32-bit整數(shù)）的代碼單元序列的映射跟束。這一層級理解為 UTF-8莺奸、UTF-16、UTF-32 的編碼過程冀宴。
4）字符編碼方案（CES, Character Encoding Scheme）：從代碼單元序列到字節(jié)序列的映射灭贷。這一層級就涉及到了如大端序、小端序的設(shè)計(jì)和存取過程略贮。
附錄：更多IM技術(shù)精華文章
[2]?零基礎(chǔ)IM開發(fā)入門(一)：什么是IM系統(tǒng)甚疟？》
[3]?零基礎(chǔ)IM開發(fā)入門(二)：什么是IM系統(tǒng)的實(shí)時(shí)性？》
[4]?零基礎(chǔ)IM開發(fā)入門(三)：什么是IM系統(tǒng)的可靠性逃延？》
[5]?零基礎(chǔ)IM開發(fā)入門(四)：什么是IM系統(tǒng)的消息時(shí)序一致性览妖？》
[6]?移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡(luò)的“弱”和“慢”》
[7]?移動端IM開發(fā)者必讀(二)：史上最全移動弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》
[8]?從客戶端的角度來談?wù)勔苿佣薎M的消息可靠性和送達(dá)機(jī)制》
[9]?現(xiàn)代移動端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請求速度揽祥、弱網(wǎng)適應(yīng)讽膏、安全保障》
[10]?史上最通俗Netty框架入門長文：基本介紹、環(huán)境搭建拄丰、動手實(shí)戰(zhàn)
[11]?強(qiáng)列建議將Protobuf作為你的即時(shí)通訊應(yīng)用數(shù)據(jù)傳輸格式
[12]?IM通訊協(xié)議專題學(xué)習(xí)(一)：Protobuf從入門到精通府树，一篇就夠是嗜！
[13]?微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解
[15]?從客戶端的角度來談?wù)勔苿佣薎M的消息可靠性和送達(dá)機(jī)制
[16]?IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(一)：保證在線實(shí)時(shí)消息的可靠投遞
[17]?理解IM消息“可靠性”和“一致性”問題，以及解決方案探討
[18]?融云技術(shù)分享：全面揭秘億級IM消息的可靠投遞機(jī)制
[19]?IM群聊消息如此復(fù)雜挺尾，如何保證不丟不重？
[20]?零基礎(chǔ)IM開發(fā)入門(四)：什么是IM系統(tǒng)的消息時(shí)序一致性站绪？
[21]?一套億級用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性遭铺、有序性、弱網(wǎng)優(yōu)化等
[22]?如何保證IM實(shí)時(shí)消息的“時(shí)序性”與“一致性”恢准？
[23]?阿里IM技術(shù)分享(六)：閑魚億級IM消息系統(tǒng)的離線推送到達(dá)率優(yōu)化
[24]?微信的海量IM聊天消息序列號生成實(shí)踐（算法原理篇）
[25]?社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)魂挂、技術(shù)實(shí)現(xiàn)等
[26]?網(wǎng)易云信技術(shù)分享：IM中的萬人群聊技術(shù)方案實(shí)踐總結(jié)
[27]?企業(yè)微信的IM架構(gòu)設(shè)計(jì)揭秘：消息模型、萬人群馁筐、已讀回執(zhí)涂召、消息撤回等
[28]?融云IM技術(shù)分享：萬人群聊消息投遞方案的思考和實(shí)踐
[29]?為何基于TCP協(xié)議的移動端IM仍然需要心跳保活機(jī)制敏沉？
[30]?一文讀懂即時(shí)通訊應(yīng)用中的網(wǎng)絡(luò)心跳包機(jī)制：作用果正、原理、實(shí)現(xiàn)思路等
[31]?微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺泵顺伲活實(shí)戰(zhàn)分享(網(wǎng)絡(luò)鼻镉荆活篇)
[32]?融云技術(shù)分享：融云安卓端IM產(chǎn)品的網(wǎng)絡(luò)鏈路保活技術(shù)實(shí)踐
[33]?阿里IM技術(shù)分享(九)：深度揭密RocketMQ在釘釘IM系統(tǒng)中的應(yīng)用實(shí)踐
[34]?徹底搞懂TCP協(xié)議層的KeepAlive痹懿ぃ活機(jī)制
[35]?深度解密釘釘即時(shí)消息服務(wù)DTIM的技術(shù)設(shè)計(jì)
[36]?基于實(shí)踐：一套百萬消息量小規(guī)模IM系統(tǒng)技術(shù)要點(diǎn)總結(jié)
[37]?跟著源碼學(xué)IM(十)：基于Netty迫皱，搭建高性能IM集群（含技術(shù)思路+源碼）
[38]?一套十萬級TPS的IM綜合消息系統(tǒng)的架構(gòu)實(shí)踐與思考
（本文已同步發(fā)布于：http://www.52im.net/thread-4453-1-1.html）
