細(xì)說(shuō)Java基本數(shù)據(jù)類型之一的char類型與編碼關(guān)系

一、開(kāi)頭

Java是一種強(qiáng)類型的語(yǔ)言，這意味著必須為每一個(gè)變量聲明一種類型

Java中一共有8種基本數(shù)據(jù)類型（整形有4種，浮點(diǎn)型有2種，字符型1種，還有一種布爾類型）

由于Java程序必須保證在所有機(jī)器上都能得到相同的運(yùn)行結(jié)果，所以各種數(shù)據(jù)類型的取值范圍必須是固定的

二、整形

整形共有4種

• byte：一個(gè)字節(jié)
• short：2個(gè)字節(jié)
• int：4個(gè)字節(jié)（剛好超過(guò)二十億）
• long int：8個(gè)字節(jié)

這里要注意的一些地方是

• 長(zhǎng)整形數(shù)值有一個(gè)后綴L或者l
• 十六進(jìn)制數(shù)值有一個(gè)前綴0x或者0X
• 八進(jìn)制有一個(gè)前綴0（容易混淆，不推薦使用）
• 從Java7（JDK1.7）開(kāi)始可以使用0b或者0B寫二進(jìn)制
• 從JAVA7開(kāi)始，還可以為數(shù)字字面量加下劃線，如使用1_000_000表示100W（Java編譯器會(huì)去除這些下劃線）

開(kāi)頭已經(jīng)說(shuō)了，各種數(shù)據(jù)類型的取值范圍必須是固定的，所以4種整形的范圍都為有符號(hào)位的范圍，Java也因此沒(méi)有Unsigned符號(hào)。

所以針對(duì)Unsigned的整形，基本數(shù)據(jù)類型的包裝類有對(duì)應(yīng)的API的

這里首先要認(rèn)識(shí)的一點(diǎn)是，只要不溢出，加法、減法和乘法都能正常計(jì)算，但除法是會(huì)出問(wèn)題的

三、Byte.toUnsignedInt

這個(gè)API的功能是針對(duì)Unsigned的Byte的轉(zhuǎn)化成Unsigned

從源碼上看，其實(shí)就是將其強(qiáng)制轉(zhuǎn)換成int，相當(dāng)于擴(kuò)大了位數(shù)，然后通過(guò)與上0xff，0xff是十六進(jìn)制，轉(zhuǎn)化成二進(jìn)制就是11111111，這個(gè)與運(yùn)算的作用其實(shí)為了限制位數(shù)，因?yàn)閎yte是1個(gè)字節(jié)，頂多只有8位，超過(guò)8位的那些都不要，對(duì)于Unsigned來(lái)說(shuō)，應(yīng)該都為0.

四、Integer.divideUnsigned

這個(gè)API的功能是針對(duì)Unsigned的int類型除法的

可以看到，他的處理與Byte一樣，都是轉(zhuǎn)化成更高位的類型，這里轉(zhuǎn)化成long，然后通過(guò)與運(yùn)算舍棄后面多出來(lái)的位數(shù)（其實(shí)是改為0）

五、Integer.remainderUnsigned

這個(gè)是用來(lái)求余數(shù)的

可以看到同樣也是轉(zhuǎn)化成更高位去處理

六、Long.divideUnsigned

現(xiàn)在Long沒(méi)有更高位了怎么辦呢？

下面是源碼

 public static long divideUnsigned(long dividend, long divisor) {
        //divisor是除數(shù)
        //而divident是被除數(shù)
        
        //首先判斷除數(shù)是否為Unsigned（<0就代表為unsigned，只不過(guò)將符號(hào)位看成1，變?yōu)樨?fù)數(shù)）
        if (divisor < 0L) { // signed comparison
            // Answer must be 0 or 1 depending on relative magnitude
            // of dividend and divisor.
            
            //可以看到這里的返回值只有0和1
            //這是因?yàn)槌龜?shù)為unsigned，根據(jù)整形的向下取整規(guī)則
            //得到的結(jié)果只能為1和0（dividend大于divisor就為1，小于就為0）
            //dividend不可能為divisor的兩倍（因?yàn)槲粩?shù)不過(guò)）
            return (compareUnsigned(dividend, divisor)) < 0 ? 0L :1L;
        }

        //如果除數(shù)不是Unsigned，那么就判斷被除數(shù)
        
        if (dividend > 0) //  Both inputs non-negative
            //如果被除數(shù)不是Unsigned，就直接除就好
            return dividend/divisor;
        else {
            /*
             * For simple code, leveraging BigInteger.  Longer and faster
             * code written directly in terms of operations on longs is
             * possible; see "Hacker's Delight" for divide and remainder
             * algorithms.
             */
             //如果是，那么就將除數(shù)和被除數(shù)換成更高位的BigInt型，去進(jìn)行
           
            return toUnsignedBigInteger(dividend).
                divide(toUnsignedBigInteger(divisor)).longValue();
        }
    }

