主頁(yè) > 知識(shí)庫(kù) > unicode utf-8 gb18030 gb2312 gbk各種編碼對(duì)比

unicode utf-8 gb18030 gb2312 gbk各種編碼對(duì)比

熱門標(biāo)簽:地圖標(biāo)注植物名稱 無(wú)錫電銷機(jī)器人銷售 招聘信息 福建ai電銷機(jī)器人加盟公司 鄭州中國(guó)移動(dòng)400電話申請(qǐng) 揭陽(yáng)外呼系統(tǒng)公司 熱血傳奇沃瑪森林地圖標(biāo)注 南召400電話辦理資費(fèi) 地圖標(biāo)注審核工作怎么樣注冊(cè) 去哪里辦卡
但是我這個(gè)的特點(diǎn)是追究原理,我在乎的事情都想弄明白,于是各個(gè)qq群依次發(fā)信息,沒(méi)人理會(huì)。唉,郁悶。只好自己google it and teach myself 。下面是詳細(xì)介紹。

還有對(duì)各方求助沒(méi)有人理會(huì),我有些個(gè)人想法。現(xiàn)在的人已經(jīng)很少有人去深究理論了,人們的觀念是得過(guò)且過(guò),人們通常只是知道什么,不知道為什么。對(duì)編程來(lái)說(shuō),個(gè)人認(rèn)為這是很悲哀的事情,也是非常危險(xiǎn)的事情。我想可能這也是中國(guó)的IT落后于美國(guó)的原因,我希望中國(guó)的編程人員能夠好好想想了。

下面的東西是從網(wǎng)上查到的

 Unicode 的編碼和實(shí)現(xiàn)

大概來(lái)說(shuō),Unicode 編碼系統(tǒng)可分為編碼方式和實(shí)現(xiàn)方式兩個(gè)層次。

 編碼方式

Unicode 的編碼方式與 ISO 10646通用字符集(Universal Character Set,UCS)概念相對(duì)應(yīng),目前實(shí)際應(yīng)用的 Unicode 版本對(duì)應(yīng)于 UCS-2,使用16的編碼空間。也就是每個(gè)字符占用2個(gè)字節(jié)。這樣理論上一共最多可以表示 216 即 65536 個(gè)字符。基本滿足各種語(yǔ)言的使用。實(shí)際上目前版本的 Unicode 尚未填充滿這16位編碼,保留了大量空間作為特殊使用或?qū)?lái)擴(kuò)展。

上述16位 Unicode 字符構(gòu)成基本多文種平面(Basic Multilingual Plane,簡(jiǎn)稱 BMP)。最新(但未實(shí)際廣泛使用)的 Unicode 版本定義了16個(gè)輔助平面,兩者合起來(lái)至少需要占據(jù)21位的編碼空間,比3字節(jié)略少。但事實(shí)上輔助平面字符仍然占用4字節(jié)編碼空間,與 UCS-4 保持一致。未來(lái)版本會(huì)擴(kuò)充到 ISO 10646-1 實(shí)現(xiàn)級(jí)別3,即涵蓋 UCS-4 的所有字符。UCS-4 是一個(gè)更大的尚未填充完全的31位字符集,加上恒為0的首位,共需占據(jù)32位,即4字節(jié)。理論上最多能表示 231 個(gè)字符,完全可以涵蓋一切語(yǔ)言所用的符號(hào)。

BMP 字符的 Unicode 編碼表示為 U+hhhh,其中每個(gè) h 代表一個(gè)十六進(jìn)制數(shù)位。與 UCS-2 編碼完全相同。對(duì)應(yīng)的4字節(jié) UCS-4 編碼后兩個(gè)字節(jié)一致,前兩個(gè)字節(jié)的所有位均為0。

關(guān)于 Unicode 和 ISO 10646 及 UCS 的詳細(xì)關(guān)系 ,請(qǐng)參看通用字符集。

實(shí)現(xiàn)方式

