本文由百度技術(shù)王偉分享，原題“視頻中為什么需要這么多的顏色空間？”，本文收錄時(shí)有修訂和改動(dòng)。

1、引言

在視頻處理中，我們經(jīng)常會(huì)用到不同的色彩空間：非線性RGB，線性 RGB，YUV，XYZ……為什么需要這么多的色彩空間呢？為什么在 FFMpeg 中會(huì)有 color_space，color_transfer，color_primaries 等一系列的顏色屬性呢？這些術(shù)語(yǔ)之間究竟隱藏著什么秘密？

本文將以通俗易懂的文字，引導(dǎo)你理解視頻是如何從采集開(kāi)始，歷經(jīng)各種步驟，最終通過(guò)顏色模型轉(zhuǎn)換和不同的色域轉(zhuǎn)換，讓你看到賞心悅目的視頻結(jié)果的。

2、系列文章

本文是系列文章中的第20篇，本系列文章的大綱如下：

《即時(shí)通訊音視頻開(kāi)發(fā)（一）：視頻編解碼之理論概述》

《即時(shí)通訊音視頻開(kāi)發(fā)（二）：視頻編解碼之?dāng)?shù)字視頻介紹》

《即時(shí)通訊音視頻開(kāi)發(fā)（三）：視頻編解碼之編碼基礎(chǔ)》

《即時(shí)通訊音視頻開(kāi)發(fā)（四）：視頻編解碼之預(yù)測(cè)技術(shù)介紹》

《即時(shí)通訊音視頻開(kāi)發(fā)（五）：認(rèn)識(shí)主流視頻編碼技術(shù)H.264》

《即時(shí)通訊音視頻開(kāi)發(fā)（六）：如何開(kāi)始音頻編解碼技術(shù)的學(xué)習(xí)》

《即時(shí)通訊音視頻開(kāi)發(fā)（七）：音頻基礎(chǔ)及編碼原理入門(mén)》

《即時(shí)通訊音視頻開(kāi)發(fā)（八）：常見(jiàn)的實(shí)時(shí)語(yǔ)音通訊編碼標(biāo)準(zhǔn)》

《即時(shí)通訊音視頻開(kāi)發(fā)（九）：實(shí)時(shí)語(yǔ)音通訊的回音及回音消除概述》

《即時(shí)通訊音視頻開(kāi)發(fā)（十）：實(shí)時(shí)語(yǔ)音通訊的回音消除技術(shù)詳解》

《即時(shí)通訊音視頻開(kāi)發(fā)（十一）：實(shí)時(shí)語(yǔ)音通訊丟包補(bǔ)償技術(shù)詳解》

《即時(shí)通訊音視頻開(kāi)發(fā)（十二）：多人實(shí)時(shí)音視頻聊天架構(gòu)探討》

《即時(shí)通訊音視頻開(kāi)發(fā)（十三）：實(shí)時(shí)視頻編碼H.264的特點(diǎn)與優(yōu)勢(shì)》

《即時(shí)通訊音視頻開(kāi)發(fā)（十四）：實(shí)時(shí)音視頻數(shù)據(jù)傳輸協(xié)議介紹》

《即時(shí)通訊音視頻開(kāi)發(fā)（十五）：聊聊P2P與實(shí)時(shí)音視頻的應(yīng)用情況》

《即時(shí)通訊音視頻開(kāi)發(fā)（十六）：移動(dòng)端實(shí)時(shí)音視頻開(kāi)發(fā)的幾個(gè)建議》

《即時(shí)通訊音視頻開(kāi)發(fā)（十七）：視頻編碼H.264、V8的前世今生》

《即時(shí)通訊音視頻開(kāi)發(fā)（十八）：詳解音頻編解碼的原理、演進(jìn)和應(yīng)用選型》

《即時(shí)通訊音視頻開(kāi)發(fā)（十九）：零基礎(chǔ)，史上最通俗視頻編碼技術(shù)入門(mén)》

《即時(shí)通訊音視頻開(kāi)發(fā)（二十）：一文讀懂視頻的顏色模型轉(zhuǎn)換和色域轉(zhuǎn)換》（* 本文）

3、視頻采集

如上圖所示，在相機(jī)系統(tǒng)中，外部世界的光信息（光子，photons）通過(guò)透鏡或其他光學(xué)器件聚焦之后達(dá)到相機(jī)的圖像傳感器（CCD 或者 CMOS）。

過(guò)程是這樣的：

• 1）圖像傳感器可以將一個(gè)入射光子（photon）轉(zhuǎn)換為對(duì)應(yīng)的一個(gè)電子（electron）；
• 2）在曝光時(shí)間內(nèi)，圖像傳感器對(duì)轉(zhuǎn)換的電子進(jìn)行電荷積累；
• 3）然后，圖像傳感器會(huì)將積累的電荷信號(hào)轉(zhuǎn)換成對(duì)應(yīng)的電壓信號(hào)；
• 4）最后，利用 ADC 把電信號(hào)轉(zhuǎn)換成數(shù)字信號(hào)，而轉(zhuǎn)換后的數(shù)字信號(hào)則為某個(gè)范圍內(nèi)的整數(shù)值。

ADC 數(shù)字信號(hào)的取值范圍 ：

[pquote]ADC 轉(zhuǎn)換之后的數(shù)字信號(hào)的取值范圍受限于 ADC 設(shè)備。對(duì)于 8-bits 的 ADC 而言，數(shù)字信號(hào)的取值范圍為 [0, 2^8-1]，因此，對(duì)于每一個(gè)像素而言，會(huì)用 [0, 255] 之間的整數(shù)來(lái)進(jìn)行編碼。[/pquote]

ADC 轉(zhuǎn)換的數(shù)字信號(hào)的數(shù)值是一個(gè)線性編碼的過(guò)程，這意味著如果將圖像傳感器上的光量增加 1 倍，則 ADC 轉(zhuǎn)換之后對(duì)應(yīng)的數(shù)值也會(huì)增加 1 倍。

這是一個(gè)非常有用的特性：無(wú)論是增加物理世界的光量，還是增加 ADC 轉(zhuǎn)換之后的數(shù)值，對(duì)圖片而言，都會(huì)帶來(lái)相同的效果。線性編碼意味著我們所處理的數(shù)據(jù)和光發(fā)射的強(qiáng)度成正比關(guān)系。

由數(shù)碼相機(jī)中的 CMOS 傳感器產(chǎn)生并寫(xiě)入原始文件（Raw File）的數(shù)據(jù)是線性的。與普通照片相比，線性數(shù)據(jù)通常看起來(lái)非常暗且對(duì)比度較低。

在 iPhone 手機(jī)中，可以通過(guò)設(shè)置相機(jī)來(lái)拍攝 Apple ProRAW 格式的照片。

4、探索視頻伽馬校正

研究表明：人類視覺(jué)系統(tǒng)是以對(duì)數(shù)函數(shù)的方式來(lái)感知光亮度。這意味著：人眼會(huì)提高暗部的敏感度，降低高光部分的敏感度。

從數(shù)學(xué)角度看，感知光強(qiáng)度和測(cè)量光強(qiáng)度之間存在一個(gè)*似的*方關(guān)系，具體如下式所示。

由于人類視覺(jué)感知系統(tǒng)不是以線性方式工作的，因此必須使用非線性曲線來(lái)對(duì) ADC 生成的的線性數(shù)據(jù)進(jìn)行變換，從而使得拍攝的圖像色調(diào)與我們的視覺(jué)系統(tǒng)的工作方式相匹配。這個(gè)過(guò)程也就是我們所說(shuō)的 伽馬校正。

因此：在從線性 RGB 空間轉(zhuǎn)換到非線性 RGB 空間時(shí)，需要 γ 作為轉(zhuǎn)換參數(shù)。相機(jī)中的 ISP 模塊負(fù)責(zé)對(duì)圖像傳感器的線性 RGB 進(jìn)行伽馬校正進(jìn)而產(chǎn)生對(duì)應(yīng)的符合人眼感知的非線性 RGB 數(shù)據(jù)。

RGB 的設(shè)備依賴性 ：

不同顯示設(shè)備支持的色域空間不同，因此對(duì)于不同的顯示設(shè)備而言，伽馬校正之后的 RGB 數(shù)值也不同。從這個(gè)角度講，RGB 是設(shè)備依賴型的色彩空間。

5、視頻壓縮

根據(jù)如上的信息，我們知道：相機(jī)系統(tǒng)經(jīng)過(guò) ISP 處理之后，最終會(huì)得到非線性的 RGB 信息。對(duì)于視頻而言，如果以 RGB 存儲(chǔ)每幀的信息，則需要消耗大量的存儲(chǔ)空間。

人類視覺(jué)系統(tǒng)對(duì)顏色信息的敏感度要弱于亮度信息。利用這一特點(diǎn)，通常相機(jī)會(huì)將捕獲的 RGB 信息轉(zhuǎn)換為 YUV 格式，然后對(duì) YUV 格式進(jìn)行色度信息采樣（例如，YUV420）以便壓縮圖像空間。

RGB->YUV，不同標(biāo)準(zhǔn)有不同要求，一般常用的標(biāo)準(zhǔn)有：

• 1）BT. 601(SD: Standard-Definition)；
• 2）BT. 709(HD: High-Definition)；
• 3）BT. 2020(UHD: Ultra-High-Definition)。

注意 ：

標(biāo)準(zhǔn)中，不但會(huì)規(guī)定 RGB->YUV 的轉(zhuǎn)換系數(shù)，同時(shí)還會(huì)規(guī)定從線性 RGB 到非線性 RGB 轉(zhuǎn)換的 gamma 系數(shù)。

將 RGB顏色模型，轉(zhuǎn)換成 YUV 模型后，接下來(lái)會(huì)采用某種視頻編解碼算法（例如，H265, VP9）對(duì)獲取的數(shù)據(jù)進(jìn)行視頻編碼，最終得到視頻文件（此處忽略了音頻的采集編碼以及合流的操作）。

