Unicode中文“藝”字： 827A

二進(jìn)制的“藝”字編碼：1000 0010 0111 1010

UTF-8的中文編碼規(guī)則： 1110xxxx 10xxxxxx 10xxxxxx

UTF-8的“藝”字編碼： 1110【1000】 10【0010】【01】 10【11】【1010】

UTF-8的轉(zhuǎn)碼過程解析： 8對(duì)應(yīng)的1000被填入第一字節(jié)剩余的4位。2對(duì)應(yīng)的0010被填入第2字節(jié)剩余的前4位。7對(duì)應(yīng)的0111被拆開，前2位01被填入第2字節(jié)的后兩位，后2位1被填入第3字節(jié)的前2位。A對(duì)應(yīng)的1010被填入第3字節(jié)的后4位。

UTF-8的最終編碼結(jié)果：11101000---對(duì)應(yīng)E8；10001001---對(duì)應(yīng)89；10111010---對(duì)應(yīng)BA。所以最終的UTF-8編碼就是%E8%89%BA

Unicode到UTF-8的轉(zhuǎn)換：Unicode的16進(jìn)制編碼<-->對(duì)應(yīng)的2進(jìn)制編碼<-->UTF-8規(guī)范的2進(jìn)制編碼<-->UTF-8規(guī)范的16進(jìn)制編碼

也就是說假如在Java的底層JVM，由于采用的是Unicode編碼字符集，對(duì)“藝”字的編碼是827A。那么在網(wǎng)絡(luò)傳輸?shù)倪^程中，我們當(dāng)然不能直接傳輸827A這個(gè)字符過去代表藝”這個(gè)漢字，而必須要轉(zhuǎn)換成0，1這樣的字節(jié)流，才能在網(wǎng)絡(luò)中傳輸。

所以說UTF-8是一種為了方便網(wǎng)路傳輸，節(jié)省傳輸數(shù)量，而對(duì)Unicode的字符集的字符編號(hào)進(jìn)行轉(zhuǎn)換，從定長的2個(gè)字節(jié)(16進(jìn)制)轉(zhuǎn)換成1~3個(gè)的變長字節(jié)(2進(jìn)制)表示的轉(zhuǎn)換格式。

由于Unicode采用的是2個(gè)字節(jié)的編碼方式，而UTF-8轉(zhuǎn)換后可能是1~3個(gè)字節(jié)，所以同一個(gè)漢字，在Unicode中的編碼和經(jīng)UTF-8轉(zhuǎn)換后的編碼值肯定是不同的。就好像藝字的Unicode編碼是827A，經(jīng)轉(zhuǎn)換后的3個(gè)字節(jié)是E889BA。

所以說對(duì)于英文字符來說，采用UTF-8對(duì)Unicode編碼轉(zhuǎn)換后節(jié)省了一倍的傳輸成本(由定長的2個(gè)字節(jié)變長1個(gè)字節(jié))，但對(duì)于原本雙字節(jié)的東亞字符來說，反而增加了成本，是原來的1.5倍。

小結(jié)：

①ASCII、GB2312、GBK、GB18030、Big5、Unicode都是字符集的名稱。它們定義了采用1~2個(gè)字節(jié)的編碼規(guī)范，為每個(gè)字符賦予了一個(gè)獨(dú)一無二的編號(hào)。這個(gè)編號(hào)就是我們所說的“字符編碼”。

②Unicode字符集定義的字符編碼并不適合直接通過網(wǎng)絡(luò)傳輸表達(dá)，因?yàn)樗鼈儽仨氜D(zhuǎn)換成像0101這樣的二進(jìn)制字節(jié)流傳輸。所以就出現(xiàn)了不同的轉(zhuǎn)換規(guī)范實(shí)現(xiàn)方式：UTF-8，TF-16等。這些不同的轉(zhuǎn)換規(guī)范轉(zhuǎn)換后的編碼值和Unicode是不同的。

對(duì)于UTF-8來說，它采用變長字節(jié)表示所有Unicode字符，對(duì)于英文來說和ASCII兼容，對(duì)于東亞字符來說，是原來傳輸成本的1.5倍。所以采用UTF-8編碼轉(zhuǎn)換方式雖然有利于統(tǒng)一，但增加了中文等雙字節(jié)字符的傳輸成本。

UTF-8采用首字節(jié)的高位"1"的個(gè)數(shù)表示字符的編碼長度。例如在Unicode的編碼規(guī)范中：漢字的表示區(qū)間為U-00000800至U-0000FFFF對(duì)應(yīng)的UTF-8的轉(zhuǎn)換規(guī)則為：1110xxxx 10xxxxxx 10xxxxxx 首字節(jié)3個(gè)1代表這個(gè)字符的編碼長度為3個(gè)字節(jié)。如果是2個(gè)1則表示2個(gè)字節(jié)

③在底層的平臺(tái)中如JVM，采用的是Unicode字符集，當(dāng)要把這些字符通過網(wǎng)絡(luò)傳輸時(shí)，可以選擇通過UTF-8或其他(例如GB2312)編碼轉(zhuǎn)換方式對(duì)要傳輸?shù)淖址幋a進(jìn)行轉(zhuǎn)換。如果目的端也是采用Unicode字符集，那么UTF-8轉(zhuǎn)換后的編碼可以被正常識(shí)別并解碼成最終對(duì)應(yīng)的Unicode字符集編號(hào)。如果是非Unicode字符集平臺(tái)則可能出現(xiàn)亂碼(UTF-8中漢字的3個(gè)連續(xù)字節(jié)被解析成GB2312的2個(gè)連續(xù)字節(jié)，出現(xiàn)丟失)。所以推薦在傳輸?shù)膬啥瞬捎肬nicode字符集編碼，在傳輸方式上采用UTF-8轉(zhuǎn)換方式。

javac命令是以系統(tǒng)默認(rèn)編碼讀入源文件，然后按Unicode進(jìn)行編碼的。(備注：每個(gè)文件都有自己的編碼，javac命令按照默認(rèn)的文件編碼讀入，但是在將.java文件轉(zhuǎn)換成.class的過程中，javac會(huì)將所有的字符轉(zhuǎn)化成unicode的格式保存。)

在運(yùn)行時(shí)JVM也是采用unicode編碼的，并且默認(rèn)輸入和輸出使用的都是操作系統(tǒng)的默認(rèn)編碼。也就是說在new String(bytes[,encode])中，系統(tǒng)認(rèn)為輸入的bytes是編碼為encode的字節(jié)流(如果不指定encode，那么就是默認(rèn)使用系統(tǒng)的編碼方式)，換句話說，如果按encode來翻譯bytes才能得到正確的原始字符，這個(gè)字符最后要在java中保存，它還是要從這個(gè)encode轉(zhuǎn)換成Unicode的。

也就是說，假如我們需要從磁盤文件、數(shù)據(jù)庫記錄、網(wǎng)絡(luò)傳輸一些字符，保存到Java的變量中，要經(jīng)歷由bytes-->encode字符-->Unicode字符的轉(zhuǎn)換(例如new String(bytes, encode))；而要把Java變量保存到文件、數(shù)據(jù)庫或者通過網(wǎng)絡(luò)傳輸，系統(tǒng)要做一個(gè)Unicode字符-->encode字符-->bytes的轉(zhuǎn)換(例如String.getBytes([encode]))