Unicode 的實(shí)現(xiàn)方式不同于編碼方式。一個(gè)字符的 Unicode 編碼是確定的。但是在實(shí)際傳輸過(guò)程中,由于不同系統(tǒng)平臺(tái)的設(shè)計(jì)不一定一致,以及出于節(jié)省空間的目的,對(duì) Unicode 編碼的實(shí)現(xiàn)方式有所不同。Unicode 的實(shí)現(xiàn)方式稱為Unicode轉(zhuǎn)換格式(Unicode Translation Format,簡(jiǎn)稱為 UTF)。

例如,如果一個(gè)僅包含基本7位ASCII字符的 Unicode 文件,如果每個(gè)字符都使用2字節(jié)的原 Unicode 編碼傳輸,其第一字節(jié)的8位始終為0。這就造成了比較大的浪費(fèi)。對(duì)于這種情況,可以使用 UTF-8 編碼,這是一種變長(zhǎng)編碼,它將基本7位ASCII字符仍用7位編碼表示,占用一個(gè)字節(jié)(首位補(bǔ)0)。而遇到與其他 Unicode 字符混合的情況,將按一定算法轉(zhuǎn)換,每個(gè)字符使用1-3個(gè)字節(jié)編碼,并利用首位為0或1進(jìn)行識(shí)別。這樣對(duì)以7位ASCII字符為主的西文文檔就大大節(jié)省了編碼長(zhǎng)度(具體方案參見(jiàn)UTF-8)。類似的,對(duì)未來(lái)會(huì)出現(xiàn)的需要4個(gè)字節(jié)的輔助平面字符和其他 UCS-4 擴(kuò)充字符,2字節(jié)編碼的 UTF-16 也需要通過(guò)一定的算法進(jìn)行轉(zhuǎn)換。

再如,如果直接使用與 Unicode 編碼一致(僅限于 BMP 字符)的 UTF-16 編碼,由于每個(gè)字符占用了兩個(gè)字節(jié),Macintosh (Mac)機(jī)和PC機(jī)上,對(duì)字節(jié)順序的理解是不一致的。這時(shí)同一字節(jié)流可能會(huì)被解釋為不同內(nèi)容,如某字符為十六進(jìn)制編碼4E59,按兩個(gè)字節(jié)拆分為4E和59,在Mac上讀取時(shí)是從低字節(jié)開(kāi)始,那么在Mac OS會(huì)認(rèn)為此4E59編碼為594E,找到的字符為“奎”,而在Windows上從高字節(jié)開(kāi)始讀取,則編碼為 U+4E59 的字符為“乙”。就是說(shuō)在Windows下以UTF-16編碼保存一個(gè)字符“乙”,在Mac OS里打開(kāi)會(huì)顯示成“奎”。此類情況說(shuō)明UTF-16的編碼順序若不加以人為定義就可能發(fā)生混淆,于是在 UTF-16 編碼實(shí)現(xiàn)方式中使用了大尾序(Big-Endian, 簡(jiǎn)寫為UTF-16 BE)、小尾序(Little-Endian, 簡(jiǎn)寫為UTF-16 LE)的概念,以及可附加的BOM(Byte Order Mark)解決方案目前在PC機(jī)上的Windows系統(tǒng)和Linux系統(tǒng)對(duì)于UTF-16編碼默認(rèn)使用UTF-16 LE。(具體方案參見(jiàn)UTF-16

此外 Unicode 的實(shí)現(xiàn)方式還包括 UTF-7、Punycode、CESU-8SCSU、UTF-32等,這些實(shí)現(xiàn)方式有些僅在一定的國(guó)家和地區(qū)使用,有些則屬于未來(lái)的規(guī)劃方式。目前通用的實(shí)現(xiàn)方式是 UTF-16小尾序(BOM)、UTF-16大尾序(BOM)和 UTF-8。在微軟公司Windows XP操作系統(tǒng)附帶的記事本Notepad)中,“另存為”對(duì)話框可以選擇的四種編碼方式除去非 Unicode 編碼的ANSI(對(duì)于英文系統(tǒng)即ASCII編碼,中文系統(tǒng)則為GB2312Big5編碼) 外,其余三種為“Unicode”(對(duì)應(yīng)UTF-16 LE)、“Unicode big endian”(對(duì)應(yīng)UTF-16 BE)和“UTF-8”。