6、視頻轉(zhuǎn)碼

出于各種原因，例如：

• 1）終端用戶的帶寬受限；
• 2）終端用戶支持的視頻編解碼算法和相機(jī)壓縮視頻的編解碼算法不一致；
• 3）……

一般不會(huì)直接把相機(jī)產(chǎn)出的視頻文件分發(fā)給用戶去消費(fèi)。媒體服務(wù)商會(huì)對(duì)相機(jī)生成的視頻文件進(jìn)行轉(zhuǎn)碼，然后選擇合適的轉(zhuǎn)碼后的視頻分發(fā)給終端消費(fèi)用戶。

在視頻轉(zhuǎn)碼階段，如果我們希望對(duì)原視頻進(jìn)行色域的變換，例如從 BT. 601 轉(zhuǎn)碼為 BT. 709，則需要在不同色域的 RGB 數(shù)值之間進(jìn)行轉(zhuǎn)換。

在不同的色域空間進(jìn)行 RGB 數(shù)據(jù)的轉(zhuǎn)換，這也就是我們所說(shuō)的 色彩管理。色彩管理會(huì)對(duì)圖像進(jìn)行色彩管理以適配當(dāng)前環(huán)境下的顏色效果，從而保證同一張圖片在不同輸入、輸出上都呈現(xiàn)出最好的顏色。

色彩轉(zhuǎn)換需要在某個(gè)線性空間下進(jìn)行操作，并且操作過(guò)程需要保持設(shè)備的獨(dú)立性。因此，不同的 RGB 色域空間是不能直接進(jìn)行轉(zhuǎn)換的，需要一個(gè)設(shè)備無(wú)關(guān)、線性的顏色模型作為中轉(zhuǎn)才能實(shí)現(xiàn)其轉(zhuǎn)換。

而 XYZ（CIE 1931 XYZ color space）具備設(shè)備無(wú)關(guān)、線性操作的特性。

在 FFMpeg 中，主要使用 colorspace 濾鏡 來(lái)完成不同色域空間的轉(zhuǎn)換。

根據(jù) colorspace 的實(shí)現(xiàn)可知，在 FFMpeg 中，BT. 601->BT. 709 的轉(zhuǎn)換過(guò)程如下所示：

在如上的變換中，涉及到 3 個(gè)顏色空間的轉(zhuǎn)換，分別是：

• 1）YUV 和 RGB 之間的轉(zhuǎn)換；
• 2）線性 RGB 和非線性 RGB 之間的轉(zhuǎn)換；
• 3）線性 RGB 和 XYZ 之間的轉(zhuǎn)換。

在 FFMpeg 中，所有的這些轉(zhuǎn)換參數(shù)都保存在 AVFrame 結(jié)構(gòu)中：

• 1）AVFrame->colorspace 中保存了 YUV/RGB 的轉(zhuǎn)換矩陣；
• 2）AVFrame->color_trc 中保存了線性 RGB 和非線性 RGB 之間的轉(zhuǎn)換函數(shù)（transformation characteristics）；
• 3）AVFrame->color_primaries 中保存了 RGB/XYZ 的轉(zhuǎn)換矩陣；

如果用 ffprobe 命令解析視頻文件，則：

• 1）color_space 字段對(duì)應(yīng) YUV/RGB 的轉(zhuǎn)換矩陣；
• 2）color_transfer 字段對(duì)應(yīng)線性 RGB 和非線性 RGB 之間的轉(zhuǎn)換函數(shù)；
• 3）color_primaries 字段對(duì)應(yīng) RGB/XYZ 的轉(zhuǎn)換矩陣。

$ ffprobe -select_streams v:0 -show_entries stream=color_space,color_transfer,color_primaries test.mp4

 

[STREAM]

color_space=bt2020nc

color_transfer=arib-std-b67

color_primaries=bt2020

[/STREAM]

在如上的例子中，arib-std-b67 也就是我們所熟悉的 HLG。

在 MediaInfo 中：

• 1）Matrix coefficients 字段對(duì)應(yīng) YUV/RGB 的轉(zhuǎn)換矩陣；
• 2）Transfer characteristic 字段對(duì)應(yīng)線性 RGB 和非線性 RGB 之間的轉(zhuǎn)換函數(shù)；
• 3）Color primaries 字段對(duì)應(yīng) RGB/XYZ 的轉(zhuǎn)換矩陣。

除了如上的參數(shù)外，AVFrame->range 還用來(lái)存儲(chǔ)視頻中對(duì)應(yīng)像素的每個(gè)分量的取值范圍。

在 vf_setparams.c 中也作了相關(guān)的定義說(shuō)明：

{"limited", NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_MPEG},  0, 0, FLAGS, "range"},

{"tv",      NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_MPEG},  0, 0, FLAGS, "range"},

{"mpeg",    NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_MPEG},  0, 0, FLAGS, "range"},

{"full",    NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_JPEG},  0, 0, FLAGS, "range"},

{"pc",      NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_JPEG},  0, 0, FLAGS, "range"},

{"jpeg",    NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_JPEG},  0, 0, FLAGS, "range"},

7、視頻解碼&播放

7.1基本

轉(zhuǎn)碼之后的視頻，可以通過(guò)各種渠道分發(fā)到終端用戶進(jìn)行消費(fèi)。

對(duì)于大部分顯示設(shè)備，例如CRT顯示器、LCD、OLED，屏幕上的每個(gè)像素都是通過(guò)驅(qū)動(dòng)三個(gè)非常靠*但仍然分開(kāi)的小型 RGB 光源而構(gòu)建的。

因此：顯示屏（監(jiān)視器、電視機(jī)、屏幕等等）僅使用 RGB 模型，并以不同的方式來(lái)組織，并顯示最終的圖像。

如前所述：不同的顯示設(shè)備采用的 RGB 的色域并不一定相同，因此，RGB 是一種設(shè)備依賴型的顏色模型。在 Mac 電腦上，可以通過(guò)顯示器配置來(lái)選擇顯示器支持不同的 RGB 色域。

7.2顯示設(shè)備和相機(jī)的色域一致

如果編碼視頻和播放視頻的顯示器采用的 RGB 色域是一致的，比如都是 sRGB，此時(shí)的播放過(guò)程相對(duì)比較簡(jiǎn)單。

視頻解碼之后：得到 YUV 數(shù)據(jù)，然后根據(jù)標(biāo)準(zhǔn)將 YUV 數(shù)據(jù)轉(zhuǎn)換成非線性的 sRGB 數(shù)據(jù)，然后顯示器根據(jù) sRGB 數(shù)據(jù)顯示圖像即可。

7.3顯示設(shè)備和相機(jī)的色域不一致

當(dāng)顯示設(shè)備支持的色域從 sRGB 變?yōu)?Rec. 2020 時(shí)，如果直接顯示 sRGB 色域下的數(shù)據(jù)，則會(huì)導(dǎo)致比較嚴(yán)重的顏色失真。

和轉(zhuǎn)碼階段的色域轉(zhuǎn)換類似，此時(shí)，也需要在不同的色域空間進(jìn)行 RGB 數(shù)據(jù)的轉(zhuǎn)換（色彩管理）以保證相同的視頻在不同輸入、輸出、顯示設(shè)備上都呈現(xiàn)出最好的顏色。

對(duì)于顯示設(shè)備而言，sRGB->RGB(Rec. 2020)的轉(zhuǎn)換過(guò)程如下所示：

因此：對(duì)于拍攝設(shè)備和顯示設(shè)備的色域不同時(shí)，視頻的播放增加了顏色管理的過(guò)程。

8、視頻觀看

雖然視頻信息的采集和最終終端播放采用的都是 RGB 的顏色模型，但是對(duì)人眼而言，RGB 其實(shí)并不直觀，比如我們很難馬上反應(yīng)出天青色的 RGB 色值？

為了能夠更直觀的表示顏色，又引入了 HSL 色彩模型。

HSL 比 RGB 更加直觀，比如：想從黃色過(guò)度到紅色，只需要調(diào)整色相即可，飽和度和亮度保持不變。因此，HSL 一般更適合人的色彩感知，而 RGB 更適合顯示領(lǐng)域。

為了讓作品可以呈現(xiàn)出期望的效果，提升用戶的視覺(jué)體驗(yàn)，在攝影后期，使用 HSL 對(duì)作品進(jìn)行調(diào)整是最方便的一種方式。利用 HSL 對(duì)作品進(jìn)行調(diào)整，簡(jiǎn)單幾步就可以讓灰暗的「馬路隨拍」秒變「街頭大片」。

FFMpeg 的 signalstats 濾鏡可以分析獲取視頻的色調(diào)、飽和度、亮度信息。但是該濾鏡獲取的色調(diào)、飽和度和 HSL 中的計(jì)算 是不一致的。

signalstats 計(jì)算色調(diào)、飽和度的算法如下所示：

如果需要得到視頻的標(biāo)準(zhǔn) HSL 信息，可以使用作者開(kāi)發(fā)的 vf_hsl 濾鏡。

9、本文小結(jié)

雖然顏色還是那個(gè)顏色，但是不同的顏色空間的適用范圍并不相同。

具體是：

• 1）RGB：面向采集和顯示設(shè)備；
• 2）YUV：面向存儲(chǔ)；
• 3）HSL：面向人類視覺(jué)感知；
• 4）XYZ：RGB之間的轉(zhuǎn)換橋梁。

從視頻采集到視頻消費(fèi)的整個(gè)過(guò)程，涉及到不同的設(shè)備和標(biāo)準(zhǔn)，而不同的設(shè)備和標(biāo)準(zhǔn)所支持的色域空間又不相同。

