GBK、UTF8、GB2312和UTF-8的區別是什么

這篇文章主要介紹“GBK、UTF8、GB2312和UTF-8的區別是什么”，在日常操作中，相信很多人在GBK、UTF8、GB2312和UTF-8的區別是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”GBK、UTF8、GB2312和UTF-8的區別是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

UTF-8：Unicode TransformationFormat-8bit，允許含BOM，但通常不含BOM。是用以希圖國際上字符的一種多字節編碼，它對英文運用8位（即一個字節），中文運用24為（三個字節）來編碼。UTF-8包羅全天下所有國家需要用到的字符，是國際編碼，普片性強。UTF-8編碼的文字可以在各國贊成UTF8字符集的瀏覽器上顯示。如，如果是UTF8編碼，則在本國人的英文IE上也能顯示中文，他們無需下載IE的中文語言贊成包。

GBK是國家標準GB2312根柢上擴容后兼容GB2312的尺度。GBK的文字編碼是用雙字節來展示的，即不管中、英文字符均運用雙字節來表示，為了鑒別中文，將其最高位都設定成1。GBK搜羅一切中翰墨符，是國度編碼，普片性比UTF8差，不外UTF8占用的數據庫比GBK大。

GBK、GB2312等與UTF8之間都必須經由過程Unicode編碼技能花樣相互轉換：
GBK、GB2312－－Unicode－－UTF8
UTF8－－Unicode－－GBK、GB2312

CSS5容易從功能上說：

1、GBK通常指GB2312編碼 只支持簡體中翰墨

2、utf通常指UTF-8，贊成簡體中翰墨、繁體中文字、英文、日文、韓文等語言（贊成翰墨更廣）

3、通常外洋運用utf-8與gb2312，看自己需求決意

具體詳細先容如下：

對于一個站點、論壇來說，如果英翰墨符較多，則首倡使用UTF－8節省空間。不過當初得多論壇的插件通常只支持GBK。
個編碼的區別詳細解釋
簡單來講，unicode，gbk與大五碼便是編碼的值，而utf-8,uft-16之類即是這個值的表現模式．而前面那三種編碼是一兼容的，同一個漢字，那三個碼值是純粹紛歧樣的．如＂漢＂的uncode值與gbk就是不一樣的，若是uncode為a040，gbk為b030，而uft-8碼，就是把阿誰值表現的形式．utf-8碼徹底只針對uncode來組織的，如果ＧＢＫ要轉ＵＴＦ－８必需先轉uncode碼，再轉utf-8就ＯＫ了．

談談Unicode編碼，簡要解釋UCS、UTF、BMP、BOM等實詞

標題一： 
使用Windows記事本的“另存為”，可以在GBK、Unicode、Unicode big endian與UTF-8這幾種編碼方式間相互轉換。同樣是txt文件，Windows是怎樣辨認編碼方式的呢？

我很早前就發現Unicode、Unicode bigendian和UTF-8編碼的txt文件的開首會多出幾個字節，離別是FF、FE（Unicode）,FE、FF（Unicode bigendian）,EF、BB、BF（UTF-8）。但這些標志是基于甚么尺度呢？

問題二： 
近來在網上看到一個ConvertUTF.c，實現了UTF-32、UTF-16與UTF-8這三種編碼方式的彼此轉換。對于Unicode編碼(UCS2)、GBK、UTF-8這些編碼方式，我正本就意識。但這個舉措讓我有些懵懂，想不起來UTF-16和UCS2有甚么關連。 
查了查相關資料，總算將這些問題弄明晰了，專門也明了了一些Unicode的細節。寫成一篇文章，送給有過類似疑難的友人。本文在寫作時盡可能做到下里巴人，但要求讀者知道甚么是字節，什么是十六進制。

0、big endian和little endian
big endian與littleendian是CPU處置多字節數的不同方式。比如“漢”字的Unicode編碼是6C49。那末寫到文件里時，終究是將6C寫在前面，還是將49寫在前面？如果將6C寫在前面，就是big endian。如果將49寫在前面，等于little endian。

“endian”這個詞出自《格列佛游記》。正人國的內戰就源于吃雞蛋時是究竟從大頭(Big-Endian)敲開照舊從小頭(Little-Endian)敲開，由此曾發生過六次叛亂，一個皇帝送了命，另一個丟了王位。

咱們一般將endian翻譯成“字節序”，將big endian與little endian稱作“大尾”與“小尾”。

1、字符編碼、內碼，專門介紹漢字編碼
字符必需編碼后技能花樣被總計機處置懲罰。共計機運用的缺省編碼方式就是算計機的內碼。初期的總計機應用7位的ASCII編碼，為了處理漢字，遞次員設計了用于簡體中文的GB2312與用于繁體中文的big5。