目前輔助平面的工作主要集中在第二和第三平面的中日韓統(tǒng)一表意文字中,因此包括GBK、GB18030、Big5簡(jiǎn)體中文繁體中文、日文韓文以及越南喃字的各種編碼與 Unicode 的協(xié)調(diào)性被重點(diǎn)關(guān)注??紤]到 Unicode 最終要涵蓋所有的字符,從某種意義而言,這些編碼方式也可視作 Unicode 的出現(xiàn)于其之前的既成事實(shí)的實(shí)現(xiàn)方式,如同ASCII及其擴(kuò)展Latin-1一樣,后兩者的字符在16位 Unicode 編碼空間中的編碼第一字節(jié)各位全為0,第二字節(jié)編碼與原編碼完全一致。但上述東亞語(yǔ)言編碼與 Unicode 編碼的對(duì)應(yīng)關(guān)系要復(fù)雜得多。

 

utf-8

 

 

UTF-8(8 位元 Universal Character Set/Unicode Transformation Format)是一種針對(duì) Unicode 的可變長(zhǎng)度字符編碼。它可以用來(lái)表示 Unicode 標(biāo)準(zhǔn)中的任何字符,且其編碼中的第一個(gè)字節(jié)仍與 ASCII 相容,這使得原來(lái)處理 ASCII 字符的軟件無(wú)須或只須做少部份修改,即可繼續(xù)使用。因此,它逐漸成為電子郵件、網(wǎng)頁(yè)及其他儲(chǔ)存或傳送文字的應(yīng)用中,優(yōu)先采用的編碼。

UTF-8 使用一至四個(gè)字節(jié)為每個(gè)字符編碼:

  1. 128 個(gè) US-ASCII 字符只需一個(gè)字節(jié)編碼(Unicode 范圍由 U+0000 至 U+007F)。
  2. 帶有附加符號(hào)拉丁文希臘文、西里爾字母亞美尼亞語(yǔ)、希伯來(lái)文阿拉伯文、敘利亞文它拿字母則需要二個(gè)字節(jié)編碼(Unicode 范圍由 U+0080 至 U+07FF)。
  3. 其他基本多文種平面(BMP)中的字符(這包含了大部分常用字)使用三個(gè)字節(jié)編碼。
  4. 其他極少使用的 Unicode 輔助平面的字符使用四字節(jié)編碼。

對(duì)上述提及的第四種字符而言,UTF-8 使用四個(gè)字節(jié)來(lái)編碼似乎太耗費(fèi)資源了。但 UTF-8 對(duì)所有常用的字符都可以用三個(gè)字節(jié)表示,而且它的另一種選擇,UTF-16編碼,對(duì)前述的第四種字符同樣需要四個(gè)字節(jié)來(lái)編碼,所以要決定 UTF-8 或 UTF-16 哪種編碼比較有效率,還要視所使用的字符的分布范圍而定。不過(guò),如果使用一些傳統(tǒng)的壓縮系統(tǒng),比如 DEFLATE,則這些不同編碼系統(tǒng)間的的差異就變得微不足道了。若顧及傳統(tǒng)壓縮算法在壓縮較短文字上的效果不大,可以考慮使用 Standard Compression Scheme for Unicode(SCSU)。

 