正是通過(guò)不同的顏色模型轉(zhuǎn)換和不同的色域轉(zhuǎn)換，才得以讓我們實(shí)現(xiàn)：在不同輸入、輸出、顯示設(shè)備上都呈現(xiàn)出最好的顏色，并以*似相同的觀看體驗(yàn)來(lái)消費(fèi)視頻。

10、參考文獻(xiàn)

[1] CMOS Image Sensor原理簡(jiǎn)述

[2] 數(shù)字視頻導(dǎo)論

[3] 用HSL調(diào)色=簡(jiǎn)單、快速、超出片

[4] 零基礎(chǔ)入門(mén)：實(shí)時(shí)音視頻技術(shù)基礎(chǔ)知識(shí)全面盤(pán)點(diǎn)

[5] 實(shí)時(shí)音視頻面視必備：快速掌握11個(gè)視頻技術(shù)相關(guān)的基礎(chǔ)概念

[6] 輕松詼諧，講解視頻編解碼技術(shù)的過(guò)去、現(xiàn)在和將來(lái)

[7] 寫(xiě)給小白的實(shí)時(shí)音視頻技術(shù)入門(mén)提綱

[8] 福利貼：最全實(shí)時(shí)音視頻開(kāi)發(fā)要用到的開(kāi)源工程匯總

[9] 詳解音頻編解碼的原理、演進(jìn)和應(yīng)用選型

[10] 零基礎(chǔ)，史上最通俗視頻編碼技術(shù)入門(mén)

（本文已同步發(fā)布于：http://www.52im.net/thread-4467-1-1.html）

一、更新內(nèi)容簡(jiǎn)介

本次更新為次要版本更新，進(jìn)行了若干優(yōu)化（更新歷史詳見(jiàn)：碼云 Release Notes、Github Release Notes）。MobileIMSDK 可能是市面上唯一同時(shí)支持 UDP+TCP+WebSocket 三種協(xié)議的同類開(kāi)源IM框架。

二、MobileIMSDK簡(jiǎn)介

MobileIMSDK 是一套專為移動(dòng)端開(kāi)發(fā)的原創(chuàng)IM通信層框架：

• 歷經(jīng)10年、久經(jīng)考驗(yàn)；
• 超輕量級(jí)、高度提煉，lib包50KB以內(nèi)；
• 精心封裝，一套API同時(shí)支持UDP、TCP、WebSocket三種協(xié)議（可能是全網(wǎng)唯一開(kāi)源的）；
• 客戶端支持 iOS、Android、標(biāo)準(zhǔn)Java、H5、小程序、Uniapp；
• 服務(wù)端基于Netty，性能卓越、易于擴(kuò)展；
• 可與姊妹工程 MobileIMSDK-Web 無(wú)縫互通實(shí)現(xiàn)網(wǎng)頁(yè)端聊天或推送等；
• 可應(yīng)用于跨設(shè)備、跨網(wǎng)絡(luò)的聊天APP、企業(yè)OA、消息推送等各種場(chǎng)景。

MobileIMSDK工程始于2013年10月，歷經(jīng)10年，起初用作某產(chǎn)品的即時(shí)通訊底層實(shí)現(xiàn)，完全從零開(kāi)發(fā)，技術(shù)自主可控！

您可能需要：查看關(guān)于MobileIMSDK的詳細(xì)介紹。

三、源碼托管同步更新

OsChina.net

• 源碼托管： http://git.oschina.net/jackjiang/MobileIMSDK

• 項(xiàng)目資料： 點(diǎn)擊查看更多資料

GitHub.com

• 源碼托管： https://github.com/JackJiang2011/MobileIMSDK

• 項(xiàng)目資料： 點(diǎn)擊查看更多資料

四、MobileIMSDK設(shè)計(jì)目標(biāo)

讓開(kāi)發(fā)者專注于應(yīng)用邏輯的開(kāi)發(fā)，底層復(fù)雜的即時(shí)通訊算法交由SDK開(kāi)發(fā)人員，從而解偶即時(shí)通訊應(yīng)用開(kāi)發(fā)的復(fù)雜性。

五、MobileIMSDK框架組成

整套MobileIMSDK框架由以下7部分組成：

1. Android客戶端SDK：用于Android版即時(shí)通訊客戶端，支持Android 2.3及以上，查看API文檔；
2. iOS客戶端SDK：用于開(kāi)發(fā)iOS版即時(shí)通訊客戶端，支持iOS 9.0及以上，查看API文檔；
3. Java客戶端SDK：用于開(kāi)發(fā)跨平臺(tái)的PC端即時(shí)通訊客戶端，支持Java 1.6及以上，查看API文檔；
4. H5客戶端SDK：查看精編注釋版；
5. 微信小程序端SDK：查看精編注釋版；
6. Uniapp端SDK：查看精編注釋版；
7. 服務(wù)端SDK：用于開(kāi)發(fā)即時(shí)通訊服務(wù)端，支持Java 1.7及以上版本，查看API文檔。

整套MobileIMSDK框架的架構(gòu)組成：

 另外：MobileIMSDK可與姊妹工程 MobileIMSDK-Web 無(wú)縫互通，從而實(shí)現(xiàn)Web網(wǎng)頁(yè)端聊天或推送等。

六、MobileIMSDK v6.4更新內(nèi)容 

【重要說(shuō)明】：

MobileIMSDK v6.4 為次要版本，進(jìn)行了若干優(yōu)化！ 查看詳情 （github）

【新增重要特性】：

• 無(wú)

【解決的Bug】：

• 1. [Uniapp端] 解決了Demo界面右上角的連接狀態(tài)title無(wú)法更新的問(wèn)題；
• 2. [服務(wù)端] 解決橋接模式下與最新rabbitmq庫(kù)不兼容從而斷線重連不成功，導(dǎo)致MQ中消息堆積的問(wèn)題。

【其它優(yōu)化和提升】：

• 1. [服務(wù)端] 解決登陸連接指令中的一處潛在空指針風(fēng)險(xiǎn)；
• 2. [微信小程序端] 優(yōu)化自帶Demo中聊天主界面flex布局下的中部聊天列表高度自適應(yīng)能力；
• 3. [微信小程序端/H5端] 優(yōu)化了Demo中的CSS代碼；
• 4. [微信小程序端/H5端] 優(yōu)化了WebSocket的關(guān)閉邏輯，確保標(biāo)準(zhǔn)API中的close方法因異步調(diào)用帶來(lái)socket實(shí)例被錯(cuò)誤重置的問(wèn)題；
• 5. [H5端] 為Demo增加了消息送達(dá)狀態(tài)圖標(biāo)的顯示（包括發(fā)送中、發(fā)送成功、發(fā)送失敗3種狀態(tài)）；
• 6. [H5端] 重新設(shè)計(jì)了Demo的登錄界面；
• 7. [服務(wù)端] 升級(jí)amqp-client庫(kù)至5.x版；
• 8. [服務(wù)端] 解決橋接模式下MQ斷線自動(dòng)恢復(fù)時(shí)消費(fèi)者Chennal未主動(dòng)清理，導(dǎo)致channel越來(lái)越多的問(wèn)題（無(wú)消費(fèi)者與其關(guān)聯(lián)的空channel）：
• 9. [Android] 提升targetSdkVersion至33（即Android 13）；
• 10. [Android] 升級(jí)開(kāi)發(fā)工程使之支持最新Android Studio Giraffe和Gradle 8.1.1；

【最新版本源碼地址】：

• Gitee：https://gitee.com/jackjiang/MobileIMSDK/releases/tag/v6.4
• Github：https://github.com/JackJiang2011/MobileIMSDK/releases/tag/6.4

本文由阮一峰(ruanyifeng.com）分享，本文收錄時(shí)有內(nèi)容修訂和排版優(yōu)化。

1、引言

今天中午，我突然想搞清楚 Unicode 和 UTF-8 之間的關(guān)系，就開(kāi)始查資料。

這個(gè)問(wèn)題比我想象的復(fù)雜，午飯后一直看到晚上9點(diǎn)，才算初步搞清楚。

下面就是我的總結(jié)，主要用來(lái)整理自己的思路。我盡量寫(xiě)得通俗易懂，希望能對(duì)其他朋友有用。畢竟，字符編碼是計(jì)算機(jī)技術(shù)的基石，對(duì)于程序員來(lái)說(shuō)尤其重要，字符編碼的知識(shí)是必須要懂的。

2、專題目錄

本文是“字符編碼技術(shù)專題”系列文章的第 1 篇，總目錄如下：

• 《字符編碼技術(shù)專題(一)：快速理解ASCII、Unicode、GBK和UTF-8》（* 本文）
• 《字符編碼技術(shù)專題(二)：史詩(shī)級(jí)計(jì)算機(jī)字符編碼知識(shí)入門(mén)，一文即懂！》
• 《字符編碼技術(shù)專題(三)：徹底搞懂字符亂碼的本質(zhì)，一篇就夠！》
• 《字符編碼技術(shù)專題(四)：史上最通俗大小端字節(jié)序詳解，一文即懂！》
• 《字符編碼技術(shù)專題(五)：前端必讀的計(jì)算機(jī)字符編碼知識(shí)入門(mén)》

3、基礎(chǔ)知識(shí)

計(jì)算機(jī)中儲(chǔ)存的信息都是用二進(jìn)制數(shù)表示的；而我們?cè)谄聊簧峡吹降挠⑽摹h字等字符是二進(jìn)制數(shù)轉(zhuǎn)換之后的結(jié)果。通俗的說(shuō)，按照何種規(guī)則將字符存儲(chǔ)在計(jì)算機(jī)中，如'a'用什么表示，稱為"編碼"；反之，將存儲(chǔ)在計(jì)算機(jī)中的二進(jìn)制數(shù)解析顯示出來(lái)，稱為"解碼"，如同密碼學(xué)中的加密和解密。在解碼過(guò)程中，如果使用了錯(cuò)誤的解碼規(guī)則，則導(dǎo)致'a'解析成'b'或者亂碼。