下面我們就來(lái)看看compareUnsigned方法

MIN_VALUE是代表長(zhǎng)整形可以取的最小值，也就是 ? 2 63 -2^{63} ?263

可以看到，具體的過(guò)程就是讓兩個(gè)數(shù)減去最小值，然后進(jìn)行比較

原理是，即使是Unsigned，只要減去了最小值，就不會(huì)超過(guò)有符號(hào)位的范圍，然后通過(guò)比較減去后的大小，就可以判斷除數(shù)和被除數(shù)誰(shuí)大誰(shuí)小，然后就返回0和1。

七、浮點(diǎn)型

浮點(diǎn)型有兩種類型，一種為float，一種為double。

這里，我們認(rèn)識(shí)一下精度損失

在兩種浮點(diǎn)型，小數(shù)都是使用二進(jìn)制表示的，比如 2 ? 1 或 者 2 ? 2 2^{-1}或者2^{-2} 2?1或者2?2，也就是0.5，0.125這些，也就是說(shuō)，有一些小數(shù)是無(wú)法使用二進(jìn)制表示的，只能通過(guò)后面的位數(shù)進(jìn)行無(wú)限逼近，所以就會(huì)產(chǎn)生精度損失。

那什么是雙精度和單精度呢？

這是根據(jù)double和float的位數(shù)來(lái)區(qū)分的，double為8字節(jié)，而float為4字節(jié)，所以double可以使用更多位數(shù)進(jìn)行逼近，所以double會(huì)更加精確。

這里要注意的是，所有的浮點(diǎn)數(shù)計(jì)算都遵循IEEE754規(guī)范

對(duì)于表示溢出和出錯(cuò)情況，使用了三個(gè)特殊的浮點(diǎn)數(shù)值去表示

• 正無(wú)窮大
• 負(fù)無(wú)窮大
• NaN（不是一個(gè)數(shù)字）

八、字符型

char類型本來(lái)用來(lái)表示單個(gè)字符，但如今有些Unicode字符可以用一個(gè)char表示，也就是兩個(gè)字節(jié)，但有時(shí)一些Unicode字符需要用多個(gè)字節(jié)表示，也就是使用多個(gè)char表示

char類型的值可以表示為十六進(jìn)制值，從u0000～uffff。這里是u充當(dāng)了一個(gè)轉(zhuǎn)義序列的功能，同時(shí)u轉(zhuǎn)義序列是可以出現(xiàn)在字符常量或字符串，所以使用注釋和參數(shù)的時(shí)候，要注意一下

在Java中，char類型描述了UTF-16編碼中的一個(gè)代碼單元

九、Unicode

在認(rèn)識(shí)UTF-16前，我們需要認(rèn)識(shí)Unicode

Unicode其實(shí)相當(dāng)于一本很厚的字典，里面儲(chǔ)存了世界上所有語(yǔ)言的字符，使用Unicode碼點(diǎn)唯一地對(duì)應(yīng)一個(gè)字符。

Unicode是沒(méi)有規(guī)定字符對(duì)應(yīng)的二進(jìn)制碼占用的空間是多少，那么問(wèn)題來(lái)了，以“漢”字為例，它的Unicode碼點(diǎn)為0x6c49，對(duì)應(yīng)的二進(jìn)制為110110001001001，也就是15位二進(jìn)制，也就說(shuō)明了，這個(gè)字需要用2個(gè)字節(jié)去存儲(chǔ)這個(gè)字，那么，對(duì)于其他字體，很有可能出現(xiàn)3個(gè)字節(jié)，或者更多的字節(jié)去存儲(chǔ)，對(duì)于計(jì)算機(jī)來(lái)說(shuō)，計(jì)算機(jī)怎么知道這兩個(gè)字節(jié)表示的是一個(gè)字符，而不是與后面的字節(jié)形成一個(gè)字符?