Unicode字符位元被分割為數(shù)個(gè)部分,并分配到UTF-8的字節(jié)串中較低的位元的位置。在U+0080的以下字符都使用內(nèi)含其字符的單字節(jié)編碼。這些編碼正好對(duì)應(yīng)7位元的ASCII字符。在其他情況,有可能需要多達(dá)4個(gè)字符組來(lái)表示一個(gè)字符。這些多字節(jié)的最高有效位元會(huì)設(shè)定成1,以防止與7位元的ASCII字符混淆,并保持標(biāo)準(zhǔn)的字節(jié)主導(dǎo)字串(standard byte-oriented string)運(yùn)作順利。

代碼范圍
十六進(jìn)制
標(biāo)量值(scalar value)
二進(jìn)制
UTF-8
二進(jìn)制十六進(jìn)制
注釋
000000 - 00007F
128個(gè)代碼
00000000 00000000 0zzzzzzz 0zzzzzzz(00-7F) ASCII字符范圍,字節(jié)由零開(kāi)始
七個(gè)z 七個(gè)z
000080 - 0007FF
1920個(gè)代碼
00000000 00000yyy yyzzzzzz 110yyyyy(C2-DF) 10zzzzzz(80-BF) 第一個(gè)字節(jié)由110開(kāi)始,接著的字節(jié)由10開(kāi)始
三個(gè)y;二個(gè)y;六個(gè)z 五個(gè)y;六個(gè)z
000800 - 00D7FF
00E000 - 00FFFF
61440個(gè)代碼 [Note 1]
00000000 xxxxyyyy yyzzzzzz 1110xxxx(E0-EF) 10yyyyyy 10zzzzzz 第一個(gè)字節(jié)由1110開(kāi)始,接著的字節(jié)由10開(kāi)始
四個(gè)x;四個(gè)y;二個(gè)y;六個(gè)z 四個(gè)x;六個(gè)y;六個(gè)z
010000 - 10FFFF
1048576個(gè)代碼
000wwwxx xxxxyyyy yyzzzzzz 11110www(F0-F4) 10xxxxxx 10yyyyyy 10zzzzzz 由11110開(kāi)始,接著的字節(jié)由10開(kāi)始
三個(gè)w;二個(gè)x;四個(gè)x;四個(gè)y;二個(gè)y;六個(gè)z 三個(gè)w;六個(gè)x;六個(gè)y;六個(gè)z

Note 1  Unicode在范圍D800-DFFF中不存在任何字符,基本多文種平面中約定了這個(gè)范圍用于UTF-16擴(kuò)展標(biāo)識(shí)輔助平面(兩個(gè)UTF-16表示一個(gè)輔助平面字符)。當(dāng)然,任何編碼都是可以被轉(zhuǎn)換到這個(gè)范圍,但在unicode中他們并不代表任何合法的值。

以上這個(gè)表是php截取utf-8字符串的關(guān)鍵,根據(jù)每個(gè)字節(jié)的前幾位的數(shù)字決定該字符占幾個(gè)字節(jié)(utf-8的編碼有點(diǎn)類似于5類IP地址的編碼)

 

例如,希伯來(lái)語(yǔ)字母 aleph(א)的Unicode代碼是 U+05D0,按照以下方法改成 UTF-8:

  • 它屬于 U+0080到U+07FF區(qū)域,這個(gè)表說(shuō)明它使用雙字節(jié),110yyyyy 10zzzzzz.
  • 十六進(jìn)制 的 0x05D0換算成二進(jìn)制就是 101-1101-0000.
  • 這11位數(shù)按順序放入"y"部分和"z"部分:11010111 10010000.
  • 最后結(jié)果就是雙字節(jié),用十六進(jìn)制寫起來(lái)就是 0xD7 0x90,這就是這個(gè)字符aleph(א)的UTF-8編碼。

所以開(kāi)始的128個(gè)字符(US-ASCII)只需一字節(jié),接下來(lái)的1920個(gè)字符需要雙字節(jié)編碼,包括帶附加符號(hào)拉丁字母,希臘字母,西里爾字母,科普特語(yǔ)字母,亞美尼亞語(yǔ)字母,希伯來(lái)文字母和阿拉伯字母的字符。基本多文種平面中其余的字符使用三個(gè)字節(jié),剩余字符使用四個(gè)字節(jié)。

 