字符集（Charset）：是一個(gè)系統(tǒng)支持的所有抽象字符的集合。字符是各種文字和符號(hào)的總稱，包括各國(guó)家文字、標(biāo)點(diǎn)符號(hào)、圖形符號(hào)、數(shù)字等。

字符編碼（Character Encoding）：是一套法則，使用該法則能夠?qū)ψ匀徽Z(yǔ)言的字符的一個(gè)集合（如字母表或音節(jié)表），與其他東西的一個(gè)集合（如號(hào)碼或電脈沖）進(jìn)行配對(duì)。即在符號(hào)集合與數(shù)字系統(tǒng)之間建立對(duì)應(yīng)關(guān)系，它是信息處理的一項(xiàng)*本技術(shù)。通常人們用符號(hào)集合（一般情況下就是文字）來(lái)表達(dá)信息。而以計(jì)算機(jī)為*礎(chǔ)的信息處理系統(tǒng)則是利用元件（硬件）不同狀態(tài)的組合來(lái)存儲(chǔ)和處理信息的。元件不同狀態(tài)的組合能代表數(shù)字系統(tǒng)的數(shù)字，因此字符編碼就是將符號(hào)轉(zhuǎn)換為計(jì)算機(jī)可以接受的數(shù)字系統(tǒng)的數(shù)，稱為數(shù)字代碼。

常見(jiàn)字符集名稱：ASCII字符集、GB2312字符集、BIG5字符集、GB18030字符集、Unicode字符集等。計(jì)算機(jī)要準(zhǔn)確的處理各種字符集文字，需要進(jìn)行字符編碼，以便計(jì)算機(jī)能夠識(shí)別和存儲(chǔ)各種文字。

4、ASCII 碼

我們知道，計(jì)算機(jī)內(nèi)部，所有信息最終都是一個(gè)二進(jìn)制值。每一個(gè)二進(jìn)制位（bit）有0和1兩種狀態(tài)，因此八個(gè)二進(jìn)制位就可以組合出256種狀態(tài)，這被稱為一個(gè)字節(jié)（byte）。也就是說(shuō)，一個(gè)字節(jié)一共可以用來(lái)表示256種不同的狀態(tài)，每一個(gè)狀態(tài)對(duì)應(yīng)一個(gè)符號(hào)，就是256個(gè)符號(hào)，從00000000到11111111。

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

ASCII 碼一共規(guī)定了128個(gè)字符的編碼，比如空格SPACE是32（二進(jìn)制00100000），大寫(xiě)的字母A是65（二進(jìn)制01000001）。這128個(gè)符號(hào)（包括32個(gè)不能打印出來(lái)的控制符號(hào)），只占用了一個(gè)字節(jié)的后面7位，最前面的一位統(tǒng)一規(guī)定為0。

▲ ASCII編碼表

5、非 ASCII 編碼

英語(yǔ)用128個(gè)符號(hào)編碼就夠了，但是用來(lái)表示其他語(yǔ)言，128個(gè)符號(hào)是不夠的。比如，在法語(yǔ)中，字母上方有注音符號(hào)，它就無(wú)法用 ASCII 碼表示。于是，一些歐洲國(guó)家就決定，利用字節(jié)中閑置的最高位編入新的符號(hào)。比如，法語(yǔ)中的é的編碼為130（二進(jìn)制10000010）。這樣一來(lái)，這些歐洲國(guó)家使用的編碼體系，可以表示最多256個(gè)符號(hào)。

▲ 擴(kuò)展ASCII編碼表

但是，這里又出現(xiàn)了新的問(wèn)題。不同的國(guó)家有不同的字母，因此，哪怕它們都使用256個(gè)符號(hào)的編碼方式，代表的字母卻不一樣。比如，130在法語(yǔ)編碼中代表了é，在希伯來(lái)語(yǔ)編碼中卻代表了字母Gimel (?)，在俄語(yǔ)編碼中又會(huì)代表另一個(gè)符號(hào)。但是不管怎樣，所有這些編碼方式中，0--127表示的符號(hào)是一樣的，不一樣的只是128--255的這一段。

至于亞洲國(guó)家的文字，使用的符號(hào)就更多了，漢字就多達(dá)10萬(wàn)左右。一個(gè)字節(jié)只能表示256種符號(hào)，肯定是不夠的，就必須使用多個(gè)字節(jié)表達(dá)一個(gè)符號(hào)。比如，簡(jiǎn)體中文常見(jiàn)的編碼方式是 GB2312，使用兩個(gè)字節(jié)表示一個(gè)漢字，所以理論上最多可以表示 256 x 256 = 65536 個(gè)符號(hào)。

中文編碼的問(wèn)題比較復(fù)雜，將在文末討論。這里先了解下，雖然都是用多個(gè)字節(jié)表示一個(gè)符號(hào)，但是GB類的漢字編碼與后文的 Unicode 和 UTF-8 是毫無(wú)關(guān)系的。

6、Unicode

正如上一節(jié)所說(shuō)，世界上存在著多種編碼方式，同一個(gè)二進(jìn)制數(shù)字可以被解釋成不同的符號(hào)。因此，要想打開(kāi)一個(gè)文本文件，就必須知道它的編碼方式，否則用錯(cuò)誤的編碼方式解讀，就會(huì)出現(xiàn)亂碼。為什么電子郵件常常出現(xiàn)亂碼？就是因?yàn)榘l(fā)信人和收信人使用的編碼方式不一樣。

可以想象，如果有一種編碼，將世界上所有的符號(hào)都納入其中。每一個(gè)符號(hào)都給予一個(gè)獨(dú)一無(wú)二的編碼，那么亂碼問(wèn)題就會(huì)消失。這就是 Unicode，就像它的名字都表示的，這是一種所有符號(hào)的編碼。

Unicode 當(dāng)然是一個(gè)很大的集合，現(xiàn)在的規(guī)模可以容納100多萬(wàn)個(gè)符號(hào)。每個(gè)符號(hào)的編碼都不一樣，比如，U+0639表示阿拉伯字母Ain，U+0041表示英語(yǔ)的大寫(xiě)字母A，U+4E25表示漢字嚴(yán)。具體的符號(hào)對(duì)應(yīng)表，可以查詢unicode.org，或者專門(mén)的漢字對(duì)應(yīng)表。

7、Unicode 的問(wèn)題

需要注意的是，Unicode 只是一個(gè)符號(hào)集，它只規(guī)定了符號(hào)的二進(jìn)制代碼，卻沒(méi)有規(guī)定這個(gè)二進(jìn)制代碼應(yīng)該如何存儲(chǔ)。

比如，漢字嚴(yán)的 Unicode 是十六進(jìn)制數(shù)4E25，轉(zhuǎn)換成二進(jìn)制數(shù)足足有15位（100111000100101），也就是說(shuō)，這個(gè)符號(hào)的表示至少需要2個(gè)字節(jié)。表示其他更大的符號(hào)，可能需要3個(gè)字節(jié)或者4個(gè)字節(jié)，甚至更多。

這里就有兩個(gè)嚴(yán)重的問(wèn)題，第一個(gè)問(wèn)題是，如何才能區(qū)別 Unicode 和 ASCII ？計(jì)算機(jī)怎么知道三個(gè)字節(jié)表示一個(gè)符號(hào)，而不是分別表示三個(gè)符號(hào)呢？第二個(gè)問(wèn)題是，我們已經(jīng)知道，英文字母只用一個(gè)字節(jié)表示就夠了，如果 Unicode 統(tǒng)一規(guī)定，每個(gè)符號(hào)用三個(gè)或四個(gè)字節(jié)表示，那么每個(gè)英文字母前都必然有二到三個(gè)字節(jié)是0，這對(duì)于存儲(chǔ)來(lái)說(shuō)是極大的浪費(fèi)，文本文件的大小會(huì)因此大出二三倍，這是無(wú)法接受的。

它們?cè)斐傻慕Y(jié)果是：1）出現(xiàn)了 Unicode 的多種存儲(chǔ)方式，也就是說(shuō)有許多種不同的二進(jìn)制格式，可以用來(lái)表示 Unicode。2）Unicode 在很長(zhǎng)一段時(shí)間內(nèi)無(wú)法推廣，直到互聯(lián)網(wǎng)的出現(xiàn)。

8、UTF-8

互聯(lián)網(wǎng)的普及，強(qiáng)烈要求出現(xiàn)一種統(tǒng)一的編碼方式。UTF-8 就是在互聯(lián)網(wǎng)上使用最廣的一種 Unicode 的實(shí)現(xiàn)方式。其他實(shí)現(xiàn)方式還包括 UTF-16（字符用兩個(gè)字節(jié)或四個(gè)字節(jié)表示）和 UTF-32（字符用四個(gè)字節(jié)表示），不過(guò)在互聯(lián)網(wǎng)上*本不用。重復(fù)一遍，這里的關(guān)系是，UTF-8 是 Unicode 的實(shí)現(xiàn)方式之一。

UTF-8 最大的一個(gè)特點(diǎn)，就是它是一種變長(zhǎng)的編碼方式。它可以使用1~4個(gè)字節(jié)表示一個(gè)符號(hào)，根據(jù)不同的符號(hào)而變化字節(jié)長(zhǎng)度。

UTF-8 的編碼規(guī)則很簡(jiǎn)單，只有二條：

• 1）對(duì)于單字節(jié)的符號(hào)：字節(jié)的第一位設(shè)為0，后面7位為這個(gè)符號(hào)的 Unicode 碼。因此對(duì)于英語(yǔ)字母，UTF-8 編碼和 ASCII 碼是相同的；
• 2）對(duì)于n字節(jié)的符號(hào)（n > 1）：第一個(gè)字節(jié)的前n位都設(shè)為1，第n + 1位設(shè)為0，后面字節(jié)的前兩位一律設(shè)為10。剩下的沒(méi)有提及的二進(jìn)制位，全部為這個(gè)符號(hào)的 Unicode 碼。