GB2312(1980年)一共收錄了7445個字符，包括6763個漢字與682個其它符號。漢字區的內碼規模高字節從B0-F7，低字節從A1-FE，占用的碼位是72*94=6768。其中有5個閑暇是D7FA-D7FE。

GB2312贊成的漢字太少。1995年的漢字縮減規范GBK1.0收錄了21886個符號，它分為漢字區與圖形符號區。漢字區包括21003個字符。

從ASCII、GB2312到GBK，這些編碼辦法是向下兼容的，即同一個字符在這些方案中總是有雷同的編碼，后背的標準支持更多的字符。在這些編碼中，英文和中文可以抗衡地處理。區別中文編碼的辦法是高字節的最高位不為0。依照法式員的俗稱，GB2312、GBK都屬于雙字節字符集 (DBCS)。

2000年的GB18030是取代GBK1.0的正式國度尺度。該尺度收錄了27484個漢字，同時還收錄了藏文、蒙文、維吾爾文等首要的多半民族文字。從漢字字匯上說，GB18030在GB13000.1的20902個漢字的基礎上增長了CJK裁減A的6582個漢字（Unicode碼0x3400-0x4db5），一共收錄了27484個漢字。

CJK即是中日韓的含義。Unicode為了節省碼位，將中日韓三國語言中的筆墨抗衡編碼。GB13000.1便是ISO/IEC 10646-1的中文版，至關于Unicode 1.1。

GB18030的編碼采取單字節、雙字節和4字節方案。個中單字節、雙字節和GBK是純粹兼容的。4字節編碼的碼位即是收錄了CJK精簡A的6582個漢字。比如：UCS的0x3400在GB18030中的編碼應當是8139EF30，UCS的0x3401在GB18030中的編碼應當是8139EF31。

微軟供應了GB18030的晉級包，但這個升級包只不過提供了一套支持CJK擴展A的6582個漢字的新字體：新宋體-18030，的確不竄改內碼。Windows 的內碼仍然是GBK。

這里還有一些細節：

GB2312的原文照常區位碼，從區位碼到內碼，需要在高字節和低字節上劃分加上A0。

關于任何字符編碼，編碼單元的順序是由編碼方案指定的，與endian無關。例如GBK的編碼單元是字節，用兩個字節閃現一個漢字。這兩個字節的順序是靜止的，不受CPU字節序的影響。UTF-16的編碼單元是word（雙字節），word之間的順序是編碼方案指定的，word內部的字節分列才會遭到endian的影響。后背還會引見UTF-16。

GB2312的兩個字節的最高位但凡1。但吻合這個前提的碼位只有128*128=16384個。以是GBK和GB18030的低字節最高位均可能不是1。不外這不影響DBCS字符流的綜合：在讀取DBCS字符流時，只要碰到高位為1的字節，就能夠將下兩個字節作為一個雙字節編碼，而無庸管低字節的高位是什么。

2、Unicode、UCS與UTF
前面提到從ASCII、GB2312、GBK到GB18030的編碼辦法是向下兼容的。而Unicode只與ASCII兼容（更切確地說，是與ISO-8859-1兼容），與GB碼不兼容。譬喻“漢”字的Unicode編碼是6C49，而GB碼是BABA。

Unicode也是一種字符編碼方法，不外它是由國際組織設計，可以包容全球所有語言筆墨的編碼方案。Unicode的大名是"UniversalMultiple-Octet Coded Character Set"，簡喻為UCS。UCS可以看作是"Unicode CharacterSet"的縮寫。