設(shè)計(jì)UTF-8的理由(utf-8的特點(diǎn))

UTF-8的設(shè)計(jì)有以下的多字符組序列的特質(zhì):

  • 單字節(jié)字符的最高有效位元永遠(yuǎn)為0。
  • 多字節(jié)序列中的首個(gè)字符組的幾個(gè)最高有效位元決定了序列的長(zhǎng)度。最高有效位為110的是2字節(jié)序列,而1110的是三字節(jié)序列,如此類推。
  • 多字節(jié)序列中其余的字節(jié)中的首兩個(gè)最高有效位元為10。

UTF-8的這些特質(zhì),保證了一個(gè)字符的字節(jié)序列不會(huì)包含在另一個(gè)字符的字節(jié)序列中。這確保了以字節(jié)為基礎(chǔ)的部份字串比對(duì)(sub-string match)方法可以適用于在文字中搜尋字或詞。有些比較舊的可變長(zhǎng)度8位元編碼(如Shift JIS)沒(méi)有這個(gè)特質(zhì),故字串比對(duì)的算法變得相當(dāng)復(fù)雜。雖然這增加了UTF-8編碼的字串的信息冗余,但是利多于弊。另外,資料壓縮并非Unicode 的目的,所以不可混為一談。即使在傳送過(guò)程中有部份字節(jié)因錯(cuò)誤或干擾而完全遺失,還是有可能在下一個(gè)字符的起點(diǎn)重新同步,令受損范圍受到限制。

另一方面,由于其字節(jié)序列設(shè)計(jì),如果一個(gè)疑似為字符串的序列被驗(yàn)證為UTF-8編碼,那么我們可以有把握地說(shuō)它是UTF-8字符串。一段兩字節(jié)隨機(jī)序列碰巧為合法的UTF-8而非ASCII 的機(jī)率為32分1。對(duì)于三字節(jié)序列的機(jī)率為256分3,對(duì)更長(zhǎng)的序列的機(jī)率就更低了。

  • 在ASCII碼的范圍,用一個(gè)字節(jié)表示,超出ASCII碼的范圍就用字節(jié)表示,這就形成了我們上面看到的UTF-8的表示方法,這様?shù)暮锰幨钱?dāng)UNICODE文件中只有ASCII碼時(shí),儲(chǔ)存的文件都為一個(gè)字節(jié),所以就是普通的ASCII文件無(wú)異,讀取的時(shí)候也是如此,所以能與以前的ASCII文件相容。
  • 大于ASCII碼的,就會(huì)由上面的第一字節(jié)的前幾位表示該unicode字符的長(zhǎng)度,比如110xxxxxx前三位的二進(jìn)制表示告訴我們這是個(gè) 2BYTE的UNICODE字符;1110xxxx是個(gè)三位的UNICODE字符,依此類推;xxx 的位置由字符編碼數(shù)的二進(jìn)制表示的位填入。越靠右的 x 具有越少的特殊意義。只用最短的那個(gè)足夠表達(dá)一個(gè)字符編碼數(shù)的多字節(jié)串。注意在多字節(jié)串中,第一個(gè)字節(jié)的開(kāi)頭"1"的數(shù)目就是整個(gè)串中字節(jié)的數(shù)目。。

 unicode和utf-8轉(zhuǎn)換