下表總結(jié)了編碼規(guī)則，字母x表示可用編碼的位：

跟據(jù)上表，解讀 UTF-8 編碼非常簡(jiǎn)單。如果一個(gè)字節(jié)的第一位是0，則這個(gè)字節(jié)單獨(dú)就是一個(gè)字符；如果第一位是1，則連續(xù)有多少個(gè)1，就表示當(dāng)前字符占用多少個(gè)字節(jié)。

下面，還是以漢字嚴(yán)為例，演示如何實(shí)現(xiàn) UTF-8 編碼。

嚴(yán)的 Unicode 是4E25（100111000100101），根據(jù)上表，可以發(fā)現(xiàn)4E25處在第三行的范圍內(nèi)（0000 0800 - 0000 FFFF），因此嚴(yán)的 UTF-8 編碼需要三個(gè)字節(jié)，即格式是1110xxxx 10xxxxxx 10xxxxxx。然后，從嚴(yán)的最后一個(gè)二進(jìn)制位開(kāi)始，依次從后向前填入格式中的x，多出的位補(bǔ)0。這樣就得到了，嚴(yán)的 UTF-8 編碼是11100100 10111000 10100101，轉(zhuǎn)換成十六進(jìn)制就是E4B8A5。

9、Unicode 與 UTF-8 之間的轉(zhuǎn)換

通過(guò)上一節(jié)的例子，可以看到嚴(yán)的 Unicode碼 是4E25，UTF-8 編碼是E4B8A5，兩者是不一樣的。它們之間的轉(zhuǎn)換可以通過(guò)程序?qū)崿F(xiàn)。

Windows平臺(tái)，有一個(gè)最簡(jiǎn)單的轉(zhuǎn)化方法，就是使用內(nèi)置的記事本小程序notepad.exe。打開(kāi)文件后，點(diǎn)擊文件菜單中的另存為命令，會(huì)跳出一個(gè)對(duì)話框，在最底部有一個(gè)編碼的下拉條。

里面有四個(gè)選項(xiàng)：ANSI，Unicode，Unicode big endian和UTF-8

• 1）ANSI是默認(rèn)的編碼方式：對(duì)于英文文件是ASCII編碼，對(duì)于簡(jiǎn)體中文文件是GB2312編碼（只針對(duì) Windows 簡(jiǎn)體中文版，如果是繁體中文版會(huì)采用 Big5 碼）；
• 2）Unicode編碼這里指的是notepad.exe使用的 UCS-2 編碼方式：即直接用兩個(gè)字節(jié)存入字符的 Unicode 碼，這個(gè)選項(xiàng)用的 little endian 格式；
• 3）Unicode big endian編碼與上一個(gè)選項(xiàng)相對(duì)應(yīng)：我在下一節(jié)會(huì)解釋 little endian 和 big endian 的涵義；
• 4）UTF-8編碼：也就是上一節(jié)談到的編碼方法。

選擇完"編碼方式"后，點(diǎn)擊"保存"按鈕，文件的編碼方式就立刻轉(zhuǎn)換好了。

10、Little endian 和 Big endian

上一節(jié)已經(jīng)提到，UCS-2 格式可以存儲(chǔ) Unicode 碼（碼點(diǎn)不超過(guò)0xFFFF）。以漢字嚴(yán)為例，Unicode 碼是4E25，需要用兩個(gè)字節(jié)存儲(chǔ)，一個(gè)字節(jié)是4E，另一個(gè)字節(jié)是25。存儲(chǔ)的時(shí)候，4E在前，25在后，這就是 Big endian 方式；25在前，4E在后，這是 Little endian 方式。

這兩個(gè)古怪的名稱來(lái)自英國(guó)作家斯威夫特的《格列佛游記》。在該書(shū)中，小人國(guó)里爆發(fā)了內(nèi)戰(zhàn)，戰(zhàn)爭(zhēng)起因是人們爭(zhēng)論，吃雞蛋時(shí)究竟是從大頭(Big-endian)敲開(kāi)還是從小頭(Little-endian)敲開(kāi)。為了這件事情，前后爆發(fā)了六次戰(zhàn)爭(zhēng)，一個(gè)皇帝送了命，另一個(gè)皇帝丟了王位。

第一個(gè)字節(jié)在前，就是"大頭方式"（Big endian），第二個(gè)字節(jié)在前就是"小頭方式"（Little endian）。

那么很自然的，就會(huì)出現(xiàn)一個(gè)問(wèn)題：計(jì)算機(jī)怎么知道某一個(gè)文件到底采用哪一種方式編碼？

Unicode 規(guī)范定義，每一個(gè)文件的最前面分別加入一個(gè)表示編碼順序的字符，這個(gè)字符的名字叫做"零寬度非換行空格"（zero width no-break space），用FEFF表示。這正好是兩個(gè)字節(jié)，而且FF比FE大1。

如果一個(gè)文本文件的頭兩個(gè)字節(jié)是FE FF，就表示該文件采用大頭方式；如果頭兩個(gè)字節(jié)是FF FE，就表示該文件采用小頭方式。

11、實(shí)例講解

下面，舉一個(gè)實(shí)例。

打開(kāi)"記事本"程序notepad.exe，新建一個(gè)文本文件，內(nèi)容就是一個(gè)嚴(yán)字，依次采用ANSI，Unicode，Unicode big endian和UTF-8編碼方式保存。

然后，用文本編輯軟件UltraEdit 中的"十六進(jìn)制功能"，觀察該文件的內(nèi)部編碼方式：

• 1）ANSI：文件的編碼就是兩個(gè)字節(jié)D1 CF，這正是嚴(yán)的 GB2312 編碼，這也暗示 GB2312 是采用大頭方式存儲(chǔ)的。
• 2）Unicode：編碼是四個(gè)字節(jié)FF FE 25 4E，其中FF FE表明是小頭方式存儲(chǔ)，真正的編碼是4E25。
• 3）Unicode big endian：編碼是四個(gè)字節(jié)FE FF 4E 25，其中FE FF表明是大頭方式存儲(chǔ)。
• 4）UTF-8：編碼是六個(gè)字節(jié)EF BB BF E4 B8 A5，前三個(gè)字節(jié)EF BB BF表示這是UTF-8編碼，后三個(gè)E4B8A5就是嚴(yán)的具體編碼，它的存儲(chǔ)順序與編碼順序是一致的。

UltraEdit下載地址請(qǐng)至官網(wǎng)：https://www.ultraedit.com/

▲ UltraEdit軟件

12、最后簡(jiǎn)要看看中文字符集和編碼

12.1GB系列字符集&編碼

計(jì)算機(jī)發(fā)明之處及后面很長(zhǎng)一段時(shí)間，只用應(yīng)用于美國(guó)及西方一些發(fā)達(dá)國(guó)家，ASCII能夠很好滿足用戶的需求。但是當(dāng)天朝也有了計(jì)算機(jī)之后，為了顯示中文，必須設(shè)計(jì)一套編碼規(guī)則用于將漢字轉(zhuǎn)換為計(jì)算機(jī)可以接受的數(shù)字系統(tǒng)的數(shù)。

天朝專家把那些127號(hào)之后的奇異符號(hào)們（即EASCII）取消掉，規(guī)定：一個(gè)小于127的字符的意義與原來(lái)相同，但兩個(gè)大于127的字符連在一起時(shí)，就表示一個(gè)漢字，前面的一個(gè)字節(jié)（他稱之為高字節(jié)）從0xA1用到 0xF7，后面一個(gè)字節(jié)（低字節(jié)）從0xA1到0xFE，這樣我們就可以組合出大約7000多個(gè)簡(jiǎn)體漢字了。在這些編碼里，還把數(shù)學(xué)符號(hào)、羅馬希臘的 字母、日文的假名們都編進(jìn)去了，連在ASCII里本來(lái)就有的數(shù)字、標(biāo)點(diǎn)、字母都統(tǒng)統(tǒng)重新編了兩個(gè)字節(jié)長(zhǎng)的編碼，這就是常說(shuō)的"全角"字符，而原來(lái)在127號(hào)以下的那些就叫"半角"字符了。

上述編碼規(guī)則就是GB2312。GB2312或GB2312-80是中國(guó)國(guó)家標(biāo)準(zhǔn)簡(jiǎn)體中文字符集，全稱《信息交換用漢字編碼字符集·*本集》，又稱GB0，由中國(guó)國(guó)家標(biāo)準(zhǔn)總局發(fā)布，1981年5月1日實(shí)施。GB2312編碼通行于中國(guó)大陸；新加坡等地也采用此編碼。中國(guó)大陸幾乎所有的中文系統(tǒng)和國(guó)際化的軟件都支持GB2312。GB2312的出現(xiàn)，*本滿足了漢字的計(jì)算機(jī)處理需要，它所收錄的漢字已經(jīng)覆蓋中國(guó)大陸99.75%的使用頻率。對(duì)于人名、古漢語(yǔ)等方面出現(xiàn)的罕用字，GB2312不能處理，這導(dǎo)致了后來(lái)GBK及GB 18030漢字字符集的出現(xiàn)。下圖是GB2312編碼的開(kāi)始部分（由于其非常龐大，只列舉開(kāi)始部分，具體可查看GB2312簡(jiǎn)體中文編碼表）。

▲ GB2312編碼表的開(kāi)始部分

