编码UTF-8
☯，首先，這并不是圖片，這是一個(gè)unicode字符，Yin Yang，即陰陽符，碼點(diǎn)為U+262F。如果你的瀏覽器無法顯示，可以查看這個(gè)鏈接http://www.fileformat.info/info/unicode/char/262f/index.htm。這與我們要討論的主題有何關(guān)系呢？下面我會(huì)談到。
連續(xù)式表示帶來的分隔難題
計(jì)算機(jī)的底層表示
在計(jì)算機(jī)的最底層，一切都成了0和1，你也許見過一些極客(Geek)穿著印有一串0和1的衣服招搖過市，像是數(shù)字化時(shí)代的某種圖騰。比如，這么一串“0001100101101110001111111000…”，如果它來自某個(gè)文本文件保存后的結(jié)果，我們?nèi)绾螐倪@一串的0和1中從新解碼得到一個(gè)個(gè)的字符呢？顯然你需要把這一串的0和1分成一段一段的0和1，在講述編碼是如何分隔之前，我們先看看自然語言的分隔問題。
自然語言的分隔問題
大家是否意識(shí)到，我們的中文句子里字詞之間也是連續(xù)的呢？英文里說“hello world”，我們說“你好世界”，“我們 不 需要 在 中間 加 空格！”在古代，句與句之間甚至都沒有分開，那時(shí)還沒有標(biāo)點(diǎn)！所以有了所謂的斷句問題。讓我們來看一個(gè)例子：
民可使由之不可使知之 ——出自《論語 第八章 泰伯篇》
這么一串十個(gè)字要如何去分隔并解釋呢？
斷法一：
民可使由之，不可使知之。
解釋：你可以去驅(qū)使你的民眾，但不可讓他們知道為什么（不要去教他們知識(shí)）
評(píng)論：很顯然是站在統(tǒng)治階級(jí)立場的一種愚民論調(diào)。
斷法二：
民可，使由之；不可，使知之。
解釋：民眾可以做的，放手讓他們?nèi)プ觯徊粫?huì)做的，教會(huì)他們?nèi)绾稳プ觯ㄓ只颍翰豢梢匀プ龅模屗麄兠靼诪楹尾豢梢裕?/p>
評(píng)論：這看來是種不錯(cuò)的主張。
顯然，以上的文字是以某種定長或變長的方式組合在一起的，但是關(guān)于它們?nèi)绾畏指舻男畔t被丟棄了，于是在解釋時(shí)就存在產(chǎn)生歧義可能了。
如何快速準(zhǔn)確分詞在中文NLP領(lǐng)域還是蠻有挑戰(zhàn)的一件事，當(dāng)然了，字符集編碼的分隔就簡單多了。
編碼的分隔
自然語言中我們可以使用空格，標(biāo)點(diǎn)來減少歧義的發(fā)生。在計(jì)算機(jī)里，一切都數(shù)字化了，包括所謂的空格，標(biāo)點(diǎn)之類的分隔符。
老子說“道生一，一生二，二生三，三生萬物”，計(jì)算機(jī)則是“二生萬物”，0和1表示了一切。
在空格與標(biāo)點(diǎn)都被數(shù)字化的情況下，我們在這一串01中如何去找出分隔來呢？顯然我們需要外部的約定。
8位（bit）一組的字節(jié)是最基本的一個(gè)約定，也是文件的基本單位，文件就是字節(jié)的序列。字節(jié)顯然就是最基礎(chǔ)的一個(gè)分隔依據(jù)。
定長(Fixed-length)的解決方案
定長僅表明段與段之間長度相同，但沒說明是多長。有了字節(jié)這一基本單位，我們就可以說得更具體，如定長一字節(jié)或者定長二字節(jié)。
ASCII編碼是最早也是最簡單的一種字符編碼方案，使用定長一字節(jié)來表示一個(gè)字符。
下面我們來看一個(gè)具體的編碼示例，為了方便，采用了十進(jìn)制，大家看起來也更直觀，原理與二進(jìn)制是一樣的。
假設(shè)我們現(xiàn)在有個(gè)文件，內(nèi)容是00000001，假如定長2位（這里的位指十進(jìn)制的位）是唯一的編碼方案，用它去解碼，就會(huì)得到“hhhe”（可以對比圖上的編碼，00代表h，所以前6個(gè)0轉(zhuǎn)化成3個(gè)h，后面的01則轉(zhuǎn)化成e）。
但是，如果定長2位不是唯一的編碼方案呢？如上圖中的定長4位方案，如果我們誤用定長4位去解碼，結(jié)果就只能得到“he”（0000轉(zhuǎn)化為h，0001轉(zhuǎn)化為e）！
畢竟，文件的內(nèi)容并沒有暗示它使用了何種編碼！這就好比孔夫子寫下“民可使由之不可使知之”時(shí)并沒有暗示它是5|5分隔（民可使由之|不可使知之）還是2|3|2|3分隔（民可|使由之|不可|使知之）那樣。
如何區(qū)分不同的定長（以及變長）編碼方式？
答案是：你無法區(qū)分！好吧，這么說可能有點(diǎn)武斷，有人可能會(huì)說BOM(Byte Order Mark 字節(jié)順序標(biāo)識(shí))能否算作某種區(qū)分手段呢？但也有很多情況是沒有BOM的。
關(guān)于BOM，可見字符集與編碼（七）——BOM
總之，我想給讀者傳遞的一個(gè)信息就是
文本文件作為一種通用的文件，在存儲(chǔ)時(shí)一般都不會(huì)帶上其所使用編碼的信息。編碼信息與文件內(nèi)容的分離，其實(shí)這正是亂碼的根源。
我們說無法區(qū)分即是基于這一點(diǎn)而言，但另一方面，各種編碼方案所形成的字節(jié)序列也往往帶有某種特征，綜合統(tǒng)計(jì)學(xué)，語言偏好等因素，還是有可能猜測出正確的編碼的，比如很多瀏覽器中都有所謂“編碼自動(dòng)檢測”的功能。
本章主題主講定變長，更多討論可見亂碼探源系列。
定長多字節(jié)方案是如何來的？
顯然，字符集的擴(kuò)充是主要推動(dòng)力。定長一字節(jié)編碼空間撐死了也就28=256。
這點(diǎn)可憐的空間拿到中國來，它能編碼的漢字量也就小學(xué)一年級(jí)的水平。
其實(shí)變長多字節(jié)方案更早出現(xiàn)，比如GB2312，采用變長主要為了兼容一字節(jié)的ASCII，漢字則用兩字節(jié)表示（這也是迫不得已的事，一字節(jié)壓根不夠用）。隨著計(jì)算機(jī)在全世界的推廣，各種編碼方案都出來了，彼此之間的轉(zhuǎn)換也帶來了諸多的問題。采用某種統(tǒng)一的標(biāo)準(zhǔn)就勢在必行了，于是乎天上一聲霹靂，Unicode粉墨登場！
前面已經(jīng)談到，Unicode早期是作為定長二字節(jié)方案出來的。它的理論編碼空間一下達(dá)到了216=65536(即64K，這里1K=1024=210)。
對于只用到ASCII字符的人來說，比如老美，讓他們采用Unicode，多少還是有些怨言的。怎么說呢？比如“he”兩個(gè)字符，用ASCII只需要保存成6865(16進(jìn)制)，現(xiàn)在則成了00680065，前面兩個(gè)毫無作用的0怎么看怎么礙眼，原來假設(shè)是1KB的文本文件現(xiàn)在硬生生就要變成2KB，1GB的則變成2GB！
可是更糟糕的事還在后頭，在老美眼中，16位的空間已經(jīng)算是天量了！要知道一字節(jié)里ASCII也僅僅用了一半，
后面將會(huì)看到，這一特性為各種變長方案能兼容它提供了很大便利！因?yàn)樽罡呶欢际?.
而且這一半里還有不少控制符。可隨著整理工作的深入，人們發(fā)現(xiàn)，16位空間還是不夠！！
說起來我們的中文可是字符集里面的大頭。“茴字有四種寫法”，上大人孔乙己的這句名言想必大家還有點(diǎn)印象。據(jù)說有些新近整理的漢語字典收錄的漢字?jǐn)?shù)量已經(jīng)高達(dá)10萬級(jí)別！我的天！這里很多字怕是孔乙己先生也未必認(rèn)得了！
那現(xiàn)在該咋辦呢？如果還是定長的方案，眼瞅著就要奔著四字節(jié)而去了。
計(jì)算機(jī)界有動(dòng)不動(dòng)就翻倍的優(yōu)良傳統(tǒng)，比如從16位機(jī)一下就到32位，32位一下又到了64位。當(dāng)然了，這里面是有各種權(quán)衡的，包括硬件方面的。
那些看到把6865保存成00680065已經(jīng)很不爽的人，現(xiàn)在你卻對他們說，“嘿，伙計(jì)，可能你需要進(jìn)一步存成0000006800000065…”。容量與效率的矛盾在這時(shí)候開始激化。
容量與效率的矛盾
首先，需要明確一下：
所謂容量，這里指用幾個(gè)字節(jié)表示一個(gè)字符，顯然用的字節(jié)越多，編碼空間越大，能表示更多不同的字符，也即容量越大。
所謂效率，當(dāng)表示一個(gè)字符用的字節(jié)越多，所占用的存儲(chǔ)空間也就越大，換句話說，存儲(chǔ)（乃至檢索）的效率降低了。
如果說效率是陰，那么容量就是陽。（我沒還沒忘記自小學(xué)語文老師就開始教導(dǎo)的，寫作文要遙相呼應(yīng)）
我們說定長不是問題，關(guān)鍵是定幾位。定少了不夠用，定多了太浪費(fèi)。定得恰到好處？可怎樣才算恰好呢？你可能會(huì)說，至少要能容納所有字符吧？但重要的事實(shí)是并非所有的字符所有的人都用得上！哪怕用得上，也可能是偶爾用上，多數(shù)時(shí)候還是用不上！
字符之間并不是平等的。用數(shù)學(xué)的語言來說，每個(gè)字符出現(xiàn)的機(jī)率不是等概率的，但表示它們卻用了同樣長度的字節(jié)。
學(xué)過《數(shù)據(jù)結(jié)構(gòu)與算法》的同學(xué)可能聽過哈夫曼編碼(Huffman Coding)，又稱霍夫曼編碼，就為了解決這樣的問題。
如果你對前一篇所發(fā)的莫爾斯電碼圖還有印象，你就會(huì)發(fā)現(xiàn)，字母e只用了一個(gè)點(diǎn)（dot）來編碼。
其它字母可能覺得不公平，為啥我們就要錄入那么多個(gè)點(diǎn)和劃（dash）才行呢？這里面其實(shí)是有統(tǒng)計(jì)規(guī)律支撐的。e出現(xiàn)的概率是最大的。z你能想到什么？
zoo大概很多人能想到，厲害一點(diǎn)可能還能想到zebra（斑馬），Zuckerberg（扎克伯格），別翻字典！你還能想到更多不？
但含有的e的單詞則多了去了。zebra中不就有個(gè)e嗎，Zuckerberg中還兩個(gè)e呢！
在存儲(chǔ)圖片時(shí)，一個(gè)像素點(diǎn)用幾個(gè)位來表示也是一個(gè)很值得考究的問題。你也許聽過所謂的24位真彩色，這暗示了一個(gè)像素使用了高達(dá)3個(gè)字節(jié)來表示。24位的空間可以表示高達(dá)1600多萬種顏色，但各種顏色的出現(xiàn)概率在均衡度上肯定要好于字符。
回到我們的主題，雖然很多字連我們的孔乙己先生見了都要搖頭，可還是有少部分人會(huì)用到它們，比如一些研究古漢字的學(xué)者。有些人取名還喜歡弄些偏僻字，所以很多人口登記方面的系統(tǒng)也有這個(gè)超大字符集的需求。
好吧，我們不能不顧這些人需求。那么有可能在定長方案的框架下解決這一容量與效率的矛盾嗎？答案是否定的！
矛盾是事物發(fā)展的動(dòng)力，下面我們將看到定長方案的簡單性使它無法緩和容量與效率的沖突，平衡這一對矛盾的努力最終推動(dòng)了編碼方案從定長演變到變長，事情也由此從簡單變得復(fù)雜了。
CAP理論及擴(kuò)展
CAP是什么玩意？
著名的Brewer猜想說：對于現(xiàn)代分布式應(yīng)用系統(tǒng)來說，數(shù)據(jù)一致性(Consistency)、系統(tǒng)可用性(Availability)、服務(wù)規(guī)模可分區(qū)性(Partitioning)三個(gè)目標(biāo)(合稱CAP)不可同時(shí)滿足，最多只能選擇兩個(gè)。
你可能要問，這貌似跟我們要討論的問題風(fēng)牛馬不相及？別著急，我們可以借鑒他的這種思想，擴(kuò)展到我們的問題上來。
兩個(gè)維度
我們所應(yīng)對的問題常常很抽象，有時(shí)借助某些隱喻（metaphor）可以幫助我們來理解。天平就是一個(gè)很好的隱喻。
先看圖中四個(gè)天平。你叫它蹺蹺板我也沒意見，反正我沒打算吃美術(shù)這碗飯！（嗯，也許是少個(gè)了指針的緣故，希望這空指針的天平不要引發(fā)什么異常。）
這幅圖表示的就是定長方案下容量與效率的一種約束關(guān)系。
容量小則效率高
容量大則效率低
容量與效率均不能讓人滿意！
容量與效率均較好，但這是不可能的情形！
讓我們具體解釋一下：
天平的藍(lán)色橫梁一種剛性約束的隱喻。所謂剛性，這里簡單理解成不能變形就是了。
天平的兩端的容量與效率是它的兩個(gè)維度，或者說兩個(gè)自由度。不必去糾結(jié)物理學(xué)上的定義，簡單理解就是它們能自由上下就好了。但我們可以看到，由于受到橫梁的約束，兩個(gè)維度同時(shí)向上是不可能的！它們的相互運(yùn)動(dòng)呈現(xiàn)出彼消此長的關(guān)系。
天平可以隱喻很多，比如安全性與便利性。為什么要我錄入驗(yàn)證碼？為什么支付寶登錄與支付要用不一樣的密碼？為何輸入密碼還不夠，還要什么手機(jī)驗(yàn)證碼？這些都很不方便呀！當(dāng)你覺得只有一個(gè)前門還不夠方便時(shí)你又加開了個(gè)后門，但你是否想過在方便自己的同時(shí)也“方便”了小偷呢？魚和熊掌不可兼得！
三個(gè)維度
好了，現(xiàn)在要再次拓展一個(gè)維度了，以使得它更像CAP理論。
還有一個(gè)維度在哪呢？我們說容量大是好，效率高是好，我們?yōu)楹吻嗖A定長方案呢？因?yàn)槎ㄩL它簡單，簡單當(dāng)然也是好，復(fù)雜就不好了。這就是第三個(gè)維度——簡單性（你也可以叫成復(fù)雜性，意思是一樣的）。
先深呼吸一下，讓我們再看一個(gè)圖：
首先這里多了一個(gè)維度，天平模型不足以表達(dá)了，改用三條互成120度的直線表示這三個(gè)維度。越往里，紅色的字代表是越差的情況；越往外，綠色的字代表是越好的情況。
圖中的約束在哪呢？就在藍(lán)色的三角形上，它有一個(gè)固定的周長，這就代表了它的約束。也許我們把它想像成一條首尾相接的固定長度的鋼絲繩更好，在圖中它只是被拉成了三角形。它可以在三個(gè)維度上運(yùn)動(dòng)，這讓它比天平的橫梁更靈活，但它的長度不能被拉伸，它不是橡皮繩！！
這幅圖能告訴我們什么？
圖1跟圖2，當(dāng)我們維持簡單性不變時(shí)，容量與效率的關(guān)系其實(shí)跟天平模型中是相似的，也是一種彼消此長的關(guān)系。
圖3，讓簡單性下降（換句話說就是變復(fù)雜了），才能為其它兩個(gè)維度騰出“余量”來。即是說你要“犧牲”簡單性來調(diào)和容量與效率的矛盾。
我們能從模型得到什么啟示呢？
一、事物的多個(gè)方面往往是相互制衡的
在前面的圖中，我們用鋼絲繩來形象隱喻這種制衡，深刻理解制衡是各種直覺與預(yù)見性的前提，當(dāng)我們作出決定時(shí)，便能夠預(yù)判出可能的后果。深層次的矛盾暗示了我們有些沖突是不可避免的，同時(shí)為我們找到正確解決問題的路徑指明了方向。
二、制衡的局面暗示了凡事有代價(jià)，站在一個(gè)全局上去考量，我們常常需要在各方面達(dá)成某種平衡與妥協(xié)。
舉個(gè)例子，分層會(huì)對性能有所損害，但不分層又會(huì)帶來緊耦合的問題。很多時(shí)候，架構(gòu)就是關(guān)于平衡的藝術(shù)。如果我們能明白這一點(diǎn)，就不會(huì)為無法找到“完美”方案而苦惱。
三、復(fù)雜性從根本上是由需求所決定的。我們既要求容量大，又要求效率高，這種要求本身就不簡單，因此也無法簡單地解決。
你功能做好了，用戶說性能還不行；你性能達(dá)標(biāo)了，用戶說界面還太丑。。。丫的能不能先把首付款付清了再跟哥提要求？！
為什么談這些理論?
一方面我不想僅僅為談定變長而只談定變長，單純談理論又往往過于抽象。我想說的一點(diǎn)是“我們在編碼上所遇到的困境往往不過是我們在軟件開發(fā)過程中遇到的各種困境的一個(gè)縮影”。
下圖是所謂的芒德布羅集（Mandelbrot set），是分形（Fractal）理論中的一個(gè)重要概念。圖片來自wiki百科。
很多問題需要我們站在更高層面上去觀察與思考時(shí)才能發(fā)現(xiàn)它們的某些相似性或者說共性，這些共性被抽象出來也就形成了我們的理論。
不識(shí)廬山真面目，只緣身在此山中。——蘇軾《題西林壁》
另一方面，因?yàn)檫@種相似性，我們在編碼問題上得到啟示也能夠指導(dǎo)我們?nèi)ソ鉀Q其它領(lǐng)域的問題。我想這就是這些理論的意義所在。
調(diào)和矛盾的努力，兼容考慮與變長方案的引入
通過前面分析，我們知道，定長二字節(jié)方案無法滿足容量增長，轉(zhuǎn)向定長四字節(jié)又會(huì)引發(fā)了效率危機(jī)，最終，Unicode編碼方案演化成了變長的UTF-16編碼方案。那么UTF-8方案又是如何來的呢？為何不能統(tǒng)一成一個(gè)方案呢？搞這么多學(xué)起來真頭痛！
我們前面提到了有一群ASCII死忠對Unicode統(tǒng)一使用二字節(jié)編碼ASCII字符始終是有不滿的，現(xiàn)在眼見簡單的定長方案也不行了，他們中的一些大牛終于忍無可忍。既然決定拋棄定長，他們決定變得更徹底，于是這幫人揭竿而起，搗鼓出了能與ASCII兼容的UTF-8方案。（注：真實(shí)歷史也許并非如此，我不是考據(jù)癖，以上敘述大家悠著看就是了，別太當(dāng)真。）
如今裝個(gè)逼還分高低格，大牛不折騰，誰又知道他們是大牛呢？只是可憐了我們這些碼農(nóng)，你還在苦苦研究sql，忽如一夜春風(fēng)來，Nosql菊花朵朵開。（貌似應(yīng)開在秋冬季？）
UTF-16用所謂的代理對(surrogate pair)來編碼U+FFFF以上的字符。在采用了變長之后，事情變得復(fù)雜了，以后我們還將繼續(xù)探討代理區(qū)，代理對，編碼單元(Code Unit)等一系列由此而來的概念。
這種變化甚至還影響到對字符串長度的定義，比如，在java中，你可能認(rèn)為包含一個(gè)字符的字符串它的長度就是1，但現(xiàn)在，一個(gè)字符它的長度也可能是2！這樣的字符也無法用char來存儲(chǔ)了。
UTF-8因?yàn)槟芗嫒軦SCII而受到廣泛歡迎，但在保存中文方面，要用3個(gè)字節(jié)，有的甚至要4個(gè)字節(jié)，所以在保存中文方面效率并不算太好，與此相對，GB2312，GBK之類用兩字節(jié)保存中文字符效率上會(huì)高，同時(shí)它們也都兼容ASCII，所以在中英混合的情況下還是比UTF-8要好，但在國際化方面及可擴(kuò)展空間上則不如UTF-8了。
其實(shí)GBK之后又還有GB18030標(biāo)準(zhǔn)，采用了1，2，4字節(jié)變長方案，把Unicode字符也收錄了進(jìn)來。GB18030其實(shí)是國家強(qiáng)制性標(biāo)準(zhǔn)，但感覺推廣并不是很給力。
目前，UTF-8方案在越來越多的地方有成為一種默認(rèn)的編碼選擇的趨勢。下面是一張來自wiki百科的圖片，反映了UTF-8在web上的增長。
在軟件開發(fā)的各個(gè)環(huán)節(jié)強(qiáng)制統(tǒng)一采用UTF-8編碼，依舊是避免亂碼問題的最有效措施，沒有之一。技術(shù)人員也許更偏愛技術(shù)問題技術(shù)解決，但不得不承認(rèn)有時(shí)行政手段更加高效！
變長(Variable-length)的編碼方案
好了，現(xiàn)在是時(shí)候談?wù)勛冮L方案的實(shí)現(xiàn)問題了，在這里將通過嘗試自己設(shè)計(jì)來探討這一問題。
變長設(shè)計(jì)的核心問題自然就是如何區(qū)分不同的變長字節(jié)，只有這樣才能在解碼時(shí)不發(fā)生歧義。
利用高位作區(qū)分
還是以前面的例子來看，我們設(shè)計(jì)了幾種變長方案
第一種方案的想法很美好，它試圖跟隨編號(hào)來自然增長，它還是可以編碼的，但在解碼時(shí)則遇到了困難。讓我們來看看。
可見，由于低位的碼位被“榨干”了，導(dǎo)致單個(gè)位與多位間無法區(qū)分，所以這種方案是行不通的。
第二種方案，低位空間有所保留，5及以上的就不使用了。然后我們通過引入一條變長解碼規(guī)則：
從左向右掃描，讀到5以下數(shù)字按單個(gè)位解碼；讀到5或以上數(shù)字時(shí)，把當(dāng)前數(shù)字及下一個(gè)數(shù)字兩位一起讀上來解碼。
讓我們來看個(gè)實(shí)例
這種方案避免了歧義，因此是可行的方案，但這還是非常粗糙的設(shè)計(jì)，如果我們想在這串字符中搜索“o”這個(gè)字符，它的編碼是3，這樣在匹配時(shí)也會(huì)匹配上53中的3，這種設(shè)計(jì)會(huì)讓我們在實(shí)現(xiàn)匹配算法時(shí)困難重重。我們可以在跟隨位上也完全舍棄低位的編碼，比如以55，56，57，58，59，65，66…這樣的形式，但這樣也會(huì)損失更多的有效編碼位。
GB2312，GBK，UTF-8的基本思想也是如此。下面也簡單示例一下（0，1代表固定值；黑色的X代表可以為0或1，為有效編碼位）：
注：GBK第二字節(jié)最高位也可能為0.
其實(shí)關(guān)鍵就在于用高位保留位來做區(qū)分，缺點(diǎn)就是有效編碼空間少了，可以看到三字節(jié)的UTF-8方式中實(shí)際有效的編碼空間只剩兩字節(jié)。但這是變長方案無法避免的。
我們還可以看到，由于最高位不同，多字節(jié)中不會(huì)包含一字節(jié)的模式。對于UTF-8而言，二字節(jié)的模式也不會(huì)包含在三字節(jié)模式中，也不會(huì)在四字節(jié)中；三字節(jié)模式也不會(huì)在四字節(jié)模式中，這樣就解決上面所說的搜索匹配難題。你可以先想想看為什么，下面的圖以二，三字節(jié)為例說明了為什么。
可以看到，由于固定位上的0和1的差別，使得二字節(jié)既不會(huì)與三字節(jié)的前兩字節(jié)相同，也不會(huì)它的后兩字節(jié)相同。其它幾種情況原理也是如此。
利用代理區(qū)作區(qū)分
讓我們再來看另一種變長方案。用所謂代理區(qū)來實(shí)現(xiàn)。
這里挖出70-89間的碼位，形成橫豎10*10的編碼空間，使得能再擴(kuò)展100個(gè)編碼空間。原來2位100個(gè)空間損失了20還剩80，再加上因此而增加的100個(gè)空間，總共是180個(gè)空間。這樣一種變長方式也就是UTF-16所采用的，具體的實(shí)現(xiàn)我們留待后面再詳述。
好了，關(guān)于定變長的問題，就講到這里，下一篇將繼續(xù)探討前面提及但還未深入分析的一些問題。
總結(jié)
- 上一篇： C#语法糖之第三篇: 匿名类 &
- 下一篇： web前端打包工具有哪些