整合營銷服務(wù)商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
先流量統(tǒng)計的標(biāo)準(zhǔn) 一般分為兩種情況，第一種是后端直接做的統(tǒng)計，這種比較好搞，直接requests獲取源代碼就可以統(tǒng)計到了，但是大部分是另一種情況，使用CNZZ站長統(tǒng)計、百度統(tǒng)計等，這類統(tǒng)計使用外部js加載統(tǒng)計的，這種直接使用requests獲取源代碼理論是解析不了js的，沒去測試，想了一種模擬真實瀏覽器去解析js請求，使用spynner擴(kuò)展就可以了，然后需要獲取有效代理，使用有效代理訪問就可以了。
看了下主要用到 spynner 的下面幾個方法：
#創(chuàng)建一個瀏覽器對象
browser = spynner.Browser()
#打開瀏覽器，并隱藏或顯示
browser.hide()
browser.show()
#webkit加載頁面
browser.load(“http://www.0535code.com”)
print browser.html.encode(“utf-8″)
#關(guān)閉該瀏覽器并刪掉實例
browser.close()
del browser
#使用jquery
browser.load_jquery(True)
browser.radio(‘#radiomea’)
browser.wk_check(‘#checkmea’)
browser.check(‘#checkmea’)
browser.wk_select(‘#sel’, ‘a(chǎn)a’)
browser.select(‘#asel option[name=”bbb”]’, remove=False)
browser.fill(‘input[name=”w”]’, ‘foo’)
#配置代理和使用代理下載
browser.set_proxy(‘http://127.0.0.1:8888’)
browser.download(‘http://0535code.com’, proxy_url=’http://127.0.0.1:8888′)
作者：網(wǎng)癡
SP.NET 類參考手冊
| 方法 | 描述 |
|---|---|
| AsBool(), AsBool(true|false) | 轉(zhuǎn)換字符串值為布爾值（true/false）。如果字符串不能轉(zhuǎn)換為true/false，則返回 false 或者其他規(guī)定的值。 |
| AsDateTime(), AsDateTime(value) | 轉(zhuǎn)換字符串值為日期/時間。返回 DateTime。如果字符串不能轉(zhuǎn)換為日期/時間，則返回 MinValue 或者其他規(guī)定的值。 |
| AsDecimal(), AsDecimal(value) | 轉(zhuǎn)換字符串值為十進(jìn)制值。如果字符串不能轉(zhuǎn)換為十進(jìn)制值，則返回 0.0 或者其他規(guī)定的值。 |
| AsFloat(), AsFloat(value) | 轉(zhuǎn)換字符串值為浮點數(shù)。如果字符串不能轉(zhuǎn)換為浮點數(shù)，則返回 0.0 或者其他規(guī)定的值。 |
| AsInt(), AsInt(value) | 轉(zhuǎn)換字符串值為整數(shù)。如果字符串不能轉(zhuǎn)換成整數(shù)，則返回 0 或者其他規(guī)定的值。 |
| Href(path [, param1 [, param2]]) | 從帶有可選的附加路徑部分的本地文件路徑創(chuàng)建一個瀏覽器兼容的 URL。 |
| Html.Raw(value) | Renders value 呈現(xiàn)為 HTML 標(biāo)記，而不是呈現(xiàn)為 HTML 編碼輸出。 |
| IsBool(), IsDateTime(), IsDecimal(), IsFloat(), IsInt() | 如果該值可以從字符串轉(zhuǎn)換為指定的類型，則返回 true。 |
| IsEmpty() | 如果對象或者變量沒有值，則返回 true。 |
| IsPost | 如果請求是 POST，則返回 true。（初始請求通常是 GET。） |
| Layout | 規(guī)定布局頁面的路徑應(yīng)用到此頁面。 |
| PageData[key], PageData[index], Page | 在當(dāng)前請求的頁面、布局頁面、部分頁面之間包含共享數(shù)據(jù)。您可以使用動態(tài)頁面來對相同的數(shù)據(jù)進(jìn)行屬性訪問。 |
| RenderBody() | (Layout pages) 呈現(xiàn)沒有在布局頁面任何命名區(qū)域的內(nèi)容頁的內(nèi)容Renders the content of a content page that is not in any named sections. |
| RenderPage(path, values) RenderPage(path[, param1 [, param2]]) | 呈現(xiàn)使用了規(guī)定的路徑和可選的額外數(shù)據(jù)的內(nèi)容頁。您可以通過 position（實例 1）或者 key（實例 2）從 PageData 獲取額外參數(shù)的值。 |
| RenderSection(sectionName [, required = true|false]) | (Layout pages) 呈現(xiàn)一個有名字的內(nèi)容區(qū)域。設(shè)置 required讓一個區(qū)域為必需非可選的。 |
| Request.Cookies[key] | 獲取或者設(shè)置 HTTP cookie 的值。 |
| Request.Files[key] | Gets 在當(dāng)前請求中上傳的文件。 |
| Request.Form[key] | 獲取在表單中 post 的數(shù)據(jù)（作為字符串）。Request.Form 和 Request.QueryString 都要求[key] 檢查。 |
| Request.QueryString[key] | 獲取 URL 查詢字符串中規(guī)定的數(shù)據(jù)。Request.Form 和 Request.QueryString 都要求[key] 檢查。 |
| Request.Unvalidated(key) Request.Unvalidated().QueryString|Form|Cookies|Headers[key] | 有選擇地禁用請求驗證（表單元素、查詢字符串值、cookie、header 值）。請求驗證默認(rèn)是開啟的，防止用戶提交標(biāo)記或者其他潛在的危險內(nèi)容。 |
| Response.AddHeader(name, value) | 在應(yīng)答中添加一個 HTTP 服務(wù)器響應(yīng)頭。 |
| Response.OutputCache(seconds [, sliding] [, varyByParams]) | Caches 在指定時間的頁面輸出緩存。設(shè)置 sliding 來重置每個頁面的訪問超時時間，設(shè)置 varyByParams 為請求頁面的每個不同的查詢字符串緩存不同版本的頁面。 |
| Response.Redirect(path) | 重定向瀏覽器請求到一個新的位置。 |
| Response.SetStatus(httpStatusCode) | 設(shè)置HTTP狀態(tài)代碼發(fā)送到瀏覽器。 |
| Response.WriteBinary(data [, mimetype]) | 寫入 data 內(nèi)容響應(yīng)可選的MIME類型。 |
| Response.WriteFile(file) | 寫入文件內(nèi)容響應(yīng)。 |
| @section(sectionName) { content } | （布局頁面）定義一個有名字的內(nèi)容區(qū)域。 |
| Server.HtmlDecode(htmlText) | 解碼一個HTML編碼的字符串。 |
| Server.HtmlEncode(text) | 為呈現(xiàn)在 HTML 標(biāo)記中的字符串編碼。 |
| Server.MapPath(virtualPath) | 為指定的虛擬路徑返回服務(wù)器的物理路徑。 |
| Server.UrlDecode(urlText) | 解碼URL文本。 |
| Server.UrlEncode(text) | URL文本編碼。 |
| Session[key] | 獲取或設(shè)置一個存在的值，直到用戶關(guān)閉瀏覽器。 |
| ToString() | 顯示一個用字符串表示的對象的值。 |
| UrlData[index] | 從 URL 獲取額外的數(shù)據(jù)（例如，/MyPage/ExtraData）。 |
文由字節(jié)教育-成人與創(chuàng)新前端團(tuán)隊分享，本文有修訂和改動。
作為開發(fā)人員，工作中我們可能會遇到以下問題：
以上這些問題都涉及到計算機中*礎(chǔ)的知識點——字符集及字符編碼的概念，本篇將從前端開發(fā)人員的視解，讓你徹底搞清并理解這些問題的本質(zhì)。
本文是系列文章中的第 5 篇，本系列總目錄如下：
首先通過 wiki 中關(guān)于字符編碼（Character_encoding）的定義來引入幾個概念：
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ìn)行存儲、傳輸和轉(zhuǎn)換。組成字符編碼的數(shù)值稱為“碼位”，它們共同組成“代碼空間”、“代碼頁”或“字符映射”。
這里所說的代碼頁（Code Page）其實就可以理解為編碼字符集（coded character set），如 Unicode、GBK 字符集等。
簡單來說：字符編碼就是將字符映射為固定的碼位值，存儲在對應(yīng)的編碼字符集中。在不同的字符集中，同一個字符的碼位不同。其中碼位也有翻譯成碼點或者內(nèi)碼。
我們知道在計算機存儲數(shù)據(jù)時要使用二進(jìn)制進(jìn)行表示。而最初計算機只在美國使用，因此人們要考慮如何使用二進(jìn)制來表達(dá) 52 個英文字母(包括大小寫)、阿拉伯?dāng)?shù)字(0-9)以及常用的符號(如! @ # $ 等)。
于是便有從電報碼發(fā)展而來的 ASCII（American Standard Code for Information Interchange，美國信息交換標(biāo)準(zhǔn)代碼）(發(fā)音 /??ski/)編碼。它定義了英文字符和二進(jìn)制的對應(yīng)關(guān)系，一直沿用至今。
它采用了單字節(jié)編碼方案（SBCS） ，一個字節(jié)的首位 bit 為 0，用其余 7 個 bit 來表示 128 個字符（范圍 0x00-0x7F）。
具體是：
雖然現(xiàn)代英語使用 128 個字符就足夠了，但表示其他語言就遠(yuǎn)遠(yuǎn)不夠了。因此當(dāng) ASCII 進(jìn)入歐洲后，又被擴(kuò)展為了 EASCII(Extended ASCII)，將 7 bit 擴(kuò)展為 8 bit，并且前 127 個編碼含義和 ASCII 保持一致。
但 256 個字符依舊無法解決眾多使用拉丁字母的語言（主要是歐洲語言）問題。于是又?jǐn)U展出了 15 個 ISO 8859 字符集。
舉幾個字符集作為了解：
前面講到拉丁文所使用是 ASCII 和 EASCII，但在亞洲——主要是中日韓(CJK)——光常用漢字就 6000 多個，而漢字總共有 5、6 萬之多，單靠一個字節(jié)是遠(yuǎn)遠(yuǎn)沒辦法做到的。
因此聰明的中國人（也可能是日本人）就想到使用雙字節(jié)編碼（DBCS） 來表示一個漢字，這樣理論上 2 個字節(jié)可以表達(dá) 65535 個字符（當(dāng)然很理論，實際上要少很多）。
這樣就可以表示大部分常用字符了，接下來就要講到和中文有關(guān)的 GB 系列（如 GB2312、GBK、GB18030）的字符集了。
其實 GB 就是“國標(biāo)”漢語拼音的首字母，而 GBK 就是“國標(biāo)擴(kuò)展”的意思，而 GB18030 是在保留 GBK 編碼*礎(chǔ)上再度擴(kuò)展為可變的 4 字節(jié)編碼空間的編碼規(guī)范。
這里我們著重介紹下 GB2312 的編碼結(jié)構(gòu)。
GB2312 全稱《信息交換用漢字編碼字符集·*本集》，收錄了 6763 個漢字，682 個拉丁、希臘、日文假名等字符。就將其中漢字覆蓋了大陸 99.75% 的使用頻率，足夠大部分的場景使用的。
同時還把 ASCII 中標(biāo)點符號、阿拉伯?dāng)?shù)字、英文字符用雙字節(jié)收錄在內(nèi)，這里為了區(qū)別于 ASCII 中的字符，就將其做成了與漢字等寬的正方型效果（即拉丁字母的兩倍寬），以表示和編碼存儲方式一一對應(yīng)。因為字符編碼和字寬的對應(yīng)關(guān)系，我們這就稱這類字符為「全角」字符，而 ASCII 中的字符則為「半角」字符。（這種叫法源于日本，因為在日本中“角”有“方塊”的意思）
接下來看看如何編碼的。規(guī)范將收錄的漢字分成 94 個區(qū)，每個區(qū)又包含 94 個漢字，用所在的區(qū)位來表示一個字符（這種方法也稱為區(qū)位碼） 。每個字符用 2 個字節(jié)表示，其中第一個字節(jié)稱為「高位字節(jié)」表示分區(qū)號，第二個字節(jié)稱為「低位字節(jié)」表示區(qū)段內(nèi)的碼位。另外實際 GB2312 僅用了 87 個區(qū)，88-94 區(qū)保留待擴(kuò)展。
為了避開 ASCII 中前面的 31 個不可見控制符和空格，在區(qū)位碼*礎(chǔ)上 +32（0x20），這樣獲得的編碼就稱為 ISO-2022 國標(biāo)碼。
但是實際使用時，英文字符和漢字混用的情況很常見，國標(biāo)碼僅避讓開了控制字符，依然和 ASCII 的英文字符有重合，因此決定在國標(biāo)碼的*礎(chǔ)上將單字節(jié)的最高位 bit 存為 1，即在國標(biāo)碼上 +128（0x80），也就是區(qū)位碼上 +160 （0xA0），這樣就完美的避讓開了 ASCII 字符區(qū)間。
這樣種編碼就叫做 EUC-CN 機內(nèi)碼：
EUC-CN 機內(nèi)碼 = 區(qū)位碼 + 160
而目前 GB2312 所采用的就是 EUC 這種主流編碼方式，以便于兼容 ASCII 碼。同時也可以根據(jù)最高位 bit 來判斷是讀取 1 個字符（ASCII）還是 2 個字符來進(jìn)行解析。在 GB2312 內(nèi)，高位字節(jié)范圍 0xA1-0xF7（01-87 區(qū)+160 或 0xA0），低位字節(jié)范圍 0xA1-0xFE（01-94 + 160 或 0xA0）。
以“節(jié)”為例：
但是新的問題來了，GB2312 僅收入了 6763 個常用的漢字，一些在標(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 個。而 GB18030 則更為激進(jìn)，干脆將存儲空間變成可變的 1、2、4 字節(jié)，理論上可以存儲 161 萬個字符，完全涵蓋 Unicode 范圍。同時 GB18030 還收錄了中日韓、繁體字、少數(shù)民族文字等多種語言。
于此同時，海峽對岸的程序員也發(fā)明出了一套自己的繁體中文標(biāo)準(zhǔn)，由于起初項目名稱是「五大中文套裝軟件」，因此稱為 Big5，也叫大五碼。記得當(dāng)年想要玩臺灣“流入”的游戲，MagicWin 這類的轉(zhuǎn)碼軟件是裝機必備。
隨著世界各個地區(qū)編碼方式越來越多，給不同地區(qū)間數(shù)據(jù)傳輸造成非常大的困難，比如一個從中國發(fā)送到日本郵件的，在不知道其編碼的情況下，就會出現(xiàn)亂碼。
因此終于有人開始想用一種更加通用的方案，來涵蓋世界上所有的字符和符號——這就是 Unicode，如其名字本身的含義一樣。
首先 Unicode 也采用了 16 位的編碼空間，即 2 個字節(jié)表示一個字符，用 "U+"接 4 個十六進(jìn)制數(shù)字表示（例如U+4AE0），每個字符分配一個唯一的「碼點」（CodePoint，也稱碼位）。同時又定義了 17 個編組，每組稱為一個「平面」（Plane）。這樣字符范圍從 0x00000 - 0x10FFFF，這樣就可以最多表示 17 * 65536 也就是 100多萬個字符，完全可以存儲全世界所有的語言和符號了。
這其中將常用的字符存放在第一個編組，即 0 號平面（Plane 0），也稱之為「*本多文種平面 」（BMP - Basic Multilingual Plane），其范圍是 0x0000 - 0xFFFF 。而 1-16 號平面被稱為「輔助平面」（Supplementary Planes），用于存儲很少使用的文字或者圖形符號（emoji 表情符號就存于這些平面），其范圍是 0x10000-0x10FFFF。
Unicode 字符表的范圍涵蓋的字符和符號非常廣，不僅收錄了表情符號、麻將、音樂符號等表意符號外，還收錄了一些早已不再使用的文字，比如甲骨文、古埃及的圣書體，甚至收錄了為影視劇而創(chuàng)造的語言——克林貢語。并且還在持續(xù)更新中，截止此文完成，最近的一次更新是在2022年9月。
但是這里有個比較嚴(yán)重的問題：
由于這個問題導(dǎo)致 Unicode 的在初期完全沒法推廣，直到互聯(lián)網(wǎng)的普及，急需一種對 Unicode 字符的編碼方式出現(xiàn)，這就是 ****UTF（Unicode Transformation Format）。在 UTF 中又出現(xiàn)了 UTF-8、UTF-16、UTF-32 這些不同的編碼方式。
首先，人們想到的就是干脆所有字符直接用 4 個字節(jié)存儲，不足 4 位的就補 0 代替。但是這樣簡單粗暴，尤其僅使用英文的數(shù)據(jù)，會造成了空間的極大浪費。
比如拉丁字母 A 的 Unicode 碼點為 U+0065，十六進(jìn)制為 0x41，如果使用 UTF-32 編碼就是 0x00000041。
于是人們又開始設(shè)計一種可以節(jié)省空間的編碼方式——UTF-8。
UTF-8 最大的特點是可變長編碼，它使用 1-4 個字節(jié)表示一個字符。
它的編碼方式如下：
1）由于 Unicode 在 0+0000-0+007F 范圍和 ASCII 完全相同，因此使用單字節(jié)表示（這樣 ASCII 和 UTF-8 的編碼一樣，是完全兼容的）。
2）在大于 0+007F 的字符時，是由 1 個前導(dǎo)字節(jié)（leading bytes）和 n 個（n >=1 ）尾字節(jié)（trailing bytes）的多字節(jié)結(jié)構(gòu)組成。前導(dǎo)字節(jié)從最左側(cè)起用 1來表示這個字符有多少位，直到遇到 0 為止。尾字節(jié)前兩位都是 10，其余的 bit 位就是可用編碼空間。
比如：
這里 x 就表示可用的編碼空間，這也就是 UTF-8 中 8 表示至少 8 位表示一個字符，同時也是以 8 位為一組實現(xiàn)可變字節(jié)的編碼方式。（這里之所以跳過了 10xxxxxx，是因為 10 表示尾字節(jié)）
以下就是完整編碼方式，當(dāng)然 5、6 字節(jié)的編碼方式不會出現(xiàn)，因為已經(jīng)遠(yuǎn)超 Unicode 最大碼點范圍 U+10FFFF 了。
兔：
🐰 的 emoji：
由于 JS 中 encodeURI 是按照 UTF-8 進(jìn)行百分號編碼，因此感興趣的同學(xué)可以進(jìn)行驗證下（代碼如下所示）。
encodeURI('兔');
// %E5%85%94
encodeURI('🐰');
// %F0%9F%90%B0
除了相對于 4 字節(jié)編碼更省空間外，UTF-8 編碼還有以下比較優(yōu)秀的特性。
1）ASCII 是 UTF-8 的一個子集，一個純 ASCII 字符串也是一個合法的 UTF-8 字符串。因此現(xiàn)存的 ASCII 數(shù)據(jù)可以不經(jīng)修改即可使用。
2）單字節(jié)范圍 0x00-0x7F，而多字節(jié)的前導(dǎo)字節(jié)范圍總是在 0xC0-0xFD，尾字節(jié)都在 0x80-0xBF 中，三者完全沒有重疊。通過范圍就可以確定字節(jié)的類型，如果字節(jié)流在傳輸時中斷，不完整的字節(jié)也不會被解碼。這樣數(shù)據(jù)有損壞、丟失，影響的范圍也會很小。試想下，如果有一個按照每 4 個字節(jié)為一組的編碼方法，如果丟失了第一個字節(jié)的數(shù)據(jù)，那么繼續(xù)按照 4 字節(jié)一組的方式讀取數(shù)據(jù)，后面的數(shù)據(jù)都將無法讀取。
3）另外由于前導(dǎo)字節(jié)和尾字節(jié)范圍互不重疊，即便從一個字符的某個中間字節(jié)開始讀取，也不會錯把它和下一個字符拼接錯。這種特性也叫自同步碼。比如，“兔子”的編碼為 E5 85 94 / E5 AD 90，你不會錯把 85 94 E5 或者 AD 90 當(dāng)做一個字符，因為根本不存在這樣規(guī)則的 UTF-8 編碼。
4）僅通過首字節(jié)就能確定整體字節(jié)長度，而無需等待下一個字節(jié)的讀取。
5）理論 6 個字節(jié)可以存放 2^31 個字符，即 21 億個字符！即便是 4 字節(jié)也可以存放 200 多萬個字符。其范圍已超 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)勢，但是也有缺點：
因此：一些程序在內(nèi)部處理字符串時，就使用了另外一種編碼方式 UTF-16，其中 JavaScript、Python 就使用了這種編碼方式來存儲字符串。
UTF-16 也采用了變長的編碼方式。使用 2 個或者 4 個字節(jié)表示一個字符。
其規(guī)則是：
其中 BMP 的字符直接使用 Unicode 碼點對應(yīng)即可，比如“兔”的碼點 U+5154，UTF-16 編碼就是 0x5154。
可是 BMP 外，要如何使用 4 個字節(jié)表示呢？假如我們使用 UTF-32 的方式，直接使用碼點映射會遇到什么問題？
還以“🐰”為例，其碼點是 U+1F430。如果直接映射為 0x0001F430，頭 2 個字節(jié) 0x0001 對應(yīng)的字符在 BMP 中已經(jīng)存在，這樣在讀取數(shù)據(jù)時就無法區(qū)分到底是按照 2 字節(jié)解析，還是按照 4 個字節(jié)解析了。
幸而在 BMP 中，從 U+D800 到 U+DFFF 是一個永遠(yuǎn)保留不做映射的空段，于是 UTF-16 將輔助平面內(nèi)的字符 —— 共需要 20 個 bit 表示（由 0x10FFFF - 0x100000 = 0xFFFFF 計算得來） —— 拆分成 2 段，前 10 個 bit 位映射到 U+D800 - U+DBFF（正好 1024 個），后 10 個 bit 映射到 0xDC00 - 0xDFFF（也正好 1024 個）。這樣剛好就可以在范圍互不重復(fù)的情況下，用 4 個字節(jié)表示一個字符了。
這種用 4 個字節(jié)表示的方式，就被稱作「代理對」（Surrogate Pair），高位的 10 bit 被稱為「前導(dǎo)代理」（lead surrogates），低位 10 bit 被稱為「后尾代理」（trail surrogates）。
其具體的算法如下：
a. 碼位減去 0x10000；
b. 高位的 10 bit 的值加上 0xD800 ，得到前導(dǎo)代理；
c. 低位的 10 bit 的值加上 0xDC00 ，得到后尾代理。
用公式計算如下：
// 高位
H = Math.floor((c-0x10000) / 0x400)+0xD800
// 低位
L = (c - 0x10000) % 0x400 + 0xDC00
我們依舊使用“🐰”來舉例，看下 UTF-16 是如何進(jìn)行編碼的。
🐰：
JS 中 escape 方法（已不推薦，這里僅驗證用）返回的就是 UTF-16 編碼，可以進(jìn)行驗證：
escape('🐰')
// %uD83D%uDC30
同時 ES6 中支持用 Unicode 碼點和 UTF-16 編碼表示一個字符，也可驗證：
'\u{1F430}'== '\uD83D\uDC30'
// true
由于前導(dǎo)代理、后尾代理、BMP 中的有效字符的碼位，三者互不重疊，因此在檢查字符時，可以很容易的確定字符的邊界。這也意味著 UTF-16 也是一種自同步的編碼方式，這點和 UTF-8 是一樣的。
UTF-16 相對于 UTF-8 更容易進(jìn)行隨機訪問和索引，是因為 UTF-16 中每個字符都使用固定的2個或4個字節(jié)表示，因此可以通過簡單的數(shù)學(xué)運算來快速計算出每個字符的位置。而 UTF-8 需要解析整個數(shù)據(jù)流才能確定每個字符的位置，這使得 UTF-8 在進(jìn)行隨機訪問和索引時比 UTF-16 更加復(fù)雜和耗時。
在談及 UTF-16 時，通常會涉及到 UCS-2 的概念，這里著重講下兩者的區(qū)別。
UCS-2 是 Universal Character Set coded in 2 octets 的簡稱，由于 1989 年 UCS 標(biāo)準(zhǔn)發(fā)布時，只有 Unicode *本面字符，因此使用 2 個字節(jié)就可以表示一個字符了。
而 1996 年 UTF-16 發(fā)布時，已經(jīng)擴(kuò)展出了輔助平面，可使用代理對方式表示輔助平面的字符了，因此 UTF-16 已明確表示是 UCS-2 的超集。
所以目前 UCS-2 已經(jīng)是過時的叫法了，UTF-16 已經(jīng)取代了 UCS-2 的概念。
如果某個程序說自己支持 UCS-2 可能就意味著僅支持 BMP 內(nèi)的字符集。
將字符轉(zhuǎn)換為 UTF-16（或 UTF-32） 后，在使用時需要讀取并存儲在內(nèi)存中。以“乙”字為例，轉(zhuǎn)成 UTF-16 后，編碼為 0x4E59，需要用 2 個字節(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
之所以會有這樣不同的存儲方式，是因為有的系統(tǒng)或者處理器，在處理多字節(jié)數(shù)據(jù)時，會從低位內(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 表示小端序。
我們來驗證下，使用 VSCode 安裝 HexEditor 插件，然后新建一個空白文件，輸入“乙”和“🐰”，然后分別使用兩種編序，通過 HexEditor 查看。
UTF-16 BE：
UTF-16 LE：
另外 UTF-8 也存在 BOM 頭，值為 0xEF 0xBB 0xBF。但它只用來標(biāo)識文件的編碼方式，而不用來說明字節(jié)順序。因為 UTF-8 本身有著固定的編碼順序，字節(jié)序?qū)τ?UTF-8 來說毫無意義。
在實際使用中，也應(yīng)該盡量避免帶 BOM 頭的 UTF-8，因為 BOM 頭可能會影響一些程序的解析器（如 Unix下的Shebang）的處理。
另外由于 UTF-8 是一種稀疏的編碼，很大一部分可能的字符組合不會產(chǎn)生有效的 UTF-8 文本，因此許多程序的在解析 UTF-8 文件時，使用啟發(fā)式的分析方法可以很有把握地檢測出文件是否使用 UTF-8，而無需加入 BOM。
PS：關(guān)于大小端字節(jié)序問題，可以詳讀另一篇《史上最通俗大小端字節(jié)序詳解，一文即懂！》。
“錕斤拷”和“燙燙燙”恐怕是程序界中最經(jīng)典的故事（事故）之一了，了解了前面的編碼知識，就會很容易理解它的由來了。
由于 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)時，就會產(chǎn)生連續(xù)的 0xEF 0xBF 0xBD 0xEF 0xBF 0xBD。
如果這些字符又被使用了 GB 編碼的程序中打開，就會按照 GB 雙字節(jié)編碼將其解析。這樣剛好就對應(yīng)了 「0xEFBF 錕」 、「0xBDEF 斤」、「0xBFBD 拷」 這幾個字。
C\C++ 編譯器在 debug 模式下，引入的一種內(nèi)存保護(hù)機制，會給特定的內(nèi)存賦一個特定的初值。其中未被初始化的棧內(nèi)存，會被寫入 0XCC。當(dāng)連續(xù)的 0xCCCC 在 GB 編碼下就是「0xCCCC 燙」了。
當(dāng)然一千人眼中有一千個哈姆雷特，程序員也是如此。比如臺灣是“嚙踝蕭”，而日本是“フフフフフフ”了。
前面我們提到 JavaScript 中 '😁'.length = 2，要說明這個問題之前，先簡單介紹下 JavaScript 與編碼的歷史。
1990 年 UCS-2 編碼發(fā)布，1995 年 JavaScript 誕生，第一個 JS 解釋器被使用，1996 年 UTF-16 發(fā)布。
從時間線上來看 JavaScript 解釋器只能采用了 UCS-2 的編碼方式。而 length 統(tǒng)計的是代碼單元而非真正的字符數(shù)量，因此按照 UCS-2 的編碼方式，每個字符由 2 個字節(jié)構(gòu)成，即兩個 2 字節(jié)組成字符的 length = 1。
而 是輔助平面的字符，其 UTF-16 的編碼為 D8 3D DE 01，因此 JavaScript 會把它當(dāng)做 0xD83D 和 0xDE01 兩個字符。這也就是 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
但在 ES6 中，大大增強了對 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 中只要將碼點放入 {} 中，即可正確表示其含義：
vara = '\u{1F430}';
// 🐰
ES6 新增了幾個專門處理 4 字節(jié)碼點的函數(shù)，如：
ES6 正則提供了 u 修飾符，對正則表達(dá)式添加 4 字節(jié)碼點的支持：
// '\u{1F430}'
/^.$/.test('🐰'); // false
/^.$/u.test('🐰'); // true
vars = '\u0065\u0323\u0301'; // '??'
/^.$/.test(s); // false
/^.$/u.test(s); // false
上面解釋了為什么 length=2，是否意味著 length 非 1 即 2 呢？別急，我們運行下 '👨👩👧👦'.length。
居然 length=11，為什么整整齊齊的一家人要這么長？這到底發(fā)生了什么？
要解釋這個問題，就要講到 Unicode 的合成字符（combining character）。
在一些語言中，會在字符的上面添加一些符號，以表示不同的發(fā)音或表示不同的含義。例如：漢語拼音有 ā 的音標(biāo)、ü 上面的兩點，法語和西班牙語中的 é 表示重音，越南國語字中的 ? 表示一個字母。
而在 Unicode 中有兩種表示方法：
'\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 問題上來，這個 emoji 就使用了合成符號表示（這個表情沒有單獨的碼點），其組合是由 7 個 Unicode 組合而成，分別是 ['👨', '', '👩', '', '👧', '', '👦']， 使用了 U+ 200D 零寬連字符（Zero-Width Joiner，ZWJ）將四個 emoji 鏈接。
這類表情也被稱為 Emoji ZWJ Sequences ：
而 👨 👩 👧 👦 的 length 分別為 2，而零寬連字符的 length 為 1，因此最終 length 就是 24 + 31 = 11。
通過下面的方式也可以驗證其組合：
[...'👨👩👧👦']
// ['👨', '', '👩', '', '👧', '', '👦']
'\u{1F468}\u{200D}\u{1F469}\u200D\u{1F467}\u200D\u{1F466}'
// 👨👩👧👦
當(dāng)然這里想通過 normalize() 判斷是否等價是不行的，首先 👨👩👧👦 沒有獨立的碼點， 其次該方法目前不能識別三個或三個以上字符的合成。
[...'👨👩👧👦'.normalize()];
// ['👨', '', '👩', '', '👧', '', '👦']
// '\u0065\u0323\u0301' => '??'
[...'??'.normalize()]
// ['?', '?']
上面提到關(guān)于 Unicode 的問題不僅限于 JavaScript，在 Python、Java 等語言中也會遇到。通常這類合成符號在實際開發(fā)中會造成很多棘手的問題。
在設(shè)置 input 的 maxLength 屬性時，就會遇到不同瀏覽器的差異。
<input maxlength="10">
Chrome 將 👨👩👧👦 粘貼后，會按照 String.prototype.length 進(jìn)行裁剪，多出的字符會被裁剪掉：
例子在這里：Safari（PC 16.3+Moblie）則會按照實際字符個數(shù)計算：
在華為默認(rèn)的瀏覽器測試，行為和 Chrome 的相同：
該問題在開發(fā)多語言業(yè)務(wù)中，可能會更加明顯（如后臺的字符數(shù)限制、前端展示等）。如果希望正確計算需要使用三方庫，例如：https://github.com/orling/grapheme-splitter （拋磚引玉，未驗證覆蓋情況）。
在一些場景下，會有多個附加音標(biāo)修飾一個字符的情況。例如 '??' 是由字母“e” \u0065、尖音符 “??” ****\u0301 、 下句點 ****“??” \u0323 ****組成。其中后兩個音標(biāo)的順序可互換， 甚至也可以是 '?' + '?' 或者 'é' + '?' 的組合。
'\u0065\u0301\u0323'; // ??
'\u0065\u0323\u0301'; // ??
'\u1eb9\u0301'; // '?' + '?'
'\u00e9\u0323'; // 'é' + '?'
這時要使用正則匹配字符變得異常復(fù)雜。
雖然 Unicode 屬性轉(zhuǎn)義表達(dá)式（Unicode property escapes），但可惜的是ES2018 以前的版本并不支持，因此可以考慮使用 XRegExp 來實現(xiàn)。
// 例子在這里
varreg = XRegExp('\pL\pM*', 'g');
XRegExp.match('??', reg);
// ["??"]
其中 \pL 和 \pM 的含義如下：
雖然在 ES2018 中引入了 Unicode 屬性轉(zhuǎn)義符，但在瀏覽端上依然要考慮使用 XRegExp 來實現(xiàn)，當(dāng)然可以考慮在服務(wù)端處理，因為 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ù)庫存儲時使用了不同的表示方式存儲同一含義的字符，會導(dǎo)致檢索失敗。MySQL 存儲時也要考慮使用 utf8mb4_unicode 編碼格式，才能正確存儲表情符。
最后關(guān)于 Unicode 字符編碼模型，可以概況為四個層級。
1）抽象字符庫（ACR, Abstract Character Repertoire）：即要編碼的字符，比如某些字母表和符號集。這一層級會將語言中的字符進(jìn)行抽象。
2）編碼字符集（CCS, Coded Character Set）：從抽象字符庫到一組非負(fù)整數(shù)（即代碼點）的映射。這一層級可以理解為字符到 Unicode 碼點映射的過程。
3）字符編碼形式（CEF, Character Encoding Form）：從代碼點到特定寬度（比如32-bit整數(shù)）的代碼單元序列的映射。這一層級理解為 UTF-8、UTF-16、UTF-32 的編碼過程。
4）字符編碼方案（CES, Character Encoding Scheme）：從代碼單元序列到字節(jié)序列的映射。這一層級就涉及到了如大端序、小端序的設(shè)計和存取過程。
[1] 新手入門一篇就夠：從零開發(fā)移動端IM》
[2] 零*礎(chǔ)IM開發(fā)入門(一)：什么是IM系統(tǒng)？》
[3] 零*礎(chǔ)IM開發(fā)入門(二)：什么是IM系統(tǒng)的實時性？》
[4] 零*礎(chǔ)IM開發(fā)入門(三)：什么是IM系統(tǒng)的可靠性？》
[5] 零*礎(chǔ)IM開發(fā)入門(四)：什么是IM系統(tǒng)的消息時序一致性？》
[6] 移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡(luò)的“弱”和“慢”》
[7] 移動端IM開發(fā)者必讀(二)：史上最全移動弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》
[8] 從客戶端的角度來談?wù)勔苿佣薎M的消息可靠性和送達(dá)機制》
[9] 現(xiàn)代移動端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請求速度、弱網(wǎng)適應(yīng)、安全保障》
[10] 史上最通俗Netty框架入門長文：*本介紹、環(huán)境搭建、動手實戰(zhàn)
[11] 強列建議將Protobuf作為你的即時通訊應(yīng)用數(shù)據(jù)傳輸格式
[12] IM通訊協(xié)議專題學(xué)習(xí)(一)：Protobuf從入門到精通，一篇就夠！
[13] 微信新一代通信安全解決方案：*于TLS1.3的MMTLS詳解
[14] 探討組合加密算法在IM中的應(yīng)用
[15] 從客戶端的角度來談?wù)勔苿佣薎M的消息可靠性和送達(dá)機制
[16] IM消息送達(dá)保證機制實現(xiàn)(一)：保證在線實時消息的可靠投遞
[17] 理解IM消息“可靠性”和“一致性”問題，以及解決方案探討
[18] 融云技術(shù)分享：全面揭秘億級IM消息的可靠投遞機制
[19] IM群聊消息如此復(fù)雜，如何保證不丟不重？
[20] 零*礎(chǔ)IM開發(fā)入門(四)：什么是IM系統(tǒng)的消息時序一致性？
[21] 一套億級用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性、有序性、弱網(wǎng)優(yōu)化等
[22] 如何保證IM實時消息的“時序性”與“一致性”？
[23] 阿里IM技術(shù)分享(六)：閑魚億級IM消息系統(tǒng)的離線推送到達(dá)率優(yōu)化
[24] 微信的海量IM聊天消息序列號生成實踐（算法原理篇）
[25] 社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實現(xiàn)等
[26] 網(wǎng)易云信技術(shù)分享：IM中的萬人群聊技術(shù)方案實踐總結(jié)
[27] 企業(yè)微信的IM架構(gòu)設(shè)計揭秘：消息模型、萬人群、已讀回執(zhí)、消息撤回等
[28] 融云IM技術(shù)分享：萬人群聊消息投遞方案的思考和實踐
[29] 為何*于TCP協(xié)議的移動端IM仍然需要心跳保活機制？
[30] 一文讀懂即時通訊應(yīng)用中的網(wǎng)絡(luò)心跳包機制：作用、原理、實現(xiàn)思路等
[31] 微信團(tuán)隊原創(chuàng)分享：Android版微信后臺保活實戰(zhàn)分享(網(wǎng)絡(luò)保活篇)
[32] 融云技術(shù)分享：融云安卓端IM產(chǎn)品的網(wǎng)絡(luò)鏈路保活技術(shù)實踐
[33] 阿里IM技術(shù)分享(九)：深度揭密RocketMQ在釘釘IM系統(tǒng)中的應(yīng)用實踐
[34] 徹底搞懂TCP協(xié)議層的KeepAlive保活機制
[35] 深度解密釘釘即時消息服務(wù)DTIM的技術(shù)設(shè)計
[36] *于實踐：一套百萬消息量小規(guī)模IM系統(tǒng)技術(shù)要點總結(jié)
[37] 跟著源碼學(xué)IM(十)：*于Netty，搭建高性能IM集群（含技術(shù)思路+源碼）
[38] 一套十萬級TPS的IM綜合消息系統(tǒng)的架構(gòu)實踐與思考
技術(shù)交流：
- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》
- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）
（本文已同步發(fā)布于：http://www.52im.net/thread-4453-1-1.html）
*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
