一道經(jīng)典問題

Java里的char類型能不能存儲一個中文字符？

對于這道題，絕大多數(shù)的答案都是“可以存儲”。給出的原因包括：
1. java中的char是unicode存儲，unicode編碼字符集中包含了漢字，所以可以存儲中文；
2. java內(nèi)部其實是使用的UTF-16的編碼，所以是支持大部分非生僻漢字的；
3. 采用Unicode編碼集，一個char占用兩個字節(jié)，而一個中文字符也是兩個字節(jié)，因此Java中的char是可以表示一個中文字符的；
4. Java的char只能表示utf-16中的BMP部分中文字符，不能表示擴展字符集里的中文字符；

那么，這個問題的終極答案到底是什么？

Java API中關(guān)于char的說明

原文地址:https://docs.oracle.com/javase/7/docs/api/java/lang/Character.html

char類型是按照Unicode規(guī)范實現(xiàn)的一種數(shù)據(jù)類型，固定16bit大小。現(xiàn)如今，
Unicode字符集已經(jīng)進行了擴展，表示的范圍已經(jīng)超過了16bit。Unicode字符集的
數(shù)值范圍擴大到了[U+0000,U+10FFFF]。

也就是說一個char能夠存儲16bit大小的數(shù)值，即2個字節(jié)。但是，就常用的UTF-8編碼來說，我們都聽說過他是用3或者4個字節(jié)來表示一個漢字的。就拿3個字節(jié)來算的話，一個char也存不下是不是？

我們繼續(xù)看api文檔的其他段落：

一個char值可以表示BMP范圍內(nèi)的Unicode字符。BMP表示[U+0000, U+FFFF]之間的Unicode字符。

而且，絕大部分的中文字符的Unicode范圍是[0x4E00, 0x9FBB],恰好是在BMP范圍內(nèi)。

是不是說這里出現(xiàn)了破解不了的矛盾呢？UTF-8占用3到4個字節(jié)，char只能存2個字節(jié)（16bit），然而UTF-8中的幾乎所有漢字都是在BMP范圍內(nèi)，也就是在char可存儲的范圍內(nèi)，是不是矛盾了？

答案是不矛盾！關(guān)鍵點就在于接下來給出總結(jié)的第一條！

這里先給出總結(jié)，后續(xù)再給出解釋：
1.char字符存儲的是Unicode編碼的代碼點，也就是存儲的是U+FF00這樣的數(shù)值，然而我們在調(diào)試或者輸出到輸出流的時候，是JVM或者開發(fā)工具按照代碼點對應(yīng)的編碼字符輸出的。
2. 所以雖然UTF-8編碼的中文字符是占用3個或者4個字節(jié)，但是對應(yīng)的代碼點仍然集中在[0x4E00, 0x9FBB]，所以char是能夠存下在這個范圍內(nèi)的中文字符的。
3. 但是對于超過16bit的Unicode字符集，也就是Unicode的擴展字符集，一個char是放不下的，需要兩個char才能放下。

Unicode編碼

Unicode的出現(xiàn)是對混亂的ANSI編碼世界的一個大一統(tǒng)，因而也叫做統(tǒng)一碼、萬國碼、單一碼。Unicode編碼把世界上常用的語言字符都進行了統(tǒng)一的編碼，一個數(shù)值就代表一個字符，而且世界范圍內(nèi)公認。

ANSI的編碼世界里，各中語言有自己的編碼規(guī)范，同一個數(shù)值在不同的國家代表不同的字符。所以當文字在不同國家傳遞的時候（比如發(fā)郵件，看國外網(wǎng)頁），問題就很大了，我明明寫的是“愛我中華”，美國朋友看到的確實”°??ò?D?a”，一定是一臉問號！

        //=====模擬文字在不同編碼語言間傳遞的過程=====
        //發(fā)帖子
        String s = "愛我中華";
        //編碼成字節(jié)流，通過網(wǎng)絡(luò)傳入，或者存儲到文件
        byte[] bytes = s.getBytes("GB2312");
        System.out.println(s);
        //國外朋友用自己電腦的編碼方式解析字節(jié)流
        String s2 = new String(bytes, "ISO-8859-1");
        //oh！ shit, wtf!        
        System.out.println(s2);

有了Unicode這個統(tǒng)一編碼之后，全世界的計算機都能正確的解析到原始的字符，對于國內(nèi)的文字信息，國外的朋友唯一要做的就是懂中文！