utf-8的特性

  • UCS 字符 U+0000 到 U+007F (ASCII) 被編碼為字節(jié) 0x00 到 0x7F(ASCII 兼容),這也意味著只包含 7 位 ASCII 字符的文件在 ASCII 和 UTF-8 兩種編碼方式下是一樣的。
  • 所有 >U+007F 的 UCS 字符被編碼為一個(gè)多個(gè)字節(jié)的串,每個(gè)字節(jié)都有標(biāo)記位集。因此,ASCII 字節(jié) (0x00-0x7F) 不可能作為任何其他字符的一部分。
  • 表示非 ASCII 字符的多字節(jié)串的第一個(gè)字節(jié)總是在 0xC0 到 0xFD 的范圍里,并指出這個(gè)字符包含多少個(gè)字節(jié)。多字節(jié)串的其余字節(jié)都在 0x80 到 0xBF 范圍里,這使得重新同步非常容易,并使編碼無(wú)國(guó)界,且很少受丟失字節(jié)的影響。
  • 可以編入所有可能的 231個(gè) UCS 代碼
  • UTF-8 編碼字符理論上可以最多到 6 個(gè)字節(jié)長(zhǎng),然而 16 位 BMP 字符最多只用到 3 字節(jié)長(zhǎng)。
  • Bigendian UCS-4 字節(jié)串的排列順序是預(yù)定的。
  • 字節(jié) 0xFE 和 0xFF 在 UTF-8 編碼中從未用到,同時(shí),UTF-8以字節(jié)為編碼單元,它的字節(jié)順序在所有系統(tǒng)中都是一様?shù)?,沒(méi)有字節(jié)序的問(wèn)題,也因此它實(shí)際上并不需要BOM。
  • 與 UTF-16 或其他 Unicode 編碼相比,對(duì)于不支援 Unicode 和 XML 的系統(tǒng),UTF-8 更不容易造成問(wèn)題。

gb18030 

GB 2312-1980完全兼容,與GBK基本兼容,支持GB 13000Unicode的全部統(tǒng)一漢字,共收錄漢字70244個(gè)。

GB 18030主要有以下特點(diǎn):

  • 采用字節(jié)編碼,每個(gè)字可以由1個(gè)、2個(gè)或4個(gè)字節(jié)組成。(變長(zhǎng)編碼)
  • 編碼空間龐大,最多可定義161萬(wàn)個(gè)字符。
  • 支持中國(guó)國(guó)內(nèi)少數(shù)民族的文字,不需要?jiǎng)佑迷熳謪^(qū)。

字節(jié)結(jié)構(gòu)

  • 單字節(jié),其值從0到0x7F。
  • 雙字節(jié),第一個(gè)字節(jié)的值從0x81到0xFE,第二個(gè)字節(jié)的值從0x40到0xFE(不包括0x7F)。
  • 四字節(jié),第一個(gè)字節(jié)的值從0x81到0xFE,第二個(gè)字節(jié)的值從0x30到0x39,第三個(gè)字節(jié)從0x81到0xFE,第四個(gè)字節(jié)從0x30到0x39。

gb2312

 

 

GB2312編碼通行于中國(guó)大陸;新加坡等地也采用此編碼。中國(guó)大陸幾乎所有的中文系統(tǒng)和國(guó)際化的軟件都支持GB 2312。

GB 2312標(biāo)準(zhǔn)共收錄6763個(gè)漢字,其中一級(jí)漢字3755個(gè),二級(jí)漢字3008個(gè);同時(shí),GB 2312收錄了包括拉丁字母、希臘字母、日文平假名片假名字母、俄語(yǔ)西里爾字母在內(nèi)的682個(gè)全角字符。

GB 2312的出現(xiàn),基本滿足了漢字的計(jì)算機(jī)處理需要,它所收錄的漢字已經(jīng)覆蓋中國(guó)大陸99.75%的使用頻率。

對(duì)于人名、古漢語(yǔ)等方面出現(xiàn)的罕用字,GB 2312不能處理,這導(dǎo)致了后來(lái)GBKGB 18030漢字字符集的出現(xiàn)。

GB 2312中對(duì)所收漢字進(jìn)行了“分區(qū)”處理,每區(qū)含有94個(gè)漢字/符號(hào)。這種表示方式也稱為區(qū)位碼。

  • 01-09區(qū)為特殊符號(hào)。
  • 16-55區(qū)為一級(jí)漢字,按拼音排序。
  • 56-87區(qū)為二級(jí)漢字,按部首/筆畫排序。