所以，為了解決Unicode的這個(gè)問(wèn)題，新的編碼方式UTF-8、UTF-16和UTF-32就出現(xiàn)了

十、UTF-8

UTF其實(shí)是Unicode Transformation Format的縮寫，即統(tǒng)一Unicode編碼轉(zhuǎn)換格式

UTF-8的特點(diǎn)就是可變長(zhǎng)，即對(duì)于不同長(zhǎng)度字節(jié)的字符有很好的兼容性

編碼規(guī)則如下

對(duì)于單個(gè)字節(jié)的字符（也就是基本字符），也就是8位，會(huì)將第一位設(shè)為0，后面的七位會(huì)對(duì)應(yīng)這個(gè)字符的Unicode碼點(diǎn)，因此對(duì)于0～ 2 7 2^7 27號(hào)字符是完全可以的，甚至與ASCII（另一種編碼方式，只不過(guò)不支持中文只有英文和符號(hào)）完全相同（這時(shí)候可能會(huì)有人說(shuō)那么對(duì)于 2 8 至 2 7 2^8至2^7 28至27里面的字符呢？其實(shí)這一段被分在了使用2個(gè)字節(jié)表示）

對(duì)于需要使用N個(gè)字節(jié)來(lái)表示的字符(N>1)，第一個(gè)字節(jié)的前N位都設(shè)為1，第N+1位設(shè)為0（用來(lái)記錄這個(gè)字符是用多少個(gè)字節(jié)來(lái)存儲(chǔ)的，讓計(jì)算機(jī)可以識(shí)別出），剩余后面的N-1個(gè)字節(jié)的前兩位都要設(shè)置為10，剩下的二進(jìn)制位則使用這個(gè)字符的Unicode碼點(diǎn)來(lái)進(jìn)行補(bǔ)充

0000 0800 ~ 0000 FFFF(注意這里位16位)1110xxxx 10xxxxxx 10xxxxxx(對(duì)應(yīng)碼點(diǎn)16位)0001 0000 ~ 0010 FFFF(這里為18位)11110xxx 10xxxxxx 10xxxxxx 10xxxxxx（雖然超過(guò)碼點(diǎn)位數(shù)，但不影響表示）

通過(guò)表格，可以看到UTF-8d的編碼其實(shí)很簡(jiǎn)單，下面還是以"漢"為例，具體說(shuō)一下如何進(jìn)行UTF-8的編碼和解碼的

漢的編碼為0x00006c49，對(duì)應(yīng)在Unicode十六進(jìn)制碼點(diǎn)范圍的第三行，所以對(duì)應(yīng)的UTF-8二進(jìn)制為 1110 x x x x 10 x x x x x x 10 x x x x x x 1110xxxx 10xxxxxx 10xxxxxx 1110xxxx10xxxxxx10xxxxxx，然后將0x0006c49變?yōu)槎M(jìn)制為0x0110110001001001，然后填入到x里面即可（從第最后一位開(kāi)始），結(jié)果為111001101011000110001001，然后再轉(zhuǎn)換成十六進(jìn)制為：0xE6 0xB7 0x89

解碼的過(guò)程也十分簡(jiǎn)單：專為二進(jìn)制之后，先判斷多少個(gè)字節(jié)，如果第一個(gè)字節(jié)的第一位是0，則代表是只有1和字節(jié)，如果不是，就判斷前面總共有多少個(gè)1就碰到0，多少個(gè)1就是多少個(gè)字節(jié)，通過(guò)知道多少個(gè)字節(jié)，就可以知道后面要讀多少個(gè)字節(jié)來(lái)對(duì)應(yīng)這個(gè)字符，只要去掉開(kāi)頭的10就行

十一、UTF-16

在認(rèn)識(shí)UTF-16之前，先認(rèn)識(shí)平面這個(gè)東西

前面提到過(guò)Unicode編碼是一本很厚的字典，將全世界的字符都定義在這個(gè)集合里面，但這本字典不是一次性完成的，而是經(jīng)過(guò)持續(xù)地收集才完成的，所以也就產(chǎn)生了分區(qū)，進(jìn)行分區(qū)定義。每個(gè)區(qū)可以存放65536，也就是2^16字符，一個(gè)區(qū)就稱為一個(gè)平面。目前Unicode一共有17（2 ^ 4+1）個(gè)平面（剩余16個(gè)為輔助平面），所以整個(gè)Unicodez字符集大小為 2 21 2^{21} 221