UTF-8只是Unicode編碼的一種編碼轉(zhuǎn)換規(guī)范，也就是怎么存儲Unicode代碼點的方案之一。另外還有UTF-16和UTF-32等編碼規(guī)范。Unicode為什么需要這么多編碼規(guī)范？直接存儲代碼點行不行？

當然不行，存儲了就需要解析比如”漢字”兩個字的Unicode代碼點是“0x6c49和0x5b57”也就是”6c495b57”。而且，Unicode的代碼點還有3個字節(jié)的，比如”10FF3B”,對于一個很長的上述數(shù)字串該怎么解析？比如“10FF3B6c495b57”！

所以，需要某種編碼方案來區(qū)分那幾個數(shù)值是一個Unicode代碼點，這種方案就是UTF-8、UTF-16、UTF-32這樣的編碼方案。

UTF-8編碼和代碼點對應(yīng)關(guān)系

UTF-8以字節(jié)為單位對Unicode進行編碼。從Unicode到UTF-8的編碼方式如下：

Unicode編碼(十六進制)	UTF-8 字節(jié)流(二進制)
000000-00007F	0xxxxxxx
000080-0007FF	110xxxxx 10xxxxxx
000800-00FFFF	1110xxxx 10xxxxxx 10xxxxxx
010000-10FFFF	11110xxx10xxxxxx10xxxxxx10xxxxxx

有沒有發(fā)現(xiàn)點什么？當一個字節(jié)表示一個字符時，二進制開頭是0；當兩個字節(jié)表示一個字符時，二進制開頭是11；當3個字節(jié)表示一個字符時，二進制開頭是111；依次類推！

UTF-8編碼加入了多余的標識位來區(qū)分一個Unicode代碼點！才會出現(xiàn)中文漢字集中在[0x4E00, 0x9FBB]范圍的16bit數(shù)值內(nèi)，UTF-8卻需要3個字節(jié)存儲的原因。

另一個經(jīng)典問題

怎么判斷Java字符串是否包含中文？

這個問題也很經(jīng)典，一般我們可以查到的方法如下：

    //代碼來自HanLP自然語言處理庫，git地址：https://github.com/hankcs/HanLP/blob/master/src/main/java/com/hankcs/hanlp/utility/TextUtility.java
    /**
     * 判斷某個字符是否為漢字
     *
     * @param c 需要判斷的字符
     * @return 是漢字返回true，否則返回false
     */
    public static boolean isChinese(char c)
    {
        String regex = "[\\u4e00-\\u9fa5]";
        return String.valueOf(c).matches(regex);
    }

//來源地址：https://blog.csdn.net/z69183787/article/details/53162069這里考慮進了CJK的擴展字符集


// GENERAL_PUNCTUATION 判斷中文的“號  
    // CJK_SYMBOLS_AND_PUNCTUATION 判斷中文的。號  
    // HALFWIDTH_AND_FULLWIDTH_FORMS 判斷中文的，號  
    private static final boolean isChinese(char c) {  
        Character.UnicodeBlock ub = Character.UnicodeBlock.of(c);  
        if (ub == Character.UnicodeBlock.CJK_UNIFIED_IDEOGRAPHS  
                || ub == Character.UnicodeBlock.CJK_COMPATIBILITY_IDEOGRAPHS  
                || ub == Character.UnicodeBlock.CJK_UNIFIED_IDEOGRAPHS_EXTENSION_A  
                || ub == Character.UnicodeBlock.GENERAL_PUNCTUATION  
                || ub == Character.UnicodeBlock.CJK_SYMBOLS_AND_PUNCTUATION  
                || ub == Character.UnicodeBlock.HALFWIDTH_AND_FULLWIDTH_FORMS) {  
            return true;  
        }  
        return false;  
    }

總結(jié)一下，一般來說用第一種方法就足夠了，擴展字符集用的比較少，另外從HanLP的github星數(shù)來說，這種方案的通用度還是可信的。

好了，先到這里。這里也留一個坑，mysql數(shù)據(jù)庫里邊的VARCHAR類型和Java的char類型是一種處理方式么？下一篇也會從String源代碼的角度對這里的分析進行一個佐證。

標簽： Mysql 代碼 數(shù)據(jù)庫 網(wǎng)絡(luò)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。