10-15區(qū)及88-94區(qū)則未有編碼。

舉例來(lái)說(shuō),“啊”字是GB2312之中的第一個(gè)漢字,它的區(qū)位碼就是1601。

 字節(jié)結(jié)構(gòu)

在使用GB2312的程序中,通常采用EUC儲(chǔ)存方法,以便兼容于ASCII。瀏覽器編碼表上的“GB2312”,通常都是指“EUC-CN”表示法。

每個(gè)漢字及符號(hào)以兩個(gè)字節(jié)來(lái)表示。第一個(gè)字節(jié)稱為“高位字節(jié)”,第二個(gè)字節(jié)稱為“低位字節(jié)”。

“高位字節(jié)”使用了0xA1-0xF7(把01-87區(qū)的區(qū)號(hào)加上0xA0),“低位字節(jié)”使用了0xA1-0xFE(把01-94加上0xA0)。 由于一級(jí)漢字從16區(qū)起始,漢字區(qū)的“高位字節(jié)”的范圍是0xB0-0xF7,“低位字節(jié)”的范圍是0xA1-0xFE,占用的碼位是72*94=6768。其中有5個(gè)空位是D7FA-D7FE。

例如“啊”字在大多數(shù)程序中,會(huì)以兩個(gè)字節(jié),0xB0(第一個(gè)字節(jié))0xA1(第二個(gè)字節(jié))儲(chǔ)存。(與區(qū)位碼對(duì)比:0xB0=0xA0+16,0xA1=0xA0+1)。

 

EUC-CN(網(wǎng)上下到的編碼表就是這個(gè))(gb2312的字符串截取也是按照該表截取的)

EUC-CNGB 2312最常用的表示方法。瀏覽器編碼表上的“GB2312”,通常都是指“EUC-CN”表示法。

GB 2312字符使用兩個(gè)字節(jié)來(lái)表示。

“第一位字節(jié)”使用0xA1-0xF7
“第二位字節(jié)”使用0xA1-0xFE

舉例來(lái)說(shuō),“啊”字是GB 2312之中的第一個(gè)漢字,它的區(qū)位碼是1601。

在EUC-CN之中,它把0xA0+16=0xB0,0xA0+1=0xA1,得出0xB0A1。

您可能感興趣的文章:
  • Python實(shí)現(xiàn)把utf-8格式的文件轉(zhuǎn)換成gbk格式的文件
  • 趣談Unicode、Ascii、utf-8、GB2312、GBK等編碼知識(shí)
  • Shell腳本把文件從GBK轉(zhuǎn)為UTF-8編碼
  • PHP 正則判斷中文UTF-8或GBK的思路及具體實(shí)現(xiàn)
  • 字符編碼詳解及由來(lái)(UNICODE,UTF-8,GBK) 比較詳細(xì)
  • UTF-8 GBK UTF8 GB2312 之間的區(qū)別和關(guān)系介紹
  • 常用字符集編碼詳解(ASCII GB2312 GBK GB18030 unicode UTF-8)
  • 首頁(yè)四格,首頁(yè)五格For6.0(GBK)(UTF-8)[12種組合][9-18][版主安裝測(cè)試通過(guò)]
  • MySQL GBK→UTF-8編碼轉(zhuǎn)換
  • Java gbk轉(zhuǎn)utf-8

標(biāo)簽:黔南 文山 鹽城 桂林 景德鎮(zhèn) 南昌 東莞 宣城

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《unicode utf-8 gb18030 gb2312 gbk各種編碼對(duì)比》,本文關(guān)鍵詞  unicode,utf-8,gb18030,gb2312,gbk,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問(wèn)題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無(wú)關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《unicode utf-8 gb18030 gb2312 gbk各種編碼對(duì)比》相關(guān)的同類信息!
  • 本頁(yè)收集關(guān)于unicode utf-8 gb18030 gb2312 gbk各種編碼對(duì)比的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章