由于GB 2312-80只收錄6763個(gè)漢字，有不少漢字，如部分在GB 2312-80推出以后才簡(jiǎn)化的漢字（如"啰"），部分人名用字（如中國(guó)前總理***的"*"字），臺(tái)灣及香港使用的繁體字，日語(yǔ)及朝鮮語(yǔ)漢字等，并未有收錄在內(nèi)。于是廠商微軟利用GB 2312-80未使用的編碼空間，收錄GB 13000.1-93全部字符制定了GBK編碼。根據(jù)微軟資料，GBK是對(duì)GB2312-80的擴(kuò)展，也就是CP936字碼表 (Code Page 936)的擴(kuò)展（之前CP936和GB 2312-80一模一樣），最早實(shí)現(xiàn)于Windows 95簡(jiǎn)體中文版。雖然GBK收錄GB 13000.1-93的全部字符，但編碼方式并不相同。GBK自身并非國(guó)家標(biāo)準(zhǔn)，只是曾由國(guó)家技術(shù)監(jiān)督局標(biāo)準(zhǔn)化司、電子工業(yè)部科技與質(zhì)量監(jiān)督司公布為"技術(shù)規(guī)范指導(dǎo)性文件"。原始GB13000一直未被業(yè)界采用，后續(xù)國(guó)家標(biāo)準(zhǔn)GB18030技術(shù)上兼容GBK而非GB13000。

GB 18030，全稱：國(guó)家標(biāo)準(zhǔn)GB 18030-2005《信息技術(shù) 中文編碼字符集》，是中華人民共和國(guó)現(xiàn)時(shí)最新的內(nèi)碼字集，是GB 18030-2000《信息技術(shù) 信息交換用漢字編碼字符集 *本集的擴(kuò)充》的修訂版。與GB 2312-1980完全兼容，與GBK*本兼容，支持GB 13000及Unicode的全部統(tǒng)一漢字，共收錄漢字70244個(gè)。

GB 18030主要有以下特點(diǎn)：

• 與UTF-8相同，采用多字節(jié)編碼，每個(gè)字可以由1個(gè)、2個(gè)或4個(gè)字節(jié)組成；
• 編碼空間龐大，最多可定義161萬(wàn)個(gè)字符；
• 支持中國(guó)國(guó)內(nèi)少數(shù)民族的文字，不需要?jiǎng)佑迷熳謪^(qū)；
• 漢字收錄范圍包含繁體漢字以及日韓漢字。

▲ GB18030編碼總體結(jié)構(gòu)

本規(guī)格的初版使中華人民共和國(guó)信息產(chǎn)業(yè)部電子工業(yè)標(biāo)準(zhǔn)化研究所起草，由國(guó)家質(zhì)量技術(shù)監(jiān)督局于2000年3月17日發(fā)布。現(xiàn)行版本為國(guó)家質(zhì)量監(jiān)督檢驗(yàn)總局和中國(guó)國(guó)家標(biāo)準(zhǔn)化管理委員會(huì)于2005年11月8日發(fā)布，2006年5月1日實(shí)施。此規(guī)格為在中國(guó)境內(nèi)所有軟件產(chǎn)品支持的強(qiáng)制規(guī)格。

12.2BIG5字符集&編碼

Big5，又稱為大五碼或五大碼，是使用繁體中文（正體中文）社區(qū)中最常用的電腦漢字字符集標(biāo)準(zhǔn)，共收錄13,060個(gè)漢字。中文碼分為內(nèi)碼及交換碼兩類，Big5屬中文內(nèi)碼，知名的中文交換碼有CCCII、CNS11643。Big5雖普及于臺(tái)灣、香港與澳門(mén)等繁體中文通行區(qū)，但長(zhǎng)期以來(lái)并非當(dāng)?shù)氐膰?guó)家標(biāo)準(zhǔn)，而只是業(yè)界標(biāo)準(zhǔn)。倚天中文系統(tǒng)、Windows等主要系統(tǒng)的字符集都是以Big5為*準(zhǔn)，但廠商又各自增加不同的造字與造字區(qū)，派生成多種不同版本。2003年，Big5被收錄到CNS11643中文標(biāo)準(zhǔn)交換碼的附錄當(dāng)中，取得了較正式的地位。這個(gè)最新版本被稱為Big5-2003。

Big5碼是一套雙字節(jié)字符集，使用了雙八碼存儲(chǔ)方法，以兩個(gè)字節(jié)來(lái)安放一個(gè)字。第一個(gè)字節(jié)稱為"高位字節(jié)"，第二個(gè)字節(jié)稱為"低位字節(jié)"。"高位字節(jié)"使用了0x81-0xFE，"低位字節(jié)"使用了0x40-0x7E，及0xA1-0xFE。

有關(guān)Big5的更多技術(shù)細(xì)節(jié)讀者可單獨(dú)深入研究，本文就不贅述了。

13、本文小結(jié)

這些字符集和編碼的關(guān)系很容易讓程序員混淆，現(xiàn)在小結(jié)一下。

簡(jiǎn)單來(lái)說(shuō)：Unicode、GBK和Big5碼等就是編碼的值（也就是術(shù)語(yǔ)“字符集”），而UTF-8、UTF-16、UTF32之類就是這個(gè)值的表現(xiàn)形式（即術(shù)語(yǔ)“編碼格式”）。

另外：Unicode、GBK和Big5碼等字符集是不兼容的，同一個(gè)漢字在這三個(gè)字符集里的碼值是完全不一樣的。如＂漢＂的Unicode值與gbk就是不一樣的，假設(shè)Unicode為a040，GBK為b030。以UTF-8為例，UTF-8碼完全只針對(duì)Unicode來(lái)組織的，如果GBK要轉(zhuǎn)UTF-8必須先轉(zhuǎn)Unicode碼，再轉(zhuǎn)UTF-8就OK了。

即GBK、GB2312等與UTF8之間都必須通過(guò)Unicode編碼才能相互轉(zhuǎn)換：

1）GBK、GB2312 --先轉(zhuǎn)--> Unicode --再轉(zhuǎn)--> UTF8

2）UTF8 --先轉(zhuǎn)--> Unicode --再轉(zhuǎn)--> GBK、GB2312

附錄：更多IM技術(shù)精華文章

[1] 新手入門(mén)一篇就夠：從零開(kāi)發(fā)移動(dòng)端IM》

[2] 零*礎(chǔ)IM開(kāi)發(fā)入門(mén)(一)：什么是IM系統(tǒng)？》

[3] 零*礎(chǔ)IM開(kāi)發(fā)入門(mén)(二)：什么是IM系統(tǒng)的實(shí)時(shí)性？》

[4] 零*礎(chǔ)IM開(kāi)發(fā)入門(mén)(三)：什么是IM系統(tǒng)的可靠性？》

[5] 零*礎(chǔ)IM開(kāi)發(fā)入門(mén)(四)：什么是IM系統(tǒng)的消息時(shí)序一致性？》

[6] 移動(dòng)端IM開(kāi)發(fā)者必讀(一)：通俗易懂，理解移動(dòng)網(wǎng)絡(luò)的“弱”和“慢”》

[7] 移動(dòng)端IM開(kāi)發(fā)者必讀(二)：史上最全移動(dòng)弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》

[8] 從客戶端的角度來(lái)談?wù)勔苿?dòng)端IM的消息可靠性和送達(dá)機(jī)制》

[9] 現(xiàn)代移動(dòng)端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請(qǐng)求速度、弱網(wǎng)適應(yīng)、安全保障》

[10] 史上最通俗Netty框架入門(mén)長(zhǎng)文：*本介紹、環(huán)境搭建、動(dòng)手實(shí)戰(zhàn)

[11] 強(qiáng)列建議將Protobuf作為你的即時(shí)通訊應(yīng)用數(shù)據(jù)傳輸格式

[12] IM通訊協(xié)議專題學(xué)習(xí)(一)：Protobuf從入門(mén)到精通，一篇就夠！

[13] 微信新一代通信安全解決方案：*于TLS1.3的MMTLS詳解

[14] 探討組合加密算法在IM中的應(yīng)用

[15] 從客戶端的角度來(lái)談?wù)勔苿?dòng)端IM的消息可靠性和送達(dá)機(jī)制

[16] IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(一)：保證在線實(shí)時(shí)消息的可靠投遞

[17] 理解IM消息“可靠性”和“一致性”問(wèn)題，以及解決方案探討

[18] 融云技術(shù)分享：全面揭秘億級(jí)IM消息的可靠投遞機(jī)制

[19] IM群聊消息如此復(fù)雜，如何保證不丟不重？

[20] 零*礎(chǔ)IM開(kāi)發(fā)入門(mén)(四)：什么是IM系統(tǒng)的消息時(shí)序一致性？

[21] 一套億級(jí)用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性、有序性、弱網(wǎng)優(yōu)化等

[22] 如何保證IM實(shí)時(shí)消息的“時(shí)序性”與“一致性”？

[23] 阿里IM技術(shù)分享(六)：閑魚(yú)億級(jí)IM消息系統(tǒng)的離線推送到達(dá)率優(yōu)化

[24] 微信的海量IM聊天消息序列號(hào)生成實(shí)踐（算法原理篇）

[25] 社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實(shí)現(xiàn)等

[26] 網(wǎng)易云信技術(shù)分享：IM中的萬(wàn)人群聊技術(shù)方案實(shí)踐總結(jié)

[27] 企業(yè)微信的IM架構(gòu)設(shè)計(jì)揭秘：消息模型、萬(wàn)人群、已讀回執(zhí)、消息撤回等

[28] 融云IM技術(shù)分享：萬(wàn)人群聊消息投遞方案的思考和實(shí)踐

[29] 為何*于TCP協(xié)議的移動(dòng)端IM仍然需要心跳保活機(jī)制？

[30] 一文讀懂即時(shí)通訊應(yīng)用中的網(wǎng)絡(luò)心跳包機(jī)制：作用、原理、實(shí)現(xiàn)思路等

[31] 微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺(tái)保活實(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í)踐：一套百萬(wàn)消息量小規(guī)模IM系統(tǒng)技術(shù)要點(diǎn)總結(jié)

[37] 跟著源碼學(xué)IM(十)：*于Netty，搭建高性能IM集群（含技術(shù)思路+源碼）