第一個(gè)平面，也就是第一個(gè)區(qū)，被稱為基本平面，前 2 16 2^{16} 216個(gè)字符也就被成為基本字符，碼點(diǎn)范圍也就是從0~ 2 16 ? 1 2^{16}-1 216?1，寫成十六進(jìn)制就是從U+0000到U+FFFF，最常見(jiàn)的字符大多都在這個(gè)區(qū)了。那么剩余的17個(gè)區(qū)，對(duì)應(yīng)的碼點(diǎn)就是從U+10000到U+10FFFF（剛好16倍），那么要如何解決確定字符與字節(jié)對(duì)應(yīng)的問(wèn)題呢？

基本平面有一個(gè)很巧妙的地方，在基本平面內(nèi)，從U+D800到U+DFFF是一個(gè)空段，也就是再這個(gè)區(qū)間內(nèi)的碼點(diǎn)是沒(méi)有對(duì)應(yīng)任何字符的，因此UTF-16就利用了這個(gè)空段來(lái)做了一個(gè)映射輔助平面的碼點(diǎn)（利用基本平面來(lái)儲(chǔ)存輔助平面）

在輔助平面碼點(diǎn)對(duì)應(yīng)的字符總共有 2 20 2^{20} 220個(gè)，所以至少需要20個(gè)二進(jìn)制位才可以完全對(duì)應(yīng)輔助平面碼點(diǎn)的字符。

UTF-16將這20個(gè)二進(jìn)制位分成一半，前十位映射在U+D800到U+DBFF之間（稱為高位），后10位映射在U+DC00到U+DFFF之間（成為低位），所以當(dāng)遇到多個(gè)字節(jié)時(shí)，如果發(fā)現(xiàn)有碼點(diǎn)位于這兩個(gè)段區(qū)間，這就意味著這是輔助平面碼點(diǎn)的映射，輔助平面字符被拆分成多個(gè)基本平面的碼點(diǎn)表示。

據(jù)個(gè)栗子

漢字"?“的 Unicode 碼點(diǎn)為 0x20BB7，該碼點(diǎn)顯然超出了基本平面的范圍（0x0000 - 0xFFFF），因此需要使用四個(gè)字節(jié)表示。首先用 0x20BB7 - 0x10000 計(jì)算出超出的部分，然后將其用 20 個(gè)二進(jìn)制位表示（不足前面補(bǔ) 0 ），結(jié)果為0001000010 1110110111。接著，將前 10 位映射到 U+D800 到 U+DBFF 之間，后 10 位映射到 U+DC00 到 U+DFFF 即可。U+D800 對(duì)應(yīng)的二進(jìn)制數(shù)為 1101100000000000，直接填充后面的 10 個(gè)二進(jìn)制位即可，得到 1101100001000010，轉(zhuǎn)成 16 進(jìn)制數(shù)則為 0xD842。同理可得，低位為 0xDFB7。因此得出漢字”?"的 UTF-16 編碼為 0xD842 0xDFB7

現(xiàn)在我們回到字符型里面的重點(diǎn)在Java中，char類型描述了UTF-16編碼中的一個(gè)代碼單元，可以知道char類型采用的是utf-16編碼方式，代碼單元其實(shí)指的就是U+D800～U+DBFF和U+DC00～U+DFFF這兩個(gè)映射區(qū)（這里是兩個(gè)個(gè)代碼單元，一個(gè)char只能使用一個(gè)代碼單元，不過(guò)通常一個(gè)代碼單元能表示絕大多數(shù)的字符了，但也是因?yàn)檫@個(gè)原因，有些字符char不可以完整表示），通過(guò)這個(gè)代碼單元，就可以進(jìn)行解碼獲取Unicode編碼了

十二、布爾類型

boolean類型有兩個(gè)值，false和true，用來(lái)判斷邏輯條件，整形值和布爾值之間是不能互換的。

到此這篇關(guān)于Java數(shù)據(jù)類型之細(xì)講char類型與編碼關(guān)系的文章就介紹到這了，更多相關(guān)Java基本數(shù)據(jù)類型的內(nèi)容，請(qǐng)搜索W3Cschool以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持！