<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    Jack Jiang

    我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
    posts - 494, comments - 13, trackbacks - 0, articles - 1

    1、引言

    IM等社交應用的開發(fā)工作中,亂碼問題也很常見,比如:

    1)IM聊天消息中的Emoji表情為什么發(fā)給后端后MySQL數(shù)據(jù)庫里會亂碼;

    2)文件名中帶有中文的大文件聊天消息發(fā)送后,對方看到的文名是亂碼;

    3)Http rest接口調用時,后端讀取到APP端傳過來的參數(shù)有中文亂碼問題;

    ... ...

    那么,對于亂碼這個看似不起眼,但并不是一兩話能講清楚的問題,是很有必要從根源了解字符集和編碼原理,知其然知其所以然顯然是一個優(yōu)秀碼農的基本素養(yǎng),所以,便有了本文,希望能幫助到你。

    * 推薦閱讀:關于字符編碼知識的詳細講解請見《字符編碼那點事:快速理解ASCII、Unicode、GBK和UTF-8》。

    學習交流:

    - 即時通訊/推送技術開發(fā)交流5群:215477170 [推薦]

    - 移動端IM開發(fā)入門文章:《新手入門一篇就夠:從零開發(fā)移動端IM

    (本文同步發(fā)布于:http://www.52im.net/thread-2868-1-1.html

    2、關于作者 

    盧鈞軼:愛搗騰Linux的DBA。曾任職于大眾點評網(wǎng)DBA團隊,主要關注MySQL、Memcache、MMM等產(chǎn)品的高性能和高可用架構。

    個人微博:米雪兒儂好的cenalulu

    Github地址:https://github.com/cenalulu

    3、系列文章

    本文是IM開發(fā)干貨系列文章中的第21篇,總目錄如下:

    IM消息送達保證機制實現(xiàn)(一):保證在線實時消息的可靠投遞

    IM消息送達保證機制實現(xiàn)(二):保證離線消息的可靠投遞

    如何保證IM實時消息的“時序性”與“一致性”?

    IM單聊和群聊中的在線狀態(tài)同步應該用“推”還是“拉”?

    IM群聊消息如此復雜,如何保證不丟不重?

    一種Android端IM智能心跳算法的設計與實現(xiàn)探討(含樣例代碼)

    移動端IM登錄時拉取數(shù)據(jù)如何作到省流量?

    通俗易懂:基于集群的移動端IM接入層負載均衡方案分享

    淺談移動端IM的多點登陸和消息漫游原理

    IM開發(fā)基礎知識補課(一):正確理解前置HTTP SSO單點登陸接口的原理

    IM開發(fā)基礎知識補課(二):如何設計大量圖片文件的服務端存儲架構?

    IM開發(fā)基礎知識補課(三):快速理解服務端數(shù)據(jù)庫讀寫分離原理及實踐建議

    IM開發(fā)基礎知識補課(四):正確理解HTTP短連接中的Cookie、Session和Token

    IM群聊消息的已讀回執(zhí)功能該怎么實現(xiàn)?

    IM群聊消息究竟是存1份(即擴散讀)還是存多份(即擴散寫)?

    IM開發(fā)基礎知識補課(五):通俗易懂,正確理解并用好MQ消息隊列

    一個低成本確保IM消息時序的方法探討

    IM開發(fā)基礎知識補課(六):數(shù)據(jù)庫用NoSQL還是SQL?讀這篇就夠了!

    IM里“附近的人”功能實現(xiàn)原理是什么?如何高效率地實現(xiàn)它?

    IM開發(fā)基礎知識補課(七):主流移動端賬號登錄方式的原理及設計思路

    IM開發(fā)基礎知識補課(八):史上最通俗,徹底搞懂字符亂碼問題的本質》(本文

    4、正文概述

    字符集和編碼無疑是IT菜鳥甚至是各種大神的頭痛問題。當遇到紛繁復雜的字符集,各種火星文和亂碼時,問題的定位往往變得非常困難。

    本文內容就將會從原理方面對字符集和編碼做個簡單的科普介紹,同時也會介紹一些通用的亂碼故障定位的方法以方便讀者以后能夠更從容的定位相關問題。

    在正式介紹之前,先做個小申明:如果你希望非常精確的理解各個名詞的解釋,那么可以詳細閱讀這篇《字符編碼那點事:快速理解ASCII、Unicode、GBK和UTF-8》。

    本文是博主通過自己理解消化后并轉化成易懂淺顯的表述后的介紹,會盡量以簡單明了的文字來從要源講解字符集、字符編碼的概念,以及在遭遇亂碼時的一些常用診斷技巧,希望能助你對于“亂碼”問題有更深地理解。

    5、什么是字符集

    在介紹字符集之前,我們先了解下為什么要有字符集。

    我們在計算機屏幕上看到的是實體化的文字,而在計算機存儲介質中存放的實際是二進制的比特流。那么在這兩者之間的轉換規(guī)則就需要一個統(tǒng)一的標準,否則把我們的U盤插到老板的電腦上,文檔就亂碼了;小伙伴QQ上傳過來的文件,在我們本地打開又亂碼了。

    于是為了實現(xiàn)轉換標準,各種字符集標準就出現(xiàn)了。

    簡單的說:字符集就規(guī)定了某個文字對應的二進制數(shù)字存放方式(編碼)和某串二進制數(shù)值代表了哪個文字(解碼)的轉換關系。 

    那么為什么會有那么多字符集標準呢?

    這個問題實際非常容易回答。問問自己為什么我們的插頭拿到英國就不能用了呢?為什么顯示器同時有DVI、VGA、HDMI、DP這么多接口呢?很多規(guī)范和標準在最初制定時并不會意識到這將會是以后全球普適的準則,或者處于組織本身利益就想從本質上區(qū)別于現(xiàn)有標準。于是,就產(chǎn)生了那么多具有相同效果但又不相互兼容的標準了。 

    說了那么多我們來看一個實際例子,下面就是“屌”這個字在各種編碼下的十六進制和二進制編碼結果,怎么樣有沒有一種很屌的感覺?

     

    6、什么是字符編碼

    字符集只是一個規(guī)則集合的名字,對應到真實生活中,字符集就是對某種語言的稱呼。例如:英語,漢語,日語。

    對于一個字符集來說要正確編碼轉碼一個字符需要三個關鍵元素:

    1)字庫表(character repertoire):是一個相當于所有可讀或者可顯示字符的數(shù)據(jù)庫,字庫表決定了整個字符集能夠展現(xiàn)表示的所有字符的范圍;

    2)編碼字符集(coded character set):即用一個編碼值code point來表示一個字符在字庫中的位置;

    3)字符編碼(character encoding form):將編碼字符集和實際存儲數(shù)值之間的轉換關系。

    一般來說都會直接將code point的值作為編碼后的值直接存儲。例如在ASCII中“A”在表中排第65位,而編碼后A的數(shù)值是 0100 0001 也即十進制的65的二進制轉換結果。

    看到這里,可能很多讀者都會有和我當初一樣的疑問:字庫表和編碼字符集看來是必不可少的,那既然字庫表中的每一個字符都有一個自己的序號,直接把序號作為存儲內容就好了。為什么還要多此一舉通過字符編碼把序號轉換成另外一種存儲格式呢?

    其實原因也比較容易理解:統(tǒng)一字庫表的目的是為了能夠涵蓋世界上所有的字符,但實際使用過程中會發(fā)現(xiàn)真正用的上的字符相對整個字庫表來說比例非常低。例如中文地區(qū)的程序幾乎不會需要日語字符,而一些英語國家甚至簡單的ASCII字庫表就能滿足基本需求。而如果把每個字符都用字庫表中的序號來存儲的話,每個字符就需要3個字節(jié)(這里以Unicode字庫為例),這樣對于原本用僅占一個字符的ASCII編碼的英語地區(qū)國家顯然是一個額外成本(存儲體積是原來的三倍)。算的直接一些,同樣一塊硬盤,用ASCII可以存1500篇文章,而用3字節(jié)Unicode序號存儲只能存500篇。于是就出現(xiàn)了UTF-8這樣的變長編碼。在UTF-8編碼中原本只需要一個字節(jié)的ASCII字符,仍然只占一個字節(jié)。而像中文及日語這樣的復雜字符就需要2個到3個字節(jié)來存儲。

    關于字符編碼知識的詳細講解請見:字符編碼那點事:快速理解ASCII、Unicode、GBK和UTF-8》。

    7、UTF-8和Unicode的關系

    看完上面兩個概念解釋,那么解釋UTF-8和Unicode的關系就比較簡單了。

    Unicode就是上文中提到的編碼字符集,而UTF-8就是字符編碼,即Unicode規(guī)則字庫的一種實現(xiàn)形式。

    隨著互聯(lián)網(wǎng)的發(fā)展,對同一字庫集的要求越來越迫切,Unicode標準也就自然而然的出現(xiàn)。它幾乎涵蓋了各個國家語言可能出現(xiàn)的符號和文字,并將為他們編號。詳見:Unicode百科介紹

    Unicode的編號從 0000 開始一直到10FFFF 共分為17個Plane,每個Plane中有65536個字符。而UTF-8則只實現(xiàn)了第一個Plane,可見UTF-8雖然是一個當今接受度最廣的字符集編碼,但是它并沒有涵蓋整個Unicode的字庫,這也造成了它在某些場景下對于特殊字符的處理困難(下文會有提到)。

    8、UTF-8編碼簡介

    為了更好的理解后面的實際應用,我們這里簡單的介紹下UTF-8的編碼實現(xiàn)方法。即UTF-8的物理存儲和Unicode序號的轉換關系。 

    UTF-8編碼為變長編碼,最小編碼單位(code unit)為一個字節(jié)。一個字節(jié)的前1-3個bit為描述性部分,后面為實際序號部分:

    • 1)如果一個字節(jié)的第一位為0,那么代表當前字符為單字節(jié)字符,占用一個字節(jié)的空間。0之后的所有部分(7個bit)代表在Unicode中的序號;
    • 2)如果一個字節(jié)以110開頭,那么代表當前字符為雙字節(jié)字符,占用2個字節(jié)的空間。110之后的所有部分(5個bit)加上后一個字節(jié)的除10外的部分(6個bit)代表在Unicode中的序號。且第二個字節(jié)以10開頭;
    • 3)如果一個字節(jié)以1110開頭,那么代表當前字符為三字節(jié)字符,占用3個字節(jié)的空間。110之后的所有部分(5個bit)加上后兩個字節(jié)的除10外的部分(12個bit)代表在Unicode中的序號。且第二、第三個字節(jié)以10開頭;
    • 4)如果一個字節(jié)以10開頭,那么代表當前字節(jié)為多字節(jié)字符的第二個字節(jié)。10之后的所有部分(6個bit)和之前的部分一同組成在Unicode中的序號。

    具體每個字節(jié)的特征可見下表,其中“x”代表序號部分,把各個字節(jié)中的所有x部分拼接在一起就組成了在Unicode字庫中的序號。如下圖所示。

     
     

    我們分別看三個從一個字節(jié)到三個字節(jié)的UTF-8編碼例子: 

     

    細心的讀者不難從以上的簡單介紹中得出以下規(guī)律:

    1)3個字節(jié)的UTF-8十六進制編碼一定是以E開頭的;

    2)2個字節(jié)的UTF-8十六進制編碼一定是以C或D開頭的;

    3)1個字節(jié)的UTF-8十六進制編碼一定是以比8小的數(shù)字開頭的。

    9、為什么會出現(xiàn)亂碼

    亂碼也就是英文常說的mojibake(由日語的文字化け音譯)。

    簡單的說亂碼的出現(xiàn)是因為:編碼和解碼時用了不同或者不兼容的字符集。

    對應到真實生活中:就好比是一個英國人為了表示祝福在紙上寫了bless(編碼過程)。而一個法國人拿到了這張紙,由于在法語中bless表示受傷的意思,所以認為他想表達的是受傷(解碼過程)。這個就是一個現(xiàn)實生活中的亂碼情況。

    在計算機科學中一樣:一個用UTF-8編碼后的字符,用GBK去解碼。由于兩個字符集的字庫表不一樣,同一個漢字在兩個字符表的位置也不同,最終就會出現(xiàn)亂碼。 

     

    我們來看一個例子,假設我們用UTF-8編碼存儲“很屌”兩個字,會有如下轉換:

     

    于是我們得到了E5BE88E5B18C這么一串數(shù)值,而顯示時我們用GBK解碼進行展示,通過查表我們獲得以下信息: 

    解碼后我們就得到了“寰堝睂”這么一個錯誤的結果,更要命的是連字符個數(shù)都變了。

    10、如何識別亂碼的本來想要表達的文字

    要從亂碼字符中反解出原來的正確文字需要對各個字符集編碼規(guī)則有較為深刻的掌握。但是原理很簡單,這里用以MySQL數(shù)據(jù)庫中的數(shù)據(jù)操縱中最常見的UTF-8被錯誤用GBK展示時的亂碼為例,來說明具體反解和識別過程。

    10.1 第1步:編碼

    假設我們在頁面上看到“寰堝睂”這樣的亂碼,而又得知我們的瀏覽器當前使用GBK編碼。那么第一步我們就能先通過GBK把亂碼編碼成二進制表達式。

    當然查表編碼效率很低,我們也可以用以下SQL語句直接通過MySQL客戶端來做編碼工作:

    mysql [localhost] {msandbox} > selecthex(convert('寰堝睂'using gbk));

    +-------------------------------------+

    | hex(convert('寰堝睂'using gbk))    |

    +-------------------------------------+

    | E5BE88E5B18C                        |

    +-------------------------------------+

    1 row inset(0.01 sec)

    10.2 第2步:識別

    現(xiàn)在我們得到了解碼后的二進制字符串E5BE88E5B18C。然后我們將它按字節(jié)拆開。

     

    然后套用之前UTF-8編碼介紹章節(jié)中總結出的規(guī)律,就不難發(fā)現(xiàn)這6個字節(jié)的數(shù)據(jù)符合UTF-8編碼規(guī)則。如果整個數(shù)據(jù)流都符合這個規(guī)則的話,我們就能大膽假設亂碼之前的編碼字符集是UTF-8。

    10.3 第3步:解碼

    然后我們就能拿著 E5BE88E5B18C 用UTF-8解碼,查看亂碼前的文字了。

    當然我們可以不查表直接通過SQL獲得結果:

    mysql [localhost] {msandbox} ((none)) > selectconvert(0xE5BE88E5B18C using utf8);

    +------------------------------------+

    | convert(0xE5BE88E5B18C using utf8) |

    +------------------------------------+

    | 很屌                               |

    +------------------------------------+

    1 row inset(0.00 sec)

    11、常見的IM亂碼問題處理之MySQL中的Emoji字符

    所謂Emoji就是一種在Unicode位于 \u1F601-\u1F64F 區(qū)段的字符。這個顯然超過了目前常用的UTF-8字符集的編碼范圍 \u0000-\uFFFF。Emoji表情隨著IOS的普及和微信的支持越來越常見。

    下面就是幾個常見的Emoji(IM聊天軟件中經(jīng)常會被用到):

    那么Emoji字符表情會對我們平時的開發(fā)運維帶來什么影響呢?

    最常見的問題就在于將他存入MySQL數(shù)據(jù)庫的時候。一般來說MySQL數(shù)據(jù)庫的默認字符集都會配置成UTF-8(三字節(jié)),而utf8mb4在5.5以后才被支持,也很少會有DBA主動將系統(tǒng)默認字符集改成utf8mb4。

    那么問題就來了,當我們把一個需要4字節(jié)UTF-8編碼才能表示的字符存入數(shù)據(jù)庫的時候就會報錯:ERROR 1366: Incorrect string value: '\xF0\x9D\x8C\x86' for column 。 

    如果認真閱讀了上面的解釋,那么這個報錯也就不難看懂了:我們試圖將一串Bytes插入到一列中,而這串Bytes的第一個字節(jié)是 \xF0 意味著這是一個四字節(jié)的UTF-8編碼。但是當MySQL表和列字符集配置為UTF-8的時候是無法存儲這樣的字符的,所以報了錯。 

    那么遇到這種情況我們如何解決呢?

    有兩種方式:

    • 1)升級MySQL到5.6或更高版本,并且將表字符集切換至utf8mb4;
    • 2)在把內容存入到數(shù)據(jù)庫之前做一次過濾,將Emoji字符替換成一段特殊的文字編碼,然后再存入數(shù)據(jù)庫中。之后從數(shù)據(jù)庫獲取或者前端展示時再將這段特殊文字編碼轉換成Emoji顯示。

    第二種方法我們假設用 -*-1F601-*- 來替代4字節(jié)的Emoji,那么具體實現(xiàn)python代碼可以參見Stackoverflow上的回答

    12、參考文獻

    附錄:更多IM開發(fā)方面的文章

    [1] IM開發(fā)綜合文章:

    新手入門一篇就夠:從零開發(fā)移動端IM

    移動端IM開發(fā)者必讀(一):通俗易懂,理解移動網(wǎng)絡的“弱”和“慢”

    移動端IM開發(fā)者必讀(二):史上最全移動弱網(wǎng)絡優(yōu)化方法總結

    從客戶端的角度來談談移動端IM的消息可靠性和送達機制

    現(xiàn)代移動端網(wǎng)絡短連接的優(yōu)化手段總結:請求速度、弱網(wǎng)適應、安全保障

    騰訊技術分享:社交網(wǎng)絡圖片的帶寬壓縮技術演進之路

    小白必讀:閑話HTTP短連接中的Session和Token

    IM開發(fā)基礎知識補課:正確理解前置HTTP SSO單點登陸接口的原理

    移動端IM開發(fā)需要面對的技術問題

    開發(fā)IM是自己設計協(xié)議用字節(jié)流好還是字符流好?

    請問有人知道語音留言聊天的主流實現(xiàn)方式嗎?

    一個低成本確保IM消息時序的方法探討

    完全自已開發(fā)的IM該如何設計“失敗重試”機制?

    通俗易懂:基于集群的移動端IM接入層負載均衡方案分享

    微信對網(wǎng)絡影響的技術試驗及分析(論文全文)

    即時通訊系統(tǒng)的原理、技術和應用(技術論文)

    開源IM工程“蘑菇街TeamTalk”的現(xiàn)狀:一場有始無終的開源秀

    QQ音樂團隊分享:Android中的圖片壓縮技術詳解(上篇)

    QQ音樂團隊分享:Android中的圖片壓縮技術詳解(下篇)

    騰訊原創(chuàng)分享(一):如何大幅提升移動網(wǎng)絡下手機QQ的圖片傳輸速度和成功率

    騰訊原創(chuàng)分享(二):如何大幅壓縮移動網(wǎng)絡下APP的流量消耗(上篇)

    騰訊原創(chuàng)分享(三):如何大幅壓縮移動網(wǎng)絡下APP的流量消耗(下篇)

    如約而至:微信自用的移動端IM網(wǎng)絡層跨平臺組件庫Mars已正式開源

    基于社交網(wǎng)絡的Yelp是如何實現(xiàn)海量用戶圖片的無損壓縮的?

    騰訊技術分享:騰訊是如何大幅降低帶寬和網(wǎng)絡流量的(圖片壓縮篇)

    騰訊技術分享:騰訊是如何大幅降低帶寬和網(wǎng)絡流量的(音視頻技術篇)

    字符編碼那點事:快速理解ASCII、Unicode、GBK和UTF-8

    全面掌握移動端主流圖片格式的特點、性能、調優(yōu)等

    子彈短信光鮮的背后:網(wǎng)易云信首席架構師分享億級IM平臺的技術實踐

    微信技術分享:微信的海量IM聊天消息序列號生成實踐(算法原理篇)

    自已開發(fā)IM有那么難嗎?手把手教你自擼一個Andriod版簡易IM (有源碼)

    融云技術分享:解密融云IM產(chǎn)品的聊天消息ID生成策略

    適合新手:從零開發(fā)一個IM服務端(基于Netty,有完整源碼)

    拿起鍵盤就是干:跟我一起徒手開發(fā)一套分布式IM系統(tǒng)

    >> 更多同類文章 …… 

     

    [2] 有關IM架構設計的文章:

    淺談IM系統(tǒng)的架構設計

    簡述移動端IM開發(fā)的那些坑:架構設計、通信協(xié)議和客戶端

    一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)

    一套原創(chuàng)分布式即時通訊(IM)系統(tǒng)理論架構方案

    從零到卓越:京東客服即時通訊系統(tǒng)的技術架構演進歷程

    蘑菇街即時通訊/IM服務器開發(fā)之架構選擇

    騰訊QQ1.4億在線用戶的技術挑戰(zhàn)和架構演進之路PPT

    微信后臺基于時間序的海量數(shù)據(jù)冷熱分級架構設計實踐

    微信技術總監(jiān)談架構:微信之道——大道至簡(演講全文)

    如何解讀《微信技術總監(jiān)談架構:微信之道——大道至簡》

    快速裂變:見證微信強大后臺架構從0到1的演進歷程(一)

    17年的實踐:騰訊海量產(chǎn)品的技術方法論

    移動端IM中大規(guī)模群消息的推送如何保證效率、實時性?

    現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲方案探討

    IM開發(fā)基礎知識補課(二):如何設計大量圖片文件的服務端存儲架構?

    IM開發(fā)基礎知識補課(三):快速理解服務端數(shù)據(jù)庫讀寫分離原理及實踐建議

    IM開發(fā)基礎知識補課(四):正確理解HTTP短連接中的Cookie、Session和Token

    WhatsApp技術實踐分享:32人工程團隊創(chuàng)造的技術神話

    微信朋友圈千億訪問量背后的技術挑戰(zhàn)和實踐總結

    王者榮耀2億用戶量的背后:產(chǎn)品定位、技術架構、網(wǎng)絡方案等

    IM系統(tǒng)的MQ消息中間件選型:Kafka還是RabbitMQ?

    騰訊資深架構師干貨總結:一文讀懂大型分布式系統(tǒng)設計的方方面面

    以微博類應用場景為例,總結海量社交系統(tǒng)的架構設計步驟

    快速理解高性能HTTP服務端的負載均衡技術原理

    子彈短信光鮮的背后:網(wǎng)易云信首席架構師分享億級IM平臺的技術實踐

    知乎技術分享:從單機到2000萬QPS并發(fā)的Redis高性能緩存實踐之路

    IM開發(fā)基礎知識補課(五):通俗易懂,正確理解并用好MQ消息隊列

    微信技術分享:微信的海量IM聊天消息序列號生成實踐(算法原理篇)

    微信技術分享:微信的海量IM聊天消息序列號生成實踐(容災方案篇)

    新手入門:零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐

    一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構方案設計實踐

    阿里技術分享:深度揭秘阿里數(shù)據(jù)庫技術方案的10年變遷史

    阿里技術分享:阿里自研金融級數(shù)據(jù)庫OceanBase的艱辛成長之路

    社交軟件紅包技術解密(一):全面解密QQ紅包技術方案——架構、技術實現(xiàn)等

    社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進

    社交軟件紅包技術解密(三):微信搖一搖紅包雨背后的技術細節(jié)

    社交軟件紅包技術解密(四):微信紅包系統(tǒng)是如何應對高并發(fā)的

    社交軟件紅包技術解密(五):微信紅包系統(tǒng)是如何實現(xiàn)高可用性的

    社交軟件紅包技術解密(六):微信紅包系統(tǒng)的存儲層架構演進實踐

    社交軟件紅包技術解密(七):支付寶紅包的海量高并發(fā)技術實踐

    社交軟件紅包技術解密(八):全面解密微博紅包技術方案

    社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等

    即時通訊新手入門:一文讀懂什么是Nginx?它能否實現(xiàn)IM的負載均衡?

    即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途

    多維度對比5款主流分布式MQ消息隊列,媽媽再也不擔心我的技術選型了

    從游擊隊到正規(guī)軍(一):馬蜂窩旅游網(wǎng)的IM系統(tǒng)架構演進之路

    從游擊隊到正規(guī)軍(二):馬蜂窩旅游網(wǎng)的IM客戶端架構演進和實踐總結

    IM開發(fā)基礎知識補課(六):數(shù)據(jù)庫用NoSQL還是SQL?讀這篇就夠了!

    瓜子IM智能客服系統(tǒng)的數(shù)據(jù)架構設計(整理自現(xiàn)場演講,有配套PPT)

    阿里釘釘技術分享:企業(yè)級IM王者——釘釘在后端架構上的過人之處

    >> 更多同類文章 ……

    (本文同步發(fā)布于:http://www.52im.net/thread-2868-1-1.html



    作者:Jack Jiang (點擊作者姓名進入Github)
    出處:http://www.52im.net/space-uid-1.html
    交流:歡迎加入即時通訊開發(fā)交流群 215891622
    討論:http://www.52im.net/
    Jack Jiang同時是【原創(chuàng)Java Swing外觀工程BeautyEye】【輕量級移動端即時通訊框架MobileIMSDK】的作者,可前往下載交流。
    本博文 歡迎轉載,轉載請注明出處(也可前往 我的52im.net 找到我)。


    只有注冊用戶登錄后才能發(fā)表評論。


    網(wǎng)站導航:
     
    Jack Jiang的 Mail: jb2011@163.com, 聯(lián)系QQ: 413980957, 微信: hellojackjiang
    主站蜘蛛池模板: 色欲aⅴ亚洲情无码AV| 国产精品免费高清在线观看| 天堂亚洲免费视频| 国产在线播放线91免费 | 亚洲精品动漫在线| 毛片免费视频播放| 国产精品无码永久免费888| 亚洲AV区无码字幕中文色| 女人张开腿给人桶免费视频| 美女网站在线观看视频免费的| 亚洲欧洲另类春色校园网站| 国产亚洲精品精品国产亚洲综合| 国产成人精品免费午夜app| 噜噜噜亚洲色成人网站| 亚洲视频在线观看免费视频| 国产又长又粗又爽免费视频| 8x网站免费入口在线观看| 老司机午夜精品视频在线观看免费| 亚洲综合激情另类小说区| 亚洲色偷拍区另类无码专区| 老司机在线免费视频| 成在人线av无码免费高潮水| 人人狠狠综合久久亚洲| 亚洲日本在线免费观看| 国产偷v国产偷v亚洲高清| 国产在线观看免费视频播放器| 亚洲免费一级视频| 最近国语视频在线观看免费播放| 亚洲Aⅴ在线无码播放毛片一线天| 97亚洲熟妇自偷自拍另类图片| 亚洲国产精品丝袜在线观看| 女人18毛片水真多免费播放| 亚洲免费一级视频| 免费成人在线电影| 国产福利在线观看永久免费| 亚洲欧美在线x视频| 成人区精品一区二区不卡亚洲| 亚洲啪啪免费视频| 亚洲综合在线观看视频| 亚洲精品国精品久久99热一| 亚洲成片观看四虎永久|