[38] 一套十萬(wàn)級(jí)TPS的IM綜合消息系統(tǒng)的架構(gòu)實(shí)踐與思考

（本文已同步發(fā)布于：http://www.52im.net/thread-4433-1-1.html）

為了更好地分類閱讀 52im.net 總計(jì)1000多篇精編文章，我將在每周三推送新的一期技術(shù)文集，本次是第21 期。

[- 1 -] 新手入門(mén)：零基礎(chǔ)理解大型分布式架構(gòu)的演進(jìn)歷史、技術(shù)原理、最佳實(shí)踐

[鏈接] http://www.52im.net/thread-2007-1-1.html

[摘要] 本文我們就來(lái)聊聊分布式架構(gòu)的演進(jìn)過(guò)程，希望能給大家?guī)?lái)眼前一亮的感覺(jué)。

[- 2 -] 一篇讀懂分布式架構(gòu)下的負(fù)載均衡技術(shù)：分類、原理、算法、常見(jiàn)方案等

[鏈接] http://www.52im.net/thread-2494-1-1.html

[摘要] 本文將從負(fù)載均衡技術(shù)的分類、技術(shù)原理、常見(jiàn)實(shí)現(xiàn)算法、常用方案等入手，為您詳細(xì)講解負(fù)載均衡技術(shù)的方方面面。這其中，四層和七層負(fù)載均衡技術(shù)最為常用，它們也是本文介紹的重點(diǎn)。

[- 3 -] 從新手到架構(gòu)師，一篇就夠：從100到1000萬(wàn)高并發(fā)的架構(gòu)演進(jìn)之路

[鏈接] http://www.52im.net/thread-2665-1-1.html

[摘要] 本文以設(shè)計(jì)淘寶網(wǎng)的后臺(tái)架構(gòu)為例，介紹從一百個(gè)并發(fā)到千萬(wàn)級(jí)并發(fā)情況下服務(wù)端的架構(gòu)的14次演進(jìn)過(guò)程，同時(shí)列舉出每個(gè)演進(jìn)階段會(huì)遇到的相關(guān)技術(shù)，讓大家對(duì)架構(gòu)的演進(jìn)有一個(gè)整體的認(rèn)知。

[- 4 -] 騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面

[鏈接] http://www.52im.net/thread-1811-1-1.html

[摘要] 本文結(jié)合作者多年的互聯(lián)網(wǎng)系統(tǒng)設(shè)計(jì)實(shí)踐經(jīng)驗(yàn)，從最基本的技術(shù)概念開(kāi)始，帶你探尋服務(wù)器端系統(tǒng)架構(gòu)的方方面面。

[- 5 -] 快速理解高性能HTTP服務(wù)端的負(fù)載均衡技術(shù)原理

[鏈接] http://www.52im.net/thread-1950-1-1.html

[摘要] 本文將以簡(jiǎn)潔通俗的文字，為你講解主流的HTTP服務(wù)端實(shí)現(xiàn)負(fù)載均衡的常見(jiàn)方案，以及具體到方案中的負(fù)載均衡算法的實(shí)現(xiàn)原理。理解和掌握這些方案、算法原理，有助于您今后的互聯(lián)網(wǎng)項(xiàng)的技術(shù)選型和架構(gòu)設(shè)計(jì)，因?yàn)闆](méi)有哪一種方案和算法能解決所有問(wèn)題，只有針對(duì)特定的場(chǎng)景使用合適的方案和算法才是最明智的選擇。

[- 6 -] 知乎技術(shù)分享：從單機(jī)到2000萬(wàn)QPS并發(fā)的Redis高性能緩存實(shí)踐之路

[鏈接] http://www.52im.net/thread-1968-1-1.html

[摘要] 本文作者陳鵬是該系統(tǒng)的負(fù)責(zé)人，本次文章深入介紹了該系統(tǒng)的方方面面，值得互聯(lián)網(wǎng)后端程序員仔細(xì)研究。

[- 7 -] 阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫(kù)技術(shù)方案的10年變遷史

[鏈接] http://www.52im.net/thread-2050-1-1.html

[摘要] 阿里數(shù)據(jù)庫(kù)事業(yè)部研究員張瑞，將為你講述雙11數(shù)據(jù)庫(kù)技術(shù)不為人知的故事。在零點(diǎn)交易數(shù)字一次次提升的背后，既是數(shù)據(jù)庫(kù)技術(shù)的一次次突破，也見(jiàn)證了阿里技術(shù)人永不言敗的精神，每一次化“不可能”為“可能”的過(guò)程都是阿里技術(shù)人對(duì)技術(shù)的不懈追求。

[- 8 -]  阿里技術(shù)分享：阿里自研金融級(jí)數(shù)據(jù)庫(kù)OceanBase的艱辛成長(zhǎng)之路

[鏈接] http://www.52im.net/thread-2072-1-1.html

[摘要] OceanBase 是螞蟻金服自研的分布式數(shù)據(jù)庫(kù)，在其 9 年的發(fā)展歷程里，從艱難上線到找不到業(yè)務(wù)場(chǎng)景瀕臨解散，最后在雙十一的流量考驗(yàn)下浴火重生，成為螞蟻金服全部核心系統(tǒng)的承載數(shù)據(jù)庫(kù)。這一路走來(lái)的艱辛和故事，螞蟻金服高級(jí)研究員、OceanBase 團(tuán)隊(duì)負(fù)責(zé)人陽(yáng)振坤將為你娓娓道來(lái)。

[- 9 -] 達(dá)達(dá)O2O后臺(tái)架構(gòu)演進(jìn)實(shí)踐：從0到4000高并發(fā)請(qǐng)求背后的努力

[鏈接] http://www.52im.net/thread-2141-1-1.html

[摘要] 達(dá)達(dá)的業(yè)務(wù)組成簡(jiǎn)單直接——商家下單、配送員接單和配送，也正因?yàn)槔斫馄饋?lái)簡(jiǎn)單，使得達(dá)達(dá)的業(yè)務(wù)量在短時(shí)間能實(shí)現(xiàn)爆發(fā)式增長(zhǎng)。而支撐業(yè)務(wù)快速增長(zhǎng)的背后，正是達(dá)達(dá)技術(shù)團(tuán)隊(duì)持續(xù)不斷的快速技術(shù)迭代的結(jié)果，本文正好借此機(jī)會(huì)，總結(jié)并分享了這一系列技術(shù)演進(jìn)的第一手實(shí)踐資料，希望能給同樣奮斗在互聯(lián)網(wǎng)創(chuàng)業(yè)一線的你帶來(lái)啟發(fā)。

[- 10 -] 優(yōu)秀后端架構(gòu)師必會(huì)知識(shí)：史上最全MySQL大表優(yōu)化方案總結(jié)

[鏈接] http://www.52im.net/thread-2157-1-1.html

[摘要] 本文將總結(jié)和分享當(dāng)MySQL單表記錄數(shù)過(guò)大時(shí)，增刪改查性能急劇下降問(wèn)題的優(yōu)化思路，這也是資深后端架構(gòu)師、程序員所必備的知識(shí)內(nèi)容之一，希望本文對(duì)你有用。

[- 11 -] 通俗易懂：如何設(shè)計(jì)能支撐百萬(wàn)并發(fā)的數(shù)據(jù)庫(kù)架構(gòu)？

[鏈接] http://www.52im.net/thread-2510-1-1.html

[摘要] 本篇文章我們一起來(lái)學(xué)習(xí)一下，對(duì)于一個(gè)支撐日活百萬(wàn)用戶的高并發(fā)系統(tǒng)，數(shù)據(jù)庫(kù)架構(gòu)應(yīng)該如何設(shè)計(jì)呢？

[- 12 -] 多維度對(duì)比5款主流分布式MQ消息隊(duì)列，媽媽再也不擔(dān)心我的技術(shù)選型了

[鏈接] http://www.52im.net/thread-2625-1-1.html

[摘要] 本文將從17個(gè)維度綜合對(duì)比Kafka、RabbitMQ、ZeroMQ、RocketMQ、ActiveMQ這5款當(dāng)前最主流的MQ消息中間件產(chǎn)品，希望能為您的下一次產(chǎn)品的架構(gòu)設(shè)計(jì)和MQ消息中間件選型提供參考依據(jù)。

[- 13 -] 小米技術(shù)分享：解密小米搶購(gòu)系統(tǒng)千萬(wàn)高并發(fā)架構(gòu)的演進(jìn)和實(shí)踐

[鏈接] http://www.52im.net/thread-2323-1-1.html

[摘要] 本次分享將為大家解密該系統(tǒng)的技術(shù)演進(jìn)、設(shè)計(jì)思路、實(shí)踐總結(jié)等，希望能帶給您啟發(fā)。

[- 14 -] 美團(tuán)技術(shù)分享：深度解密美團(tuán)的分布式ID生成算法

[鏈接] http://www.52im.net/thread-2751-1-1.html

[摘要] 對(duì)于美團(tuán)的Leaf-segment這個(gè)ID生成方案，因?yàn)樯傻腎D全局唯一、全局有序，所以非常適合IM這種應(yīng)用場(chǎng)景，這也是即時(shí)通訊網(wǎng)整理并分享給社區(qū)的原因。

[- 15 -] 12306搶票帶來(lái)的啟示：看我如何用Go實(shí)現(xiàn)百萬(wàn)QPS的秒殺系統(tǒng)(含源碼)

[鏈接] http://www.52im.net/thread-2771-1-1.html

[摘要] 本文內(nèi)容雖是從秒殺系統(tǒng)談起，并未直接涉及即時(shí)通訊相關(guān)知識(shí)，但有關(guān)Go的高并發(fā)實(shí)踐，仍然值得廣大即時(shí)通訊網(wǎng)的技術(shù)愛(ài)好者們研究和學(xué)習(xí)，必竟業(yè)務(wù)可以不同，但技術(shù)都是相通的，或許能為你即時(shí)通訊系統(tǒng)的高并發(fā)架構(gòu)帶來(lái)新的思路和靈感。

