• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            積木

            No sub title

              C++博客 :: 首頁 :: 聯(lián)系 :: 聚合  :: 管理
              140 Posts :: 1 Stories :: 11 Comments :: 0 Trackbacks

            常用鏈接

            留言簿(1)

            我參與的團(tuán)隊(duì)

            搜索

            •  

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            原諒轉(zhuǎn)自:

            該文章介紹的不錯(cuò),值得收藏。

            最近有一些朋友常問我一些亂碼的問題,和他們交流過程中,發(fā)現(xiàn)這個(gè)編碼的相關(guān)知識(shí)還真是雜亂不堪,不少人對(duì)一些

            知識(shí)理解似乎也有些偏差,網(wǎng)上百度,google的內(nèi)容,也有不少以訛傳訛,根本就是錯(cuò)誤的(例如說 unicode編碼是兩

            個(gè)字節(jié)),各種軟件讓你選擇編碼的時(shí)候,常常是很長的一個(gè)選單,讓用戶不知道該如何選。基于這樣的問題,我就寫

            下我的理解吧,一方面幫助一些需要幫助的人糾正認(rèn)識(shí),一方面作為自己以后備查的資料。

            1.ASCII(American Standard Code for Information Interchange)
              美國信息交換標(biāo)準(zhǔn)代碼,這是計(jì)算機(jī)上最早使用的通用的編碼方案。那個(gè)時(shí)候計(jì)算機(jī)還只是拉丁文字的專利,根本沒

            有想到現(xiàn)在計(jì)算機(jī)的發(fā)展勢頭,如果想到了,可能一開始就會(huì)使用unicode了。當(dāng)時(shí)絕大部分專家都認(rèn)為,要用計(jì)算機(jī)

            ,必須熟練掌握英文。這種編碼占用7個(gè)Bit,在計(jì)算機(jī)中占用一個(gè)字節(jié),8位,最高位沒用,通訊的時(shí)候有時(shí)用作奇偶

            校驗(yàn)位。因此ASCII編碼的取值范圍實(shí)際上是:0x00-0x7f,只能表示128個(gè)字符。后來發(fā)現(xiàn)128個(gè)不太夠用,做了擴(kuò)展,

            叫做ASCII擴(kuò)展編碼,用足八位,取值范圍變成:0x00-0xff,能表示256個(gè)字符。其實(shí)這種擴(kuò)展意義不大,因?yàn)?56個(gè)字

            符表示一些非拉丁文字遠(yuǎn)遠(yuǎn)不夠,但是表示拉丁文字,又用不完。所以擴(kuò)展的意義還是為了下面的ANSI編碼服務(wù)。

            2.ANSI(American National Standard Institite )
              美國國家標(biāo)準(zhǔn)協(xié)會(huì),也就是說,每個(gè)國家(非拉丁語系國家)自己制定自己的文字的編碼規(guī)則,并得到了ANSI認(rèn)可,

            符合ANSI的標(biāo)準(zhǔn),全世界在表示對(duì)應(yīng)國家文字的時(shí)候都通用這種編碼就叫ANSI編碼。換句話說,中國的ANSI編碼和在日

            本的ANSI的意思是不一樣的,因?yàn)槎即碜约簢业奈淖志幋a標(biāo)準(zhǔn)。比如中國的ANSI對(duì)應(yīng)就是GB2312標(biāo)準(zhǔn),日本就是

            JIT標(biāo)準(zhǔn),香港,臺(tái)灣對(duì)應(yīng)的是BIG5標(biāo)準(zhǔn)等等。當(dāng)然這個(gè)問題也比較復(fù)雜,微軟從95開始,用就是自己搞的一個(gè)標(biāo)準(zhǔn)GBK

            。GB2312里面只有6763個(gè)漢字,682個(gè)符號(hào),所以確實(shí)有時(shí)候不是很夠用。GBK一直能和GB2312相互混淆并且相安無事的
            一個(gè)重要原因是GBK全面兼容GB2312,所以沒有出現(xiàn)任何沖突,你用GB2312編碼的文件通過GBK去解釋一定能獲得相同的

            顯示效果,換句話說:GBK對(duì)GB2312就是,你有的,我也有,你沒得的,我還有!


            好了,ANSI的標(biāo)準(zhǔn)是什么呢,首先是ASCII的代碼你不能用!也就是說ASCII碼在任何ANSI中應(yīng)該都是相同的。其他的,

            你們自己擴(kuò)展。所以呢,中國人就把ASCII碼變成8位,0x7f之前我不動(dòng)你的,我從0xa0開始編,0xa0到0xff才95個(gè)碼位

            ,對(duì)于中國字那簡直是杯水車薪,因此,就用兩個(gè)字節(jié)吧,因此編碼范圍就從0xA1A1 - 0xFEFE,這個(gè)范圍可以表示

            23901個(gè)漢字。基本夠用了吧,GB2312才7000多個(gè)呢!GBK更猛,編碼范圍是從0x8140 - 0xFEFE,可以表示3萬多個(gè)漢字

            。可以看出,這兩種方案,都能保證漢字頭一個(gè)字節(jié)在0x7f以上,從而和ASCII不會(huì)發(fā)生沖突。能夠?qū)崿F(xiàn)英文和漢字同

            時(shí)顯示。
            BIG5,香港和臺(tái)灣用的比較多,繁體,范圍: 0xA140 - 0xF9FE, 0xA1A1 - 0xF9FE,每個(gè)字由兩個(gè)字節(jié)組成,其第一

            字節(jié)編碼范圍為0xA1~0xF9,第二字節(jié)編碼范圍為0x40-0x7E與0xA1-0xFE,總計(jì)收入13868個(gè)字 (包括5401個(gè)常用字、

            7652 個(gè)次常用字、7個(gè)擴(kuò)充字、以及808個(gè)各式符號(hào))。


            那么到底ANSI是多少位呢?這個(gè)不一定!比如在GB2312和GBK,BIG5中,是兩位!但是其他標(biāo)準(zhǔn)或者其他語言如果不夠

            用,就完全可能不止兩位!

            例如:GB18030:
            GB18030-2000(GBK2K)在GBK的基礎(chǔ)上進(jìn)一步擴(kuò)展了漢字,增加了藏、蒙等少數(shù)民族的字形。GBK2K從根本上解決了字位

            不夠,字形不足的問題。它有幾個(gè)特點(diǎn):它并沒有確定所有的字形,只是規(guī)定了編碼范圍,留待以后擴(kuò)充。
            編碼是變長的,其二字節(jié)部分與GBK兼容;四字節(jié)部分是擴(kuò)充的字形、字位,其編碼范圍是首字節(jié)0x81-0xfe、二字節(jié)

            0x30-0x39、三字節(jié)0x81-0xfe、四字節(jié)0x30-0x39。它的推廣是分階段的,首先要求實(shí)現(xiàn)的是能夠完全映射到

            Unicode3.0標(biāo)準(zhǔn)的所有字形。它是國家標(biāo)準(zhǔn),是強(qiáng)制性的。

            搞懂了ANSI的含義,我們發(fā)現(xiàn)ANSI有個(gè)致命的缺陷,就是每個(gè)標(biāo)準(zhǔn)是各自為陣的,不保證能兼容。換句話說,要同時(shí)顯

            示中文和日本文或者阿拉伯文,就完全可能會(huì)出現(xiàn)一個(gè)編碼兩個(gè)字符集里面都有對(duì)應(yīng),不知道該顯示哪一個(gè)的問題,也

            就是編碼重疊的問題。顯然這樣的方案不好,所以Unicode才會(huì)出現(xiàn)!

            3.MBCS(Multi-Byte Chactacter System(Set))
              多字節(jié)字符系統(tǒng)或者字符集,基于ANSI編碼的原理上,對(duì)一個(gè)字符的表示實(shí)際上無法確定他需要占用幾個(gè)字節(jié)的,只

            能從編碼本身來區(qū)分和解釋。因此計(jì)算機(jī)在存儲(chǔ)的時(shí)候,就是采用多字節(jié)存儲(chǔ)的形式。也就是你需要幾個(gè)字節(jié)我給你放

            幾個(gè)字節(jié),比如A我給你放一個(gè)字節(jié),比如"中“,我就給你放兩個(gè)字節(jié),這樣的字符表示形式就是MBCS。
            在基于GBK的windows中,不會(huì)超過2個(gè)字節(jié),所以windows這種表示形式有叫做DBCS(Double-Byte Chactacter System

            ),其實(shí)算是MBCS的一個(gè)特例。
            C語言默認(rèn)存放字符串就是用的MBCS格式。從原理上來說,這樣是非常經(jīng)濟(jì)的一種方式。
            4.CodePage
              
            代碼頁,最早來自IBM,后來被微軟,oracle ,SAP等廣泛采用。因?yàn)锳NSI編碼每個(gè)國家都不統(tǒng)一,不兼容,可能導(dǎo)致沖

            突,所以一個(gè)系統(tǒng)在處理文字的時(shí)候,必須要告訴計(jì)算機(jī)你的ANSI是哪個(gè)國家和地區(qū)的標(biāo)準(zhǔn),這種國家和標(biāo)準(zhǔn)的代號(hào)(

            其實(shí)就是字符編碼格式的代號(hào)),微軟稱為Codepage代碼頁,其實(shí)這個(gè)代碼頁和字符集編碼的意思是一樣的。告訴你代

            碼頁,本質(zhì)就是告訴了你編碼格式。
            但是不同廠家的代碼頁可能是完全不同,哪怕是同樣的編碼,比如, UTF-8字符編碼 在IBM對(duì)應(yīng)的代碼頁是1208,在微

            軟對(duì)應(yīng)的是65001,在德國的SAP公司對(duì)應(yīng)的是 4110 。所以啊,其實(shí)本來就是一個(gè)東西,大家各自為政,搞那么多新名

            詞,實(shí)在沒必要!所以標(biāo)準(zhǔn)還是很重要的!!!
            比如GBK的在微軟的代碼頁是936,告訴你代碼頁是936其實(shí)和告訴你我編碼格式是GBK效果完全相同。那么處理文本的時(shí)

            候就不會(huì)有問題,不會(huì)去考慮某個(gè)代碼是顯示的韓文還是中文,同樣,日文和韓文的代碼頁就和中文不同,這樣就可以

            避免編碼沖突導(dǎo)致計(jì)算機(jī)不知如何處理的問題。當(dāng)然用這個(gè)也可以很容易的切換語言版本。
            但是這都是治標(biāo)不治本的方法,還是無法解決同時(shí)顯示多種語言的問題,所以最后還是都用unicode吧,永遠(yuǎn)不會(huì)有沖

            突了。
            5.Unicode(Universal Code)
              這是一個(gè)編碼方案,說白了就是一張包含全世界所有文字的一個(gè)編碼表,不管你用的上,用不上,不管是現(xiàn)在用的,

            還是以前用過的,只要這個(gè)世界上存在的文字符號(hào),統(tǒng)統(tǒng)給你一個(gè)唯一的編碼,這樣就不可能有任何沖突了。不管你要

            同時(shí)顯示任何文字,都沒有問題。
              因此在這樣的方案下,Unicode出現(xiàn)了。Unicode編碼范圍是:0-0x10FFFF,可以容納1114112個(gè)字符,100多萬啊。全

            世界的字符根本用不完了,Unicode 5.0版本中,才用了238605個(gè)碼位。所以足夠了。
            因此從碼位范圍看,嚴(yán)格的unicode需要3個(gè)字節(jié)來存儲(chǔ)。但是考慮到理解性和計(jì)算機(jī)處理的方便性,理論上還是用4個(gè)

            字節(jié)來描述。
               Unicode采用的漢字相關(guān)編碼用的是《CJK統(tǒng)一漢字編碼字符集》— 國家標(biāo)準(zhǔn) GB13000.1 是完全等同于國際標(biāo)準(zhǔn)《

            通用多八位編碼字符集 (UCS)》 ISO 10646.1。《GB13000.1》中最重要的也經(jīng)常被采用的是其雙字節(jié)形式的基本多文

            種平面。在這65536個(gè)碼位的空間中,定義了幾乎所有國家或地區(qū)的語言文字和符號(hào)。其中從0x4E00到 0x9FA5 的連續(xù)

            區(qū)域包含了 20902 個(gè)來自中國(包括臺(tái)灣)、日本、韓國的漢字,稱為 CJK (Chinese Japanese Korean) 漢字。CJK

            是《GB2312-80》、《BIG5》等字符集的超集。
              CJK包含了中國,日本,韓國,越南,香港,也就是CJKVH。這個(gè)在UNICODE的Charset chart中可以明顯看到。
              unicode的相關(guān)標(biāo)準(zhǔn)可以從unicode.org上面獲得,目前已經(jīng)進(jìn)行到了6.0版本。

            下面這段描述來自百度百科:
               Unicode字符集可以簡寫為UCS(Unicode Character Set)。早期的  unicodeUnicode標(biāo)準(zhǔn)有UCS-2、UCS-4的說法。

            UCS-2用兩個(gè)字節(jié)編碼,UCS-4用4個(gè)字節(jié)編碼。UCS-4根據(jù)最高位為0的最高字節(jié)分成2^7=128個(gè)group。每個(gè)group再根據(jù)

            次高字節(jié)分為256個(gè)平面(plane)。每個(gè)平面根據(jù)第3個(gè)字節(jié)分為256行 (row),每行有256個(gè)碼位(cell)。group 0

            的平面0被稱作BMP(Basic Multilingual Plane)。將UCS-4的BMP去掉前面的兩個(gè)零字節(jié)就得到了UCS-2。   每個(gè)平

            面有2^16=65536個(gè)碼位。Unicode計(jì)劃使用了17個(gè)平面,一共有17*65536=1114112個(gè)碼位。在Unicode 5.0.0版本中,已

            定義的碼位只有238605個(gè),分布在平面0、平面1、平面2、平面14、平面15、平面16。其中平面15和平面16上只是定義

            了兩個(gè)各占65534個(gè)碼位的專用區(qū)(Private Use Area),分別是0xF0000-0xFFFFD和0x100000-0x10FFFD。所謂專用區(qū)

            ,就是保留給大家放自定義字符的區(qū)域,可以簡寫為PUA。   平面0也有一個(gè)專用區(qū):0xE000-0xF8FF,有6400個(gè)碼位

            。平面0的0xD800-0xDFFF,共2048個(gè)碼位,是一個(gè)被稱作代理區(qū)(Surrogate)的特殊區(qū)域。代理區(qū)的目的用兩個(gè)UTF-

            16字符表示BMP以外的字符。在介紹UTF-16編碼時(shí)會(huì)介紹。   如前所述在Unicode 5.0.0版本中,238605-65534*2-

            6400-2408=99089。余下的99089個(gè)已定義碼位分布在平面0、平面1、平面2和平面14上,它們對(duì)應(yīng)著Unicode目前定義的

            99089個(gè)字符,其中包括71226個(gè)漢字。平面0、平面1、平面2和平面14上分別定義了52080、3419、43253和337個(gè)字符。

            平面2的43253個(gè)字符都是漢字。平面0上定義了27973個(gè)漢字。
             

            6.Unicode的實(shí)現(xiàn)方案
               Unicode其實(shí)只是一張巨大的編碼表。要在計(jì)算機(jī)里面實(shí)現(xiàn),也出現(xiàn)了幾種不同的方案。也就是說如何表示unicode

            編碼的問題。
            (1)UTF-8(UCS Transformation Format 8bit)
                這個(gè)方案的意思以8位為單位來標(biāo)識(shí)文字,注意并不是說一個(gè)文字用8位標(biāo)識(shí)。他其實(shí)是一種MBCS方案,可變字節(jié)的

            。到底需要幾個(gè)字節(jié)表示一個(gè)符號(hào),這個(gè)要根據(jù)這個(gè)符號(hào)的unicode編碼來決定,最多4個(gè)字節(jié)。
            編碼規(guī)則如下:
               Unicode編碼(16進(jìn)制) ║ UTF-8 字節(jié)流(二進(jìn)制)  
             000000 - 00007F ║ 0xxxxxxx   
            000080 - 0007FF ║ 110xxxxx 10xxxxxx   
            000800 - 00FFFF ║ 1110xxxx 10xxxxxx 10xxxxxx   
            010000 - 10FFFF ║ 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx   
            UTF-8的特點(diǎn)是對(duì)不同范圍的字符使用不同長度的編碼。對(duì)于0x00-0x7F之間的字符,UTF-8編碼與ASCII編碼完全相同。

            UTF-8編碼的最大長度是4個(gè)字節(jié)。從上表可以看出,4字節(jié)模板有21個(gè)x,即可以容納21位二進(jìn)制數(shù)字。Unicode的最大

            碼位0x10FFFF也只有21位。   
            例1:“漢”字的Unicode編碼是0x6C49。0x6C49在0x0800-0xFFFF之間,使用用3字節(jié)模板了:1110xxxx 10xxxxxx

            10xxxxxx。將0x6C49寫成二進(jìn)制是:0110 1100 0100 1001, 用這個(gè)比特流依次代替模板中的x,得到:11100110

            10110001 10001001,即E6 B1 89。   
            例2:Unicode編碼0x20C30在0x010000-0x10FFFF之間,使用用4字節(jié)模板了:11110xxx 10xxxxxx 10xxxxxx 10xxxxxx。

            將0x20C30寫成21位二進(jìn)制數(shù)字(不足21位就在前面補(bǔ)0):0 0010 0000 1100 0011 0000,用這個(gè)比特流依次代替模板

            中的x,得到:11110000 10100000 10110000 10110000,即F0 A0 B0 B0。

            (2)UTF-16
             UTF-16編碼以16位無符號(hào)整數(shù)為單位。注意是16位為一個(gè)單位,不表示一個(gè)字符就只有16位。現(xiàn)在機(jī)器上的unicode編

            碼一般指的就是UTF-16。絕大部分2個(gè)字節(jié)就夠了,但是不能絕對(duì)的說所有字符都是2個(gè)字節(jié)。這個(gè)要看字符的unicode

            編碼處于什么范圍而定,有可能是2個(gè)字節(jié),也可能是4個(gè)字節(jié)。這點(diǎn)請(qǐng)注意!
            下面算法解釋來自百度百科。

            我們把Unicode  unicode編碼記作U。編碼規(guī)則如下: 
              如果U<0x10000,U的UTF-16編碼就是U對(duì)應(yīng)的16位無符號(hào)整數(shù)(為書寫簡便,下文將16位無符號(hào)整數(shù)記作WORD)。

              如果U≥0x10000,我們先計(jì)算U'=U-0x10000,然后將U'寫成二進(jìn)制形式:yyyy yyyy yyxx xxxx xxxx,U的UTF-16

            編碼(二進(jìn)制)就是:110110yyyyyyyyyy 110111xxxxxxxxxx。為什么U'可以被寫成20個(gè)二進(jìn)制位?Unicode的最大碼位

            是0x10ffff,減去0x10000后,U'的最大值是0xfffff,所以肯定可以用20個(gè)二進(jìn)制位表示。
                例如:Unicode編碼0x20C30,減去0x10000后,得到0x10C30,寫成二進(jìn)制是:0001 0000 1100 0011 0000。用前10

            位依次替代模板中的y,用后10位依次替代模板中的x,就得到:1101100001000011 1101110000110000,即0xD843

            0xDC30。   
                按照上述規(guī)則,Unicode編碼0x10000-0x10FFFF的UTF-16編碼有兩個(gè)WORD,第一個(gè)WORD的高6位是110110,第二個(gè)

            WORD的高6位是110111。可見,第一個(gè)WORD的取值范圍(二進(jìn)制)是11011000 00000000到11011011 11111111,即

            0xD800-0xDBFF。第二個(gè)WORD的取值范圍(二進(jìn)制)是11011100 00000000到11011111 11111111,即0xDC00-0xDFFF。

              為了將一個(gè)WORD的UTF-16編碼與兩個(gè)WORD的UTF-16編碼區(qū)分開來,Unicode編碼的設(shè)計(jì)者將0xD800-0xDFFF保留下來

            ,并稱為代理區(qū)(Surrogate):   
            D800-DB7F ║ High Surrogates ║ 高位替代   
            DB80-DBFF ║ High Private Use Surrogates ║ 高位專用替代   
            DC00-DFFF ║ Low Surrogates ║ 低位替代   
               高位替代就是指這個(gè)范圍的碼位是兩個(gè)WORD的UTF-16編碼的第一個(gè)WORD。低位替代就是指這個(gè)范圍的碼位是兩個(gè)

            WORD的UTF-16編碼的第二個(gè)WORD。那么,高位專用替代是什么意思?我們來解答這個(gè)問題,順便看看怎么由UTF-16編碼

            推導(dǎo)Unicode編碼。   
              如果一個(gè)字符的UTF-16編碼的第一個(gè)WORD在0xDB80到0xDBFF之間,那么它的Unicode編碼在什么范圍內(nèi)?我們知道第

            二個(gè)WORD的取值范圍是0xDC00-0xDFFF,所以這個(gè)字符的UTF-16編碼范圍應(yīng)該是0xDB80 0xDC00到0xDBFF 0xDFFF。我們

            將這個(gè)范圍寫成二進(jìn)制:   1101101110000000 11011100 00000000 - 1101101111111111 1101111111111111   按

            照編碼的相反步驟,取出高低WORD的后10位,并拼在一起,得到   1110 0000 0000 0000 0000 - 1111 1111 1111

            1111 1111  
            即0xe0000-0xfffff,按照編碼的相反步驟再加上0x10000,得到0xf0000-0x10ffff。這就是UTF-16編碼的第一個(gè)WORD在

            0xdb80到0xdbff之間的Unicode編碼范圍,即平面15和平面16。因?yàn)閁nicode標(biāo)準(zhǔn)將平面15和平面16都作為專用區(qū),所以

            0xDB80到0xDBFF之間的保留碼位被稱作高位專用替代。

            (3)UTF-32
             這個(gè)就簡單了,和Unicode碼表基本一一對(duì)應(yīng),固定四個(gè)字節(jié)。
             為什么不采用UTF-32呢,因?yàn)閡nicode定義的范圍太大了,其實(shí)99%的人使用的字符編碼不會(huì)超過2個(gè)字節(jié),所以如同統(tǒng)

            一用4個(gè)字節(jié),簡單倒是簡單了,但是數(shù)據(jù)冗余確實(shí)太大了,不好,所以16位是最好的。就算遇到超過16位能表示的字

            符,我們也可以通過上面講到的代理技術(shù),采用32位標(biāo)識(shí),這樣的方案是最好的。所以現(xiàn)在絕大部分機(jī)器實(shí)現(xiàn)unicode

            還是采用的utf-16的方案。當(dāng)然也有UTF-8的方案。比如windows用的就是UTF16方案,不少linux用的就是utf8方案。

            7. 編碼存儲(chǔ)差異

            這里就要引出兩個(gè)名詞:
            LE(little endian):小字節(jié)字節(jié)序,意思就是一個(gè)單元在計(jì)算機(jī)中的存放時(shí)按照低位在前(低地址),高位在后(高

            地址)的模式存放。

            BE(big endian):大字節(jié)字節(jié)序,和LE相反,是高位在前,低位在后。

            比如一個(gè)unicode編碼為:0x006C49,如果是LE,那么在文件中的存放順序應(yīng)該是:49 6c 00
            如果是BE ,那么順序應(yīng)該是:00 6c 49

            8.編碼格式的檢測

            到底采用什么編碼,如果能檢測就好了。專家們也是這么想的,所以專家給每種格式和字節(jié)序規(guī)定了一些特殊的編碼,

            這些編碼在unicode 中是沒有使用的,所以不用擔(dān)心會(huì)沖突。

            這個(gè)叫做BOM(Byte Order Mark)頭。意思是字節(jié)序標(biāo)志頭。通過它基本能確定編碼格式和字節(jié)序。
            UTF編碼 ║ Byte Order Mark   
            UTF-8   ║ EF BB BF   
            UTF-16LE ║ FF FE   
            UTF-16BE ║ FE FF   
            UTF-32LE ║ FF FE 00 00   
            UTF-32BE ║ 00 00 FE FF
            所以通過檢測文件前面的BOM頭,基本能確定編碼格式和字節(jié)序。
            但是這個(gè)BOM頭只是建議添加,不是強(qiáng)制的,所以不少軟件和系統(tǒng)沒有添加這個(gè)BOM頭(所以有些軟件格式中有帶BOM頭

            和NoBOM頭的選擇),這個(gè)時(shí)候要檢測什么格式,就比較麻煩了
            當(dāng)然可以檢測,但是不能保證100%準(zhǔn)確,只能通過編碼范圍從概率上來檢查,雖然準(zhǔn)確度還是比較高,但是不能保證

            100%。所以,時(shí)常看到檢測錯(cuò)誤的軟件,也不奇怪了。

            總結(jié):
               終于寫完了,其實(shí)這些問題都是不統(tǒng)一導(dǎo)致的,屬于歷史問題,所以才會(huì)有這些困惑,這里也呼吁所有的軟件 開發(fā)

            人員自覺的采用Unicode標(biāo)準(zhǔn)進(jìn)行文字處理,我相信在不久的將來,這些困擾都不會(huì)存在了,因?yàn)樗熊浖际莡nicode

            d ,只要有字庫,任何文字都能同時(shí)顯示,也可以到任何語言的平臺(tái)上的去運(yùn)行,不再有亂碼的困惑!
              其實(shí)現(xiàn)在絕大部分軟件已經(jīng)是這么做的了!
               另外也不要被很多名詞屬于所迷惑,其實(shí)這些只是標(biāo)準(zhǔn)的問題,根本沒有什么新的東西,更沒有什么復(fù)雜的東西。

            posted on 2013-12-26 18:57 Jacc.Kim 閱讀(520) 評(píng)論(0)  編輯 收藏 引用 所屬分類: VC / C++
            国产精品美女久久久网AV| 国产一区二区精品久久凹凸| 婷婷久久综合九色综合九七| 久久国产午夜精品一区二区三区| 久久AAAA片一区二区| 久久亚洲国产精品成人AV秋霞| 久久人人爽爽爽人久久久| 成人精品一区二区久久| 久久中文字幕精品| 久久99热国产这有精品| 伊人久久大香线蕉精品不卡| 久久精品国产亚洲av麻豆色欲 | 欧美亚洲国产精品久久高清| 久久亚洲AV成人无码电影| 久久精品国产精品亚洲人人| 一本久道久久综合狠狠爱| 91精品日韩人妻无码久久不卡| 久久亚洲精精品中文字幕| 亚洲欧美成人久久综合中文网| 久久这里只精品国产99热| 久久综合噜噜激激的五月天| 久久久久久国产a免费观看黄色大片 | 99久久婷婷国产综合亚洲| 久久久久国产精品人妻| 久久精品国产99国产精品| 一本久久a久久精品综合夜夜| 亚洲国产欧美国产综合久久| 国产精品久久久香蕉| 久久久久亚洲国产| 亚洲国产日韩综合久久精品| 欧美性大战久久久久久| 久久中文字幕视频、最近更新| 久久久久久a亚洲欧洲aⅴ| 91久久精一区二区三区大全| 久久精品国产99久久久| 99久久99久久久精品齐齐| 97精品久久天干天天天按摩| 久久超乳爆乳中文字幕| 久久久久中文字幕| 国产亚洲成人久久| 理论片午午伦夜理片久久|