根據維基百科全書(http://zh.wikipedia.org/wiki/)的記載：歷史上具備兩個試圖獨立設計Unicode的機關，即國際標準化組織（ISO）與一個軟件出產商的協會（unicode.org）。ISO墾荒了ISO 10646工程，Unicode協會開發了Unicode項目。

在1991年先后，單方都認識到全國不需要兩個不兼容的字符集。于是它們末尾分隔單方的任務成就，并為建樹一個單一編碼表而協同工作。從Unicode2.0最先，Unicode工程采用了與ISO 10646-1雷同的字庫與字碼。

目前兩個工程仍都存在，并獨立地頒發各自的規范。Unicode協會而今的最新版本是2005年的Unicode 4.1.0。ISO的最新尺度是ISO 10646-3:2003。

UCS只是規定若何編碼，并沒有劃定若何傳輸、留存這個編碼。比如“漢”字的UCS編碼是6C49，我可以用4個ascii數字來傳輸、生涯這個編碼；也能夠用utf-8編碼:3個間斷的字節E6 B189來透露表現它。要害在于通信雙方都要承認。UTF-8、UTF-7、UTF-16都是被遍及蒙受的方案。UTF-8的一個額定的優點是它與ISO-8859-1純粹兼容。UTF是“UCS Transformation Format”的縮寫。

IETF的RFC2781和RFC3629以RFC的一貫氣勢派頭，清晰、明快又不失鄭重地刻劃了UTF-16和UTF-8的編碼門徑。我老是記不得IETF是網絡 Engineering Task Force的縮寫。但IETF賣力護衛的RFC是網絡上一切規范的根抵。

2.1、內碼與code page
目前Windows的內核也曾贊成Unicode字符集，如許在內核上可以贊成舉世所有的語言文字。然而由于現有的多量步驟與文檔都采納了某種特定語言的編碼，比喻GBK，Windows不可能不支持現有的編碼，而全部改用Unicode。

Windows應用代碼頁(code page)來適應各個國度與區域。code page可以被理解為前面提到的內碼。GBK對應的code page是CP936。

微軟也為GB18030界說了code page：CP54936。然則由于GB18030有一一小塊4字節編碼，而Windows的代碼頁只贊成單字節與雙字節編碼，所以這個code page是沒法真正應用的。

3、UCS-2、UCS-4、BMP
UCS有兩種花色：UCS-2和UCS-4。顧名思義，UCS-2就是用兩個字節編碼，UCS-4就是用4個字節（理論上只用了31位，最高位必需為0）編碼。上面讓我們做一些容易的數學游戲：

UCS-2有2^16=65536個碼位，UCS-4有2^31=2147483648個碼位。

UCS-4根據最高位為0的最高字節分成2^7=128個group。每個group再根據次高字節分為256個plane。每個plane根據第3個字節分為256行 (rows)，每行采集256個cells。當然同一行的cells只不過收尾一個字節分歧，其余都相同。

group 0的plane 0被稱作Basic Multilingual Plane, 即BMP。大約說UCS-4中，高兩個字節為0的碼位被稱作BMP。

將UCS-4的BMP去掉前面的兩個零字節就取得了UCS-2。在UCS-2的兩個字節前加上兩個零字節，就獲取了UCS-4的BMP。而目前的UCS-4規范中還不有任何字符被分撥在BMP之外。

4、UTF編碼

UTF-8等于以8位為單位對UCS進行編碼。從UCS-2到UTF-8的編碼方式如下：

UCS-2編碼(16進制) UTF-8 字節流(二進制) 
0000 - 007F 0xxxxxxx 
0080 - 07FF 110xxxxx 10xxxxxx 
0800 - FFFF 1110xxxx 10xxxxxx 10xxxxxx

譬喻“漢”字的Unicode編碼是6C49。6C49在0800-FFFF之間，所以確定要用3字節模板了：1110xxxx 10xxxxxx10xxxxxx。將6C49寫成二進制是：0110 110001 001001， 用這個比特流按序庖代模板中的x，獲取：1110011010110001 10001001，即E6 B1 89。

讀者可以用記事本測試一下咱們的編碼可否正確。需要留神，UltraEdit在翻開utf-8編碼的文本文件時會積極轉換為UTF-16，可能孕育發生攪渾。你可以在配置中關掉這個選項。更好的工具是Hex Workshop。

UTF-16以16位為單元對UCS發展編碼。對付小于0x10000的UCS碼，UTF-16編碼就等于UCS碼對應的16位無符號整數。關于不小于0x10000的UCS碼，定義了一個算法。無非由于實際應用的UCS2，也許UCS4的BMP必然小于0x10000，所以就目前而言，可以認為UTF-16和UCS-2基原形似。但UCS-2只不過一個編碼方案，UTF-16卻要用于理論的傳輸，以是就不能不思索字節序的標題問題。

5、UTF的字節序與BOM
UTF-8以字節為編碼單元，不有字節序的問題。UTF-16以兩個字節為編碼單位，在解釋一個UTF-16文本前，首先要弄清晰每一個編碼單位的字節序。譬如“奎”的Unicode編碼是594E，“乙”的Unicode編碼是4E59。如果咱們收到UTF-16字節流“594E”，那么這是“奎”照常“乙”？

Unicode規范中引薦的符號字節順序的方式是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte order Mark。BOM是一個有點小伶俐的設法：

在UCS編碼中有一個叫做"ZERO WIDTH NO-BREAKSPACE"的字符，它的編碼是FEFF。而FFFE在UCS中是不具備的字符，所以不該該涌那時實踐傳輸中。UCS規范首倡咱們在傳輸字節流前，先傳輸字符"ZERO WIDTH NO-BREAK SPACE"。

何等如果領受者收到FEFF，就講明這個字節流是Big-Endian的；如果收到FFFE，就解釋這個字節流是Little-Endian的。因而字符"ZERO WIDTH NO-BREAK SPACE"又被稱作BOM。

UTF-8不需要BOM來疏解字節順序，但可以用BOM來剖明編碼方式。字符"ZERO WIDTH NO-BREAKSPACE"的UTF-8編碼是EF BB BF（讀者可以用我們前面介紹的編碼辦法驗證一下）。所以如果領受者收到以EF BBBF開首的字節流，就曉得這是UTF-8編碼了。

Windows即是應用BOM來符號文本文件的編碼方式的。

6、進一步的參考原料
本文主要參考的質料是 "Short overview of ISO-IEC 10646 and Unicode" (http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html)。

我還找了兩篇看下來不錯的資料，不外由于我劈頭劈臉的疑難都找到了答案，以是就不有看：

"Understanding Unicode A general introduction to the Unicode Standard" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a) 
"Character set encoding basics Understanding character set encodings and legacy encodings" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03) 
我寫過UTF-8、UCS-2、GBK互相轉換的軟件包，包括運用Windows API和不使用Windows API的版本。之后有歲月的話，我會收拾整頓一下放到我的整體主頁上