??52im社區(qū)本周新文：《企業(yè)微信針對(duì)百萬(wàn)級(jí)組織架構(gòu)的客戶端性能優(yōu)化實(shí)踐 http://www.52im.net/thread-4437-1-1.html》，歡迎閱讀！??

我是Jack Jiang，我為自已帶鹽！https://github.com/JackJiang2011/MobileIMSDK/

為了更好地分類閱讀 52im.net 總計(jì)1000多篇精編文章，我將在每周三推送新的一期技術(shù)文集，本次是第20 期。

[-1-] 融云技術(shù)分享：全面揭秘億級(jí)IM消息的可靠投遞機(jī)制

[鏈接] http://www.52im.net/thread-3638-1-1.html

[摘要] 本文根據(jù)融云億級(jí)IM消息系統(tǒng)的技術(shù)實(shí)踐，總結(jié)了分布式IM消息的可靠投遞機(jī)制，希望能為你的IM開(kāi)發(fā)和知識(shí)學(xué)習(xí)起到拋磚引玉的作用。

 [-2 -] IM開(kāi)發(fā)技術(shù)學(xué)習(xí)：揭秘微信朋友圈這種信息推流背后的系統(tǒng)設(shè)計(jì)

[鏈接] http://www.52im.net/thread-3675-1-1.html

[摘要] 本文將重點(diǎn)討論的是“關(guān)注”功能對(duì)應(yīng)的技術(shù)實(shí)現(xiàn)：先總結(jié)常用的基于時(shí)間線Feed流的后臺(tái)技術(shù)實(shí)現(xiàn)方案，再結(jié)合具體的業(yè)務(wù)場(chǎng)景，根據(jù)實(shí)際需求在基本設(shè)計(jì)思路上做一些靈活的運(yùn)用。

 [-3 -] 阿里IM技術(shù)分享(三)：閑魚(yú)億級(jí)IM消息系統(tǒng)的架構(gòu)演進(jìn)之路

[鏈接] http://www.52im.net/thread-3699-1-1.html

[摘要] 本文分享的是閑魚(yú)即時(shí)消息系統(tǒng)架構(gòu)從零開(kāi)始的技術(shù)變遷之路，以期更多的同行們?cè)诖嘶A(chǔ)上汲取經(jīng)驗(yàn)，得到有價(jià)值的啟發(fā)。

 [-4 -] 阿里IM技術(shù)分享(四)：閑魚(yú)億級(jí)IM消息系統(tǒng)的可靠投遞優(yōu)化實(shí)踐

[鏈接] http://www.52im.net/thread-3706-1-1.html

[摘要] 那么基于閑魚(yú)現(xiàn)有的即時(shí)消息系統(tǒng)架構(gòu)和技術(shù)體系，如何來(lái)優(yōu)化它的消息穩(wěn)定性、可靠性？應(yīng)該從哪里開(kāi)始治理？當(dāng)前系統(tǒng)現(xiàn)狀到底是什么樣？如何客觀進(jìn)行衡量？希望本文能讓大家看到一個(gè)不一樣的閑魚(yú)即時(shí)消息系統(tǒng)。

 [-5 -] 阿里IM技術(shù)分享(五)：閑魚(yú)億級(jí)IM消息系統(tǒng)的及時(shí)性優(yōu)化實(shí)踐

[鏈接] http://www.52im.net/thread-3726-1-1.html

[摘要] 本文將根據(jù)閑魚(yú)IM消息系統(tǒng)在消息及時(shí)性方面的優(yōu)化實(shí)踐，詳細(xì)分析了IM在線通道面臨的各種技術(shù)問(wèn)題，并通過(guò)相應(yīng)的技術(shù)手段來(lái)優(yōu)化從而保證用戶消息的及時(shí)到達(dá)。

 [- 6 -] 阿里IM技術(shù)分享(六)：閑魚(yú)億級(jí)IM消息系統(tǒng)的離線推送到達(dá)率優(yōu)化

[鏈接] http://www.52im.net/thread-3748-1-1.html

[摘要] 本文將要分享的是閑魚(yú)IM消息在解決離線推送的到達(dá)率方面的技術(shù)實(shí)踐，內(nèi)容包括問(wèn)題分析和技術(shù)優(yōu)化思路等，希望能帶給你啟發(fā)。

 [-7-] 阿里IM技術(shù)分享(八)：深度解密釘釘即時(shí)消息服務(wù)DTIM的技術(shù)設(shè)計(jì)

[鏈接] http://www.52im.net/thread-4012-1-1.html

[摘要] 本篇文章內(nèi)容將從模型設(shè)計(jì)原理到具體的技術(shù)架構(gòu)、最底層的存儲(chǔ)模型到跨地域的單元化等，全方位展現(xiàn)了 DTIM 在實(shí)際生產(chǎn)應(yīng)用中所遇到的各種技術(shù)挑戰(zhàn)及相應(yīng)的解決方案，希望借本文內(nèi)容的分享能為國(guó)內(nèi)企業(yè)級(jí)IM的開(kāi)發(fā)帶來(lái)思考和啟發(fā)。

 [-8 -]  阿里IM技術(shù)分享(九)：深度揭密RocketMQ在釘釘IM系統(tǒng)中的應(yīng)用實(shí)踐

[鏈接] http://www.52im.net/thread-4106-1-1.html

[摘要] 在釘釘?shù)腎M中，我們通過(guò) RocketMQ實(shí)現(xiàn)了系統(tǒng)解耦、異步削峰填谷，還通過(guò)定時(shí)消息實(shí)現(xiàn)分布式定時(shí)任務(wù)等高級(jí)特性。同時(shí)與 RocketMQ 深入共創(chuàng)，不斷優(yōu)化解決了很多RocketMQ本身的問(wèn)題，并且孵化出 POP 消費(fèi)模式等新特性，使 RocketMQ 能夠完美支持對(duì)性能穩(wěn)定性和時(shí)延要求非常高的 IM 系統(tǒng)。本文將為你分享這些內(nèi)容。

 [-9 -] 基于實(shí)踐：一套百萬(wàn)消息量小規(guī)模IM系統(tǒng)技術(shù)要點(diǎn)總結(jié)

[鏈接] http://www.52im.net/thread-3752-1-1.html

[摘要] 本文內(nèi)容將從開(kāi)發(fā)者的視角出發(fā)（主要是我自已的開(kāi)發(fā)體會(huì)），圍繞項(xiàng)目背景、業(yè)務(wù)需求、技術(shù)原理、開(kāi)發(fā)方案等主題，一步一步的與大家一起剖析：設(shè)計(jì)一套百萬(wàn)消息量的小規(guī)模IM系統(tǒng)架構(gòu)設(shè)計(jì)上需要注意的技術(shù)要點(diǎn)。

 [-10 -] 跟著源碼學(xué)IM(十)：基于Netty，搭建高性能IM集群（含技術(shù)思路+源碼）

[鏈接] http://www.52im.net/thread-3816-1-1.html

[摘要] 本文將根據(jù)筆者這次的業(yè)余技術(shù)實(shí)踐，為你講述如何基于Netty+Zk+Redis來(lái)搭建一套高性能IM集群，包括本次實(shí)現(xiàn)IM集群的技術(shù)原理和實(shí)例代碼，希望能帶給你啟發(fā)。

 [-11 -] 一套十萬(wàn)級(jí)TPS的IM綜合消息系統(tǒng)的架構(gòu)實(shí)踐與思考

[鏈接] http://www.52im.net/thread-3954-1-1.html

[摘要] 下面就由我來(lái)介紹一下我所負(fù)責(zé)的公司IM綜合消息系統(tǒng)所經(jīng)歷的架構(gòu)設(shè)計(jì)歷程，以及架構(gòu)設(shè)計(jì)過(guò)程中的一些思路和總結(jié)，希望能給你帶來(lái)啟發(fā)。

 [-12 -]  直播系統(tǒng)聊天技術(shù)(八)：vivo直播系統(tǒng)中IM消息模塊的架構(gòu)實(shí)踐

[鏈接] http://www.52im.net/thread-3994-1-1.html

[摘要] 本文針對(duì)秀場(chǎng)直播，結(jié)合我們一年以來(lái)通過(guò)處理不同的業(yè)務(wù)線上問(wèn)題，進(jìn)行了技術(shù)演進(jìn)式的IM消息模塊架構(gòu)的升級(jí)與調(diào)整，并據(jù)此進(jìn)行了技術(shù)總結(jié)、整理成文，希望借此機(jī)會(huì)分享給大家。

 [-13-] 得物從0到1自研客服IM系統(tǒng)的技術(shù)實(shí)踐之路

[鏈接] http://www.52im.net/thread-4153-1-1.html

[摘要] 本篇文章將基于工程實(shí)踐，分享我們從0到1自研一套客服IM系統(tǒng)時(shí)在各種關(guān)鍵技術(shù)點(diǎn)上的設(shè)計(jì)思路和實(shí)踐方法。

 [-14-] 海量用戶IM聊天室的架構(gòu)設(shè)計(jì)與實(shí)踐

[鏈接] http://www.52im.net/thread-4404-1-1.html

[摘要] 本文將分享網(wǎng)易云信針對(duì)海量用戶IM聊天室的架構(gòu)設(shè)計(jì)與應(yīng)用實(shí)踐，希望能帶給你啟發(fā)。

??52im社區(qū)本周新文：《IM跨平臺(tái)技術(shù)學(xué)習(xí)(九)：全面解密新QQ桌面版的Electron內(nèi)存優(yōu)化實(shí)踐 http://www.52im.net/thread-4429-1-1.html》，歡迎閱讀！??

我是Jack Jiang，我為自已帶鹽！https://github.com/JackJiang2011/MobileIMSDK/