一 編碼定義
用預先規定的方法將文字、數字或其他對象編成數碼，或將信息、數據轉換成規定的電脈衝信號。編碼在電子計算機、電視、遙控和通訊等方面廣泛使用。
編碼是根據一定的協議或格式把模擬信息轉換成比特流的過程。
在計算機硬件中，編碼（coding）是在一個主題或單元上爲數據存儲，管理和分析的目的而轉換信息爲編碼值（典型地如數字）的過程。在軟件中，編碼意味着邏輯地使用一個特定的語言如C或C++來執行一個程序。在密碼學中，編碼是指在編碼或密碼中寫的行爲。
將數據轉換爲代碼或編碼字符，並能譯爲原數據形式。是計算機書寫指令的過程，程序設計中的一部分。在地圖自動製圖中，按一定規則用數字與字母表示地圖內容的過程，通過編碼，使計算機能識別地圖的各地理要素。
n位二進制數可以組合成2的n次方個不同的信息，給每個信息規定一個具體碼組，這種過程也叫編碼。
數字系統中常用的編碼有兩類，一類是二進制編碼，另一類是二—十進制編碼。
二 漢字的編碼體系
1．ASCII與Binary
我們日常接觸到的文件分ASCII和Binary兩種。ASCII是“美國信息交換標準編碼”的英文字頭縮寫，可稱之爲“美標”。美標規定了用從0到127的128個數字來代表信息的規範編碼，其中包括33個控制碼，一個空格碼，和94個形象碼。形象碼中包括了英文大小寫字母，阿拉伯數字，標點符號等。我們平時閱讀的英文電腦文本，就是以形象碼的方式傳遞和存儲的。美標是國際上大部分大小電腦的通用編碼。
然而電腦中的一個字符大都是用一個八位數的二進制數字表示。這樣每一字符便可能有256個不同的數值。由於美標只規定了128個編碼，剩下的另外128個數碼沒有規範，各家用法不一。另外美標中的33個控制碼，各廠家用法也不盡一致。這樣我們在不同電腦間交換文件的時候，就有必要區分兩類不同的文件。第一類文件中每一個字都是美標形象碼或空格碼。這類文件稱爲“美標文本文件”(ASCII Text Files)，或略爲“文本文件”，通常可在不同電腦系統間直接交換。第二類文件，也就是含有控制碼或非美標碼的文件，通常不能在不同電腦系統間直接交換。這類文件有一個通稱，叫“二進制文件”(Binary Files)。
2．國標、區位、“準國標”
“國標”是“中華人民共和國國家標準信息交換用漢字編碼”的簡稱。國標表（基本表）把七千餘漢字、以及標點符號、外文字母等，排成一個94行、94列的方陣。方陣中每一橫行叫一個“區”，每個區有九十四個“位”。一個漢字在方陣中的座標，稱爲該字的“區位碼”。例如“中”字在方陣中處於第５４區第４８位，它的區位碼就是5448。
其實94這個數字。它是美標中形象碼的總數。國標表沿用這個數字，本意大概是要用兩個美標形象符代表一個漢字。由於美標形象符的編碼是從33到126，漢字區、位碼如果各加上32，就會與美標形象碼的範圍重合。如上例“中”字區、位碼加上32後，得86,80。這兩個數字的十六進制放在一起得5650，稱爲該字的“國標碼”，而與其相對應的兩個美標符號，VP，也就是“中”字的“國標符”了。
這樣就產生了一個如何區分國標符與美標符的問題。在一箇中英文混用的文件裏，“VP”到底代表“中”字呢，還是代表某個英文字頭縮寫？電子工業部第六研究所開發CCDOS的時候，使用了一個簡便的解決方案：把國標碼的兩個數字各加上128，上升到非美標碼的位置。（改變後的國標碼，習慣上仍叫“國標”。）
這個方案固然解決了原來的問題，可是新的問題隨之產生。中文文件成了“二進制文件”，既不能可靠地在不同電腦系統間交換，也不與市場上大部分以美標符號爲設計對象的軟件兼容。
爲了區分以上兩種“國標”，我們把原與美標形象碼重合的國標碼稱爲“純國標” ，而把CCDOS加上128的國標碼稱爲“準國標”。
3．GBK碼：
GBK碼是GB碼的擴展字符編碼，對多達2萬多的簡繁漢字進行了編碼，簡體版的Win95和Win98都是使用GBK作系統內碼。
從實際運用來看，微軟自win95簡體中文版開始，系統就採用GBK代碼，它包括了TrueType宋體、黑體兩種GBK字庫（北京中易電子公司提供），可以用於顯示和打印，並提供了四種GBK漢字的輸入法。此外，瀏覽器IE4.0簡體、繁體中文版內部提供了一個GBK-BIG5代碼雙向轉換功能。此外，微軟公司爲IE提供的語言包中，簡體中文支持（Simplified Chinese Language Support Kit）的兩種字庫宋體、黑體，也是GBK漢字（珠海四通電腦排版系統開發公司提供）。其他一些中文字庫生產廠商，也開始提供TrueType或PostScript GBK字庫。
許多外掛式的中文平臺，如南極星、四通利方（Richwin）等，提供GBK碼的支持，包括字庫、輸入法和GBK與其他中文代碼的轉化器。
互聯網方面，許多網站網頁使用GBK代碼。
但是多數搜索引擎都不能很好的支持GBK漢字搜索，大陸地區的搜索引擎有些能不完善的支持GBK漢字檢索。
其實，GBK是又一個漢字編碼標準，全稱《漢字內碼擴展規範》（Chinese Internatial Code Specification），1995年頒佈。GB是國標，K是漢字“擴展”的漢語拼音第一個字母。
GBK向下與GB-2312編碼兼容，向上支持ISO 10646.1國際標準，是前者向後者過渡的一個承啓標準。
GBK規範收錄了ISO 10646.1中的全部CJK漢字和符號，並有所補充。具體包括：GB 2312中的全部漢字、非漢字符號；GB 13000.1中的其他CJK漢字。以上合計20902個GB化漢字；《簡化總表中》未收入GB 13000.1的52個漢字；《康熙字典》以及《辭海》中未被收入GB 13000.1的28個部首及重要構件；13個漢字結構符；BIG-5中未被GB 2312收入、但存在於GB 13000.1的139個圖形符號；GB 12345增補的6個拼音符號；GB 12345增補的19個豎排圖形符號（GB 12345較GB 2312增補豎排標點符號29個，其中10個未被GB 13000.1收入，故GBK亦不收）；從GB 13000.1的CJK兼容區挑選出的21個漢字；GB 13000.1收入的31個IBM OS/2專用符號。GBK亦採用雙字節表示，總體編碼範圍爲0x8140~0xFEFE之間，首字節在0x81~0xFE之間，尾字節在0x40~0xFE之間，剔除0x××7F一條線，總計23940個碼位，共收入21886個漢字和圖形符號，其中漢字（包括部首和構件）21003個，圖形符號883個。
4．BIG5碼：
BIG5碼是針對繁體漢字的漢字編碼，目前在臺灣、香港的電腦系統中得到普遍應用。BIG5碼的編碼範圍參考下文。
5．HZ碼：
HZ碼是在Internet上廣泛使用的一種漢字編碼。“HZ”方案的特點，是以“純國標”的中文與美標碼混用。那麼“HZ”是怎樣區分國標符和美標符的呢？答案其實也很簡單：當一串美標碼中間插入一段國標碼的時候，我們便在國標碼的前面加上~，後面加上~。這些附加碼分別叫“逃出碼”和“逃入碼”。 由於這些附加碼本身也是美標形象碼，整個文件就儼然是一個美標文本文件，可以安然地 在電腦網上傳遞，也和大部分英文文本處理軟件兼容。
6．ISO－2022CJK碼：
ISO-2022是國際標準組織（ISO）爲各種語言字符制定的編碼標準。採用二個字節編碼，其中漢語編碼稱ISO-2022 CN，日語、韓語的編碼分別稱JP、KR。一般將三者合稱CJK碼。目前CJK碼主要在Internet網絡中使用。
7．UCS 和 ISO 10646：
1993年，國際標準ISO10646 定義了通用字符集 (Universal Character Set, UCS)。 UCS 是所有其他字符集標準的一個超集。它保證與其他字符集是雙向兼容的。就是說, 如果你將任何文本字符串翻譯到 UCS格式，然後再翻譯回原編碼, 你不會丟失任何信息。
UCS 包含了用於表達所有已知語言的字符。不僅包括拉丁語，希臘語，斯拉夫語,希伯來語,阿拉伯語,亞美尼亞語和喬治亞語的描述， 還包括中文，日文和韓文這樣的象形文字，以及平假名，片假名，孟加拉語, 旁遮普語果魯穆奇字符(Gurmukhi)， 泰米爾語， 印.埃納德語(Kannada)，Malayalam，泰國語, 老撾語， 漢語拼音(Bopomofo)， Hangul，Devangari，Gujarati， Oriya，Telugu 以及其它語種。對於還沒有加入的語言, 由於正在研究怎樣在計算機中最好地編碼它們， 因而最終它們都將被加入。這些語言包括Tibetian，高棉語，Runic(古代北歐文字)，埃塞俄比亞語， 其他象形文字，以及各種各樣的印-歐語系的語言，還包括挑選出來的藝術語言比如 Tengwar，Cirth 和 克林貢語(Klingon)。UCS 還包括大量的圖形的，印刷用的，數學用的和科學用的符號，包括所有由 TeX，Postscript， MS-DOS，MS-Windows， Macintosh， OCR 字體， 以及許多其他字處理和出版系統提供的字符。
ISO 10646 定義了一個 31 位的字符集。 然而, 在這巨大的編碼空間中, 迄今爲止只分配了前 65534 個碼位 (0x0000 到 0xFFFD)。這個UCS的16位子集稱爲基本多語言面 (Basic Multilingual Plane, BMP)。 將被編碼在16位BMP以外的字符都屬於非常特殊的字符(比如象形文字), 且只有專家在歷史和科學領域裏纔會用到它們。按當前的計劃, 將來也許再也不會有字符被分配到從0x000000到0x10FFFF這個覆蓋了超過100萬個潛在的未來字符的 21 位的編碼空間以外去了。ISO 10646-1標準第一次發表於1993年, 定義了字符集與 BMP 中內容的架構。定義 BMP以外的字符編碼的第二部分 ISO 10646-2 正在準備中, 但也許要過好幾年才能完成。新的字符仍源源不斷地加入到 BMP 中, 但已經存在的字符是穩定的且不會再改變了。
UCS 不僅給每個字符分配一個代碼, 而且賦予了一個正式的名字。表示一個 UCS 或 Unicode 值的十六進制數, 通常在前面加上 “U+”, 就象U+0041 代表字符“拉丁大寫字母A”。UCS字符U+0000到U+007F 與 US-ASCII(ISO 646) 是一致的， U+0000 到 U+00FF 與 ISO 8859-1(Latin-1) 也是一致的。從 U+E000 到 U+F8FF，已經BMP 以外的大範圍的編碼是爲私用保留的。
1993年，ISO10646中定義的USC-4 (Universal Character Set) ，使用了4 個字節的寬度以容納足夠多的相當可觀的空間，但是這個過於肥胖的字符標準在當時乃至現在都有其不現實的一面，就是會過分侵佔存儲空間並影響信息傳輸的效率。 與此同時，Unicode 組織於約 10 年前以 Universal, Unique和Uniform 爲主旨也開始開發一個16位字符標準， 爲避免兩種16位編碼的競爭，1992年兩家組織開始協商，以期折衷尋找共同點，這就是今天的 UCS-2 (BMP，Basic Multilingual Plane，16bit) 和Unicode，但它們仍然是不同的方案。
8．Unicode碼：
關於Unicode我們需要追溯一下它產生的淵源。
當計算機普及到東亞時，遇到了使用表意字符而非字母語言的中、日、韓等國家。在這些國家使用的語言中常用字符多達幾千個，而原來字符采用的是單字節編碼，一張代碼頁中最多容納的字符只有28=256個，對於使用表意字符的語言是在無能爲力。既然一個字節不夠，自然人們就採用兩個字節，所有出現了使用雙字節編碼的字符集(DBCS)。不過雙字節字符集中雖然表意字符使用了兩個字節編碼，但其中的ASCII碼和日文片假名等仍用單字節表示，如此一來給程序員帶來了不小的麻煩，因爲每當設計到DBCS字符串的處理時，總是要判斷當中的一個字節到底表示的是一個字符還是半個字符，如果是半個字符，那是前一半還是後一半？由此可見DBCS並不是一種非常好的解決方案。
人們在不斷尋找這更好的字符編碼方案，最後的結果就是Unicode誕生了。Unicode其實就是寬字節字符集，它對每個字符都固定使用兩個字節即16位表示，於是當處理字符時，不必擔心只處理半個字符。
目前，Unicode在網絡、Windows系統和很多大型軟件中得到應用。
[編輯本段]關於GB編碼的一些常識
GB編碼標準中，比較常用的是GB2312和GBK兩種，GB2312是GBK的一個子集，GB2312編碼範圍是 0xA1A1 - 0xFEFE ，如果純粹的 GB2312編碼，處理起來是什分簡單的，但處理GBK字符集時有些小的提示，先說說GBK編碼的標準吧：
GBK 採用雙字節表示，總體編碼範圍爲 8140-FEFE，首字節在 81-FE 之間，尾字節在 40-FE 之間，剔除 xx7F 一條線。總計 23940 個碼位，共收入 21886 個漢字和圖形符號，其中漢字（包括部首和構件）21003 個，圖形符號 883 個。
全部編碼分爲三大部分：
1. 漢字區。包括：
a. GB 2312 漢字區。即 GBK/2: B0A1-F7FE。收錄 GB 2312 漢字 6763 個，按原順序排列。
b. GB 13000.1 擴充漢字區。包括：
(1) GBK/3: 8140-A0FE。收錄 GB 13000.1 中的 CJK 漢字 6080 個。
(2) GBK/4: AA40-FEA0。收錄 CJK 漢字和增補的漢字 8160 個。
CJK 漢字在前，按 UCS 代碼大小排列；增補的漢字（包括部首和構件）在後，按《康熙字典》的頁碼／字位排列。
2. 圖形符號區。包括：
a. GB 2312 非漢字符號區。即 GBK/1: A1A1-A9FE。其中除 GB 2312 的符號外，
還有 10 個小寫羅馬數字和 GB 12345 增補的符號。計符號 717 個。
b. GB 13000.1 擴充非漢字區。即 GBK/5: A840-A9A0。BIG-5 非漢字符號、結構符和“○”排列在此區。計符號 166 個。
3. 用戶自定義區：分爲(1)(2)(3)三個小區。
(1) AAA1-AFFE，碼位 564 個。
(2) F8A1-FEFE，碼位 658 個。
(3) A140-A7A0，碼位 672 個。
第(3)區儘管對用戶開放，但限制使用，因爲不排除未來在此區域增補新字符的可能性。
這裏有幾個小技巧：
一、在php中，字符編碼是按所發送的編碼爲準的，因些使用的就是用戶輸入的編碼，不會自動改變，但在asp中，默認的編碼是unicode，這樣我們很容易就能得到gbk->unicode的編碼對照表，這樣即使在毫無基礎庫的情況下也能很容易的實現gbk到utf-8的轉換了；
二、由於GBK是高位最低數值是0x40，即是64，因此，有時候組織一些涉及中文的字串時，分割字符最好用64之前的ascii碼，這樣在任意情況下替換或分割都不會出現亂碼，比較常用的是 ","、";"、":"、" "、" "、" "，這些字符永遠都不會給gb編碼添亂。
編碼的種類
編碼(Encoding)在認知上是解釋傳入的刺激的一種基本知覺的過程。技術上來說，這是一個複雜的、多階段的轉換過程，從較爲客觀的感覺輸入（例如光、聲）到主觀上有意義的體驗。
字符編碼(Character encoding)是一套法則，使用該法則能夠對自然語言的字符的一個集合（如字母表或音節表），與其他東西的一個集合（如號碼或電脈衝）進行配對。
文字編碼(Text encoding)使用一種標記語言來標記一篇文字的結構和其他特徵，以方便計算機進行處理。
語義編碼(Semantics encoding)，以正式語言乙對正式語言甲進行語義編碼，即是使用語言乙表達語言甲所有的詞彙（如程序或說明）的一種方法。
電子編碼(Electronic encoding)是將一個信號轉換成爲一個代碼，這種代碼是被優化過的以利於傳輸或存儲。轉換工作通常由一個編解碼器完成。
神經編碼(Neural encoding)是指信息在神經元中被如何描繪的方法。
記憶編碼(Memory encoding)是把感覺轉換成記憶的過程。
加密(Encryption)是爲了保密而對信息進行轉換的過程。
譯碼(Transcoding)是將編碼從一種格式轉換到另一種格式的過程。[1]
UTF編碼：
是Unicode Text Format的縮寫，意爲Unicode文本格式。根據Unicode的編碼可以生成UTF編碼，轉換規則如下：
(1)首先將Unicode的編碼轉換成二進制形式，這樣一個字符對應一個16位的二進制數。
(2)如果Unicode的16位二進制編碼的頭9位都是0，則用一個字節表示該字符，這個字節的首位是“0”，剩下的7位與原編碼中的後7位相同。例如“/u0034”(0000 0000 0011 0100)，用“34” (0011 0100)表示(與原Unicode編碼是相同的，只是去掉了原編碼的首字節)；
(3)如果Unicode的16位二進制編碼的頭5位都是0，則用兩個字節表示該字符，首字節以“110”開頭，該字節後面的5位與源編碼中頭5個零後面的5位相同；第二個字節以“10”開頭，後面的六位則與源編碼中剩下的6位相同。例如“/u025d”(0000 0010 0101 1101)，轉化後爲“c99d”(1100 1001 1001 1101)；
(4)如果Unicode的16位二進制編碼不符合上述兩個規則，則用三個字節表示該字符。第一個字節以“1110”開頭，後四位與源編碼的頭4位相同；第二個字節以“10”開頭，後六位與原編碼接下來的6位相同；第三個字節也以“10”開頭，後六位與原編碼剩下的6位相同，這樣原來16位的編碼就轉換成三個字節24位的編碼了；例如“/u9da7”(1001 1101 1010 0111)，轉化爲“e9b6a7”(1110 1001 1011 0110 1010 0111)。
設計UTF-8的理由
UTF-8的設計有以下的多字符組序列的特質：
單字節字符的最高有效位元永遠爲0。
多字節序列中的首個字符組的幾個最高有效位元決定了序列的長度。最高有效位爲110的是2字節序列，而1110的是三字節序列，如此類推。
多字節序列中其餘的字節中的首兩個最高有效位元爲10。
UTF-8的這些特質，保證了一個字符的字節序列不會包含在另一個字符的字節序列中。這確保了以字節爲基礎的部份字串比對（sub-string match）方法可以適用於在文字中搜尋字或詞。有些比較舊的可變長度8位元編碼（如Shift JIS）沒有這個特質，故字串比對的算法變得相當複雜。雖然這增加了UTF-8編碼的字串的信息冗餘，但是利多於弊。另外，資料壓縮並非Unicode 的目的，所以不可混爲一談。即使在傳送過程中有部份字節因錯誤或干擾而完全遺失，還是有可能在下一個字符的起點重新同步，令受損範圍受到限制。
另一方面，由於其字節序列設計，如果一個疑似爲字符串的序列被驗證爲UTF-8編碼，那麼我們可以有把握地說它是UTF-8字符串。一段兩字節隨機序列碰巧爲合法的UTF-8而非ASCII 的機率爲32分1。對於三字節序列的機率爲256分3，對更長的序列的機率就更低了。
優點
UTF-8是ASCII的一個超集。因爲一個純ASCII字符串也是一個合法的UTF-8字符串，所以現存的ASCII文本不需要轉換。爲傳統的擴展ASCII字符集設計的軟件通常可以不經修改或很少修改就能與UTF-8一起使用。
使用標準的面向字節的排序例程對UTF-8排序將產生與基於Unicode代碼點排序相同的結果。（儘管這隻有有限的有用性，因爲在任何特定語言或文化下都不太可能有仍可接受的文字排列順序。）
UTF-8和UTF-16都是可擴展標記語言文檔的標準編碼。所有其它編碼都必須通過顯式或文本聲明來指定。[2]
任何面向字節的字符串搜索算法都可以用於UTF-8的數據（只要輸入僅由完整的UTF-8字符組成）。但是，對於包含字符記數的正則表達式或其它結構必須小心。
UTF-8字符串可以由一個簡單的算法可靠地識別出來。就是，一個字符串在任何其它編碼中表現爲合法的UTF-8的可能性很低，並隨字符串長度增長而減小。舉例說，字符值C0,C1,F5至FF從來沒有出現。爲了更好的可靠性，可以使用正則表達式來統計非法過長和替代值（可以查看W3 FAQ: Multilingual Forms上的驗證UTF-8字符串的正則表達式）。
缺點
一份寫得很差（並且與當前標準的版本不兼容）的UTF-8解析器可能會接受一些不同的僞UTF-8表示並將它們轉換到相同的Unicode輸出上。這爲設計用於處理八位表示的校驗例程提供了一種遺漏信息的方式。
[編輯] 使用UTF-8的原因
ASCII轉換成UCS-2，在編碼前插入一個0x0。用這些編碼，會含括一些控制符，比如 " 或 '/'，這在UNIX和一些C函數中，將會產生嚴重錯誤。因此可以肯定，UCS-2不適合作爲Unicode的外部編碼，也因此誕生了UTF-8。
1992年初，爲建立良好的字節串編碼系統（byte-stream encoding）以供多字節字符集（multi-byte character sets）使用，開始了一個正式的研究。ISO/IEC 10646的初稿中有一個非必須的附錄，名爲UTF。當中包含了一個供32位元的字符使用的字節串編碼系統。這個編碼方式的性能並不令人滿意，但它提出了將0-127的範圍保留給ASCII以相容舊系統的概念。
1992年7月，X/Open委員會XoJIG開始尋求一個較佳的編碼系統。Unix系統實驗室（UNIX System Laboratories, USL）的Dave Prosser爲此提出了一個編碼系統的建議。它具備可更快速實作的特性，並引入一項新的改進。其中，7位元的ASCII符號只代表原來的意思，所有多字節序列則會包含第8位元的符號，也就是所謂的最高有效位元（Most significant bit）。
1992年8月，這個建議由IBMX/Open的代表流傳到一些感興趣的團體。與此同時，貝爾實驗室Plan 9操作系統工作小組的肯·湯普遜對這編碼系統作出重大的修改，讓編碼可以自我同步（self-synchronizing），使得不必從字串的開首讀取，也能找出字符間的分界。1992年9月2日，肯·湯普遜和Rob Pike一起在美國新澤西州一架餐車的餐桌墊上描繪出此設計的要點。接下來的日子，Pike及湯普遜將它實現，並將這編碼系統完全應用在Plan 9當中，及後他將有關成果回饋X/Open。
1993年1月25-29日的在聖地牙哥舉行的USENIX會議首次正式介紹UTF-8。
自1996年起，微軟的CAB（MS Cabinet）規格在UTF-8標準正式落實前就明確容許在任何地方使用UTF-8編碼系統。但有關的編碼器實際上從來沒有實作這方面的規格。
使用UTF-8編碼唯一的好處是，國外的用戶如果使用Windows XP英文版，瀏覽UTF-8編碼的任何網頁，無論是中文、還是日文、韓文、阿拉伯文，都可以正常顯示，UTF-8是世界通用的語言編碼，UTF-8的推廣要歸功於Google的應用，以及Blog開發者。而如果用Windows XP英文版的IE6.0瀏覽gb2312語言編碼的網頁，則會提示是否安裝語言包。因此，可能會失去很多的國外瀏覽者。
使用gb2312編碼的好處是，因爲程序產生的網頁文本使用ANSI編碼格式，會比UTF-8文本編碼節省一些體積，訪問速度會稍微快一點點，大約是30:38的比例，也就是30K的ANSI編碼，轉爲UTF-8編碼是38K，當然，這個比例並不準確，是會隨Unicode字符集區域的不同而變化的。
UTF-8（8 位元 Universal Character Set／Unicode Transformation Format）是一種針對 Unicode 的可變長度字符編碼。它可以用來表示 Unicode 標準中的任何字符，且其編碼中的第一個字節仍與 ASCII 相容，這使得原來處理 ASCII 字符的軟件無須或只須做少部份修改，即可繼續使用。因此，它逐漸成爲電子郵件、網頁及其他儲存或傳送文字的應用中，優先採用的編碼。
UTF-8 使用一至四個字節爲每個字符編碼：
128 個 US-ASCII 字符只需一個字節編碼（Unicode 範圍由 U+0000 至 U+007F）。
帶有附加符號的拉丁文、希臘文、西裏爾字母、亞美尼亞語、希伯來文、阿拉伯文、敘利亞文及它拿字母則需要二個字節編碼（Unicode 範圍由 U+0080 至 U+07FF）。
其他基本多文種平面（BMP）中的字符（這包含了大部分常用字）使用三個字節編碼。
其他極少使用的 Unicode 輔助平面的字符使用四字節編碼。
對上述提及的第四種字符而言，UTF-8 使用四個字節來編碼似乎太耗費資源了。但 UTF-8 對所有常用的字符都可以用三個字節表示，而且它的另一種選擇，UTF-16編碼，對前述的第四種字符同樣需要四個字節來編碼，所以要決定 UTF-8 或 UTF-16 哪種編碼比較有效率，還要視所使用的字符的分佈範圍而定。不過，如果使用一些傳統的壓縮系統，比如 DEFLATE，則這些不同編碼系統間的的差異就變得微不足道了。若顧及傳統壓縮算法在壓縮較短文字上的效果不大，可以考慮使用 Standard Compression Scheme for Unicode（SCSU）。
互聯網工程工作小組（IETF）要求所有互聯網協議都必須支援 UTF-8 編碼。[1] 互聯網郵件聯盟（IMC）建議所有電子郵件軟件都支援 UTF-8編碼。所有主要的電子郵件軟件中，只有 Eudora 不支援 UTF-8 編碼。[1]