我是想清晰所有題目后才起源寫這篇文章的，原以為一會兒就能寫好。沒想到思量語言與查證細節破鈔了很耐久，居然從下晝1:30寫到9:00。指望有讀者能從中受益。

附錄1 再說說區位碼、GB2312、內碼與代碼頁
有的朋儕對文章中這句話還有疑難：
“GB2312的原文還是區位碼，從區位碼到內碼，需要在高字節和低字節上別離加上A0。”

我再詳細解釋一下：

“GB2312的原文”是指國度1980年的一個標準《中華人民共和國國家尺度 動靜互換用漢字編碼字符集 基本集 GB2312-80》。這個尺度用兩個數來編碼漢字與中文符號。第一個數稱為“區”，第二個數喻為“位”。以是也稱為區位碼。1-9區是中文符號，16-55區是一級漢字，56-87區是二級漢字。現在Windows也尚有區位輸入法，比方輸出1601失掉“啊”。（這個區位輸入法可以積極辨認16進制的GB2312和10進制的區位碼，也等于說輸入B0A1同樣會獲得“啊”。）

內碼是指壟斷瑣細內部的字符編碼。初期利用瑣細的內碼是與語言相關的。那會的Windows在系統內部支持Unicode，從此用代碼頁適應各類語言，“內碼”的觀念就比照含胡了。微軟通常將缺省代碼頁指定的編碼說成是內碼。

內碼這個詞匯，并無甚么民間的定義，代碼頁也只不過微軟這個公司的叫法。作為按次員，我們只有曉得它們是甚么器材，沒有緊要過量地驗證這些名詞。

所謂代碼頁(code page)等于針對一種語言文字的字符編碼。好比GBK的code page是CP936，BIG5的code page是CP950，GB2312的code page是CP20936。

Windows中出缺省代碼頁的概念，即缺省用什么編碼來解釋字符。比喻Windows的記事本掀開了一個文本文件，內中的內容是字節流：BA、BA、D7、D6。Windows應當去怎樣解釋它呢？

是依據Unicode編碼解釋、仍是依照GBK解釋、照樣根據BIG5解釋，照樣遵循ISO8859-1去解釋？如果按GBK去解釋，就會得到“漢字”兩個字。遵照其它編碼解釋，可能找不到對應的字符，也可能找到舛訛的字符。所謂“謬誤”是指與文本作者的本意不符，這時候就發生發火了亂碼。

謎底是Windows根據當前的缺省代碼頁去解釋文本文件里的字節流。缺省代碼頁可以經由管制面板的區域選項配置。記事本的另存為中有一項ANSI，的確便是遵照缺省代碼頁的編碼方法保留。

Windows的內碼是Unicode，它在技能上可以同時支持多個代碼頁。只需文件能注明本身運用甚么編碼，用戶又安裝了對應的代碼頁，Windows就能正確顯示，好比在HTML文件中就可以指定charset。

有的HTML文件作者，格外是英文作者，認為天下上所有人都使用英文，在文件中不指定charset。如果他應用了0x80-0xff之間的字符，中文Windows又遵照缺省的GBK去解釋，就會呈現亂碼。這時候只要在這個html文件中加之指定charset的語句，比喻：
<meta http-equiv="Content-Type" content="text/html; charset=ISO8859-1">
如果原作者運用的代碼頁和ISO8859-1兼容，就不會呈現亂碼了。

到此，關于“GBK、UTF8、GB2312和UTF-8的區別是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！