UTF-8 - 維基百科，自由的百科全書 - Wikipedia

UTF-8（8-bit Unicode Transformation Format）是一種針對Unicode的可變長度字元編碼，也是一種字首碼。

它可以用一至四個位元組對Unicode字元集中的所有有效編碼點進行 ... UTF-8 統一碼編碼不同的字節倍數 語言 監視 編輯 此條目需要補充更多來源。

(2018年12月27日)請協助補充多方面可靠來源以改善這篇條目，無法查證的內容可能會因為異議提出而移除。

致使用者：請搜尋一下條目的標題（來源搜尋："UTF-8"—網頁、新聞、書籍、學術、圖像），以檢查網路上是否存在該主題的更多可靠來源（判定指引）。

此條目翻譯品質不佳。

翻譯者可能不熟悉中文或原文語言，也可能使用了機器翻譯。

請協助翻譯本條目或重新編寫，並注意避免翻譯腔的問題。

明顯拙劣的翻譯請改掛{{d|G13}}提交刪除。

UTF-8（8-bitUnicodeTransformationFormat）是一種針對Unicode的可變長度字元編碼，也是一種字首碼。

它可以用一至四個位元組對Unicode字元集中的所有有效編碼點進行編碼，屬於Unicode標準的一部分，最初由肯·湯普遜和羅布·派克提出。

[2][3]由於較小值的編碼點一般使用頻率較高，直接使用Unicode編碼效率低下，大量浪費記憶體空間。

UTF-8就是為了解決向下相容ASCII碼而設計，Unicode中前128個字元，使用與ASCII碼相同的二進位值的單個位元組進行編碼，而且字面與ASCII碼的字面一一對應，這使得原來處理ASCII字元的軟體無須或只須做少部份修改，即可繼續使用。

因此，它逐漸成為電子郵件、網頁及其他儲存或傳送文字優先採用的編碼方式。

UTF-8語言國際標準Unicode分類EASCII變長編碼（英語：variable-widthencoding）Unicode轉換格式拓展自US-ASCII變換/編碼ISO10646(Unicode)前用UTF-1閱論編顯示了Google所記錄的2001年至2012年主要編碼方法的使用情況，[1]2008年，UTF-8的使用率超過所有其他編碼方式，在2012年超過所有網頁的60％。

其中ASCIIonly曲線包括所有僅包含ASCII字元的網頁，無論元資料中聲明如何。

自2009年以來，UTF-8一直是全球資訊網的最主要的編碼形式（對所有，而不僅是Unicode範圍內的編碼）（並由WHATWG宣布為強制性的「適用於所有事物(forallthings)」，[4]截止到2019年11月，在所有網頁中，UTF-8編碼應用率高達94.3%（其中一些僅是ASCII編碼，因為它是UTF-8的子集），而在排名最高的1000個網頁中占96％。

[5]第二熱門的多位元組編碼方式ShiftJIS和GB2312分別具有0.3％和0.2％的占有率。

[6][7][1]Internet郵件聯盟（InternetMailConsortium,IMC）建議所有電子郵件程式都能夠使用UTF-8展示和建立郵件，[8]W3C建議UTF-8作為XML檔案和HTML檔案的預設編碼方式。

[9]網際網路工程工作小組（IETF）要求所有網際網路協定都必須支援UTF-8編碼[10]。

網際網路郵件聯盟（IMC）建議所有電子郵件軟體都支援UTF-8編碼。

[11] 目次 1歷史 2結構 3描述 4UTF-8編碼字節含義 5設計UTF-8的理由 6UTF-8的編碼方式 7UTF-8的特性 8UTF-8編碼的優點 9UTF-8編碼的缺點 9.1編寫不良的解析器 9.2不利於正則表達式檢索 9.3其他 10UTF-8的衍生物 10.1Windows 10.2Posix系統 10.3Java 10.3.1變種UTF-8 10.4MacOSX 10.5MySQL 11參閱 12參考文獻 13外部連結 13.1由統一碼聯盟出版的書 歷史編輯 1992年初，為建立良好的位元組串編碼系統以供多位元組字元集使用，開始了一個正式的研究。

ISO/IEC10646的初稿中有一個非必須的附錄，名為UTF。

當中包含了一個供32位元的字元使用的位元組串編碼系統。

這個編碼方式的效能並不令人滿意，但它提出了將0-127的範圍保留給ASCII以相容舊系統的概念。

1992年7月，X/Open委員會XoJIG開始尋求一個較佳的編碼系統。

Unix系統實驗室（USL）的DaveProsser為此提出了一個編碼系統的建議。

它具備可更快速實作的特性，並引入一項新的改進。

其中，7位元的ASCII符號只代表原來的意思，所有多位元組序列則會包含第8位元的符號，也就是所謂的最高有效位元。

1992年8月，這個建議由IBMX/Open的代表流傳到一些感興趣的團體。

與此同時，貝爾實驗室九號計畫作業系統工作小組的肯·湯普遜對這編碼系統作出重大的修改，讓編碼可以自我同步，使得不必從字串的開首讀取，也能找出字元間的分界。

1992年9月2日，肯·湯普遜和羅勃·派克一起在美國新澤西州一架餐車的餐桌墊上描繪出此設計的要點。

接下來的日子，Pike及湯普遜將它實現，並將這編碼系統完全應用在九號計畫當中，及後他將有關成果回饋X/Open。

1993年1月25-29日的在聖地牙哥舉行的USENIX會議首次正式介紹UTF-8。

自1996年起，微軟的CAB（MSCabinet）規格在UTF-8標準正式落實前就明確容許在任何地方使用UTF-8編碼系統。

但有關的編碼器實際上從來沒有實作這方面的規格。

結構編輯 UTF-8使用一至六個位元組為每個字元編碼（儘管如此，2003年11月UTF-8被RFC3629重新規範，只能使用原來Unicode定義的區域，U+0000到U+10FFFF，也就是說最多四個位元組）： 128個US-ASCII字元只需一個位元組編碼（Unicode範圍由U+0000至U+007F）。

帶有附加符號的拉丁文、希臘文、西里爾字母、亞美尼亞語、希伯來文、阿拉伯文、敘利亞文及它拿字母則需要兩個位元組編碼（Unicode範圍由U+0080至U+07FF）。

其他基本多文種平面（BMP）中的字元（這包含了大部分常用字，如大部分的漢字）使用三個位元組編碼（Unicode範圍由U+0800至U+FFFF）。

其他極少使用的Unicode輔助平面的字元使用四至六位元組編碼（Unicode範圍由U+10000至U+1FFFFF使用四位元組，Unicode範圍由U+200000至U+3FFFFFF使用五位元組，Unicode範圍由U+4000000至U+7FFFFFFF使用六位元組）。

對上述提及的第四種字元而言，UTF-8使用四至六個位元組來編碼似乎太耗費資源了。

但UTF-8對所有常用的字元都可以用三個位元組表示，而且它的另一種選擇，UTF-16編碼，對前述的第四種字元同樣需要四個位元組來編碼，所以要決定UTF-8或UTF-16哪種編碼比較有效率，還要視所使用的字元的分佈範圍而定。

不過，如果使用一些傳統的壓縮系統，比如DEFLATE，則這些不同編碼系統間的的差異就變得微不足道了。

若顧及傳統壓縮演算法在壓縮較短文字上的效果不大，可以考慮使用Unicode標準壓縮格式（SCSU）。

描述編輯  Unicode與UTF-8的轉換 目前有好幾份關於UTF-8詳細規格的檔案，但這些檔案在定義上有些許的不同： RFC3629/STD63（2003），這份檔案制定了UTF-8是標準的網際網路協定元素 第四版，TheUnicodeStandard，§3.9－§3.10（2003） ISO/IEC10646-1:2000附加檔案D（2000）它們取代了以下那些被淘汰的定義： ISO/IEC10646-1:1993修正案2／附加檔案R（1996） 第二版，TheUnicodeStandard，附錄A（1996） RFC2044（1996） RFC2279（1998） 第三版，TheUnicodeStandard，§2.3（2000）及勘誤表#1：UTF-8ShortestForm（2000） UnicodeStandard附加檔案#27:Unicode3.1（2001）事實上，所有定義的基本原理都是相同的，它們之間最主要的不同是支援的字元範圍及無效輸入的處理方法。

Unicode字元的位元被分割為數個部分，並分配到UTF-8的位元組串中較低的位元的位置。

在U+0080的以下字元都使用內含其字元的單位元組編碼。

這些編碼正好對應7位元的ASCII字元。

在其他情況，有可能需要多達4個字元組來表示一個字元。

這些多位元組的最高有效位元會設定成1，以防止與7位元的ASCII字元混淆，並保持標準的位元組主導字串運作順利。

代碼範圍十六進制 標量值（scalarvalue）二進制 UTF-8二進制／十六進制 註釋 000000-00007F128個代碼 00000000000000000zzzzzzz 0zzzzzzz（00-7F） ASCII字元範圍，位元組由零開始 七個z 七個z 000080-0007FF1920個代碼 0000000000000yyyyyzzzzzz 110yyyyy（C0-DF）10zzzzzz（80-BF） 第一個位元組由110開始，接著的位元組由10開始 三個y；二個y；六個z 五個y；六個z 000800-00D7FF00E000-00FFFF61440個代碼[Note1] 00000000xxxxyyyyyyzzzzzz 1110xxxx（E0-EF）10yyyyyy10zzzzzz 第一個位元組由1110開始，接著的位元組由10開始 四個x；四個y；二個y；六個z 四個x；六個y；六個z 010000-10FFFF1048576個代碼 000wwwxxxxxxyyyyyyzzzzzz 11110www（F0-F7）10xxxxxx10yyyyyy10zzzzzz 將由11110開始，接著的位元組由10開始 三個w；二個x；四個x；四個y；二個y；六個z 三個w；六個x；六個y；六個z Note1Unicode在範圍D800-DFFF中不存在任何字元，基本多文種平面中約定了這個範圍用於UTF-16擴展標識輔助平面（兩個UTF-16表示一個輔助平面字元）。

當然，任何編碼都是可以被轉換到這個範圍，但在unicode中他們並不代表任何合法的值。

例如，希伯來語字母aleph（א）的Unicode代碼是U+05D0，按照以下方法改成UTF-8： 它屬於U+0080到U+07FF區域，這個表說明它使用雙位元組，110yyyyy10zzzzzz. 十六進位的0x05D0換算成二進位就是101-1101-0000. 這11位數按順序放入"y"部分和"z"部分：1101011110010000. 最後結果就是雙位元組，用十六進位寫起來就是0xD70x90，這就是這個字元aleph（א）的UTF-8編碼。

所以開始的128個字元（US-ASCII）只需一位元組，接下來的1920個字元需要雙位元組編碼，包括帶附加符號的拉丁字母，希臘字母，西里爾字母，科普特語字母，亞美尼亞語字母，希伯來文字母和阿拉伯字母的字元。

基本多文種平面中其餘的字元使用三個位元組，剩餘字元使用四個位元組。

根據這種方式可以處理更大數量的字元。

原來的規範允許長達6位元組的序列，可以覆蓋到31位元（通用字元集原來的極限）。

儘管如此，2003年11月UTF-8被RFC 3629重新規範，只能使用原來Unicode定義的區域，U+0000到U+10FFFF。

根據這些規範，以下位元組值將無法出現在合法UTF-8序列中： 編碼（二進位） 編碼（十六進位） 注釋 1100000x C0,C1 過長編碼：雙位元組序列的頭位元組，但碼點<=127 1111111x FE,FF 無法達到：7或8位元組序列的頭位元組 111110xx1111110x F8,F9,FA,FB,FC,FD 被RFC3629規範：5或6位元組序列的頭位元組 111101011111011x F5,F6,F7 被RFC3629規範：碼點超過10FFFF的頭位元組 UTF-8編碼位元組含義編輯 對於UTF-8編碼中的任意位元組B，如果B的第一位為0，則B獨立的表示一個字元(ASCII碼)； 如果B的第一位為1，第二位為0，則B為一個多位元組字元中的一個位元組(非ASCII字元)； 如果B的前兩位為1，第三位為0，則B為兩個位元組表示的字元中的第一個位元組； 如果B的前三位為1，第四位為0，則B為三個位元組表示的字元中的第一個位元組； 如果B的前四位為1，第五位為0，則B為四個位元組表示的字元中的第一個位元組；因此，對UTF-8編碼中的任意位元組，根據第一位，可判斷是否為ASCII字元；根據前二位，可判斷該位元組是否為一個字元編碼的第一個位元組；根據前四位（如果前兩位均為1），可確定該位元組為字元編碼的第一個位元組，並且可判斷對應的字元由幾個位元組表示；根據前五位（如果前四位為1），可判斷編碼是否有錯誤或資料傳輸過程中是否有錯誤。

設計UTF-8的理由編輯 UTF-8的設計有以下的多字元組序列的特質： 單位元組字元的最高有效位元永遠為0。

多位元組序列中的首個字元組的幾個最高有效位元決定了序列的長度。

最高有效位為110的是2位元組序列，而1110的是三位元組序列，如此類推。

多位元組序列中其餘的位元組中的首兩個最高有效位元為10。

UTF-8的這些特質，保證了一個字元的位元組序列不會包含在另一個字元的位元組序列中。

這確保了以位元組為基礎的部份字串比對（sub-stringmatch）方法可以適用於在文字中搜尋字或詞。

有些比較舊的可變長度8位元編碼（如ShiftJIS）沒有這個特質，故字串比對的演算法變得相當複雜。

雖然這增加了UTF-8編碼的字串的資訊冗餘，但是利多於弊。

另外，資料壓縮並非Unicode的目的，所以不可混為一談。

即使在傳送過程中有部份位元組因錯誤或干擾而完全遺失，還是有可能在下一個字元的起點重新同步，令受損範圍受到限制。

另一方面，由於其位元組序列設計，如果一個疑似為字串的序列被驗證為UTF-8編碼，那麼我們可以有把握地說它是UTF-8字串。

一段兩位元組隨機序列碰巧為合法的UTF-8而非ASCII的機率為32分1。

對於三位元組序列的機率為256分1，對更長的序列的機率就更低了。

UTF-8的編碼方式編輯 UTF-8是UNICODE的一種變長度的編碼表達方式〈一般UNICODE為雙位元組（指UCS2）〉，它由肯·湯普遜（KenThompson）於1992年建立，現在已經標準化為RFC3629。

UTF-8就是以8位元為單元對UCS進行編碼，而UTF-8不使用大尾序和小尾序的形式，每個使用UTF-8儲存的字元，除了第一個位元組外，其餘位元組的頭兩個位元都是以"10"開始，使文字處理器能夠較快地找出每個字元的開始位置。

但為了與以前的ASCII碼相容（ASCII為一個位元組），因此UTF-8選擇了使用可變長度位元組來儲存Unicode： （注意：不論是Unicode(Table3.7)[12]，還是ISO10646(10.2UTF-8)[13]，目前都只規定了最高碼位是0x10FFFF的字元的編碼。

下表中表示大於0x10FFFF的UTF-8編碼是不符合標準的。

） Unicode和UTF-8之間的轉換關係表(x字元表示碼點占據的位) 碼點的位數 碼點起值 碼點終值 位元組序列 Byte1 Byte2 Byte3 Byte4 Byte5 Byte6   7 U+0000 U+007F 1 0xxxxxxx 11 U+0080 U+07FF 2 110xxxxx 10xxxxxx 16 U+0800 U+FFFF 3 1110xxxx 10xxxxxx 10xxxxxx 21 U+10000 U+1FFFFF 4 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 26 U+200000 U+3FFFFFF 5 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 31 U+4000000 U+7FFFFFFF 6 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 在ASCII碼的範圍，用一個位元組表示，超出ASCII碼的範圍就用位元組表示，這就形成了我們上面看到的UTF-8的表示方法，這樣的好處是當UNICODE檔案中只有ASCII碼時，儲存的檔案都為一個位元組，所以就是普通的ASCII檔案無異，讀取的時候也是如此，所以能與以前的ASCII檔案相容。

大於ASCII碼的，就會由上面的第一位元組的前幾位表示該unicode字元的長度，比如110xxxxx前三位的二進位表示告訴我們這是個2BYTE的UNICODE字元；1110xxxx是個三位的UNICODE字元，依此類推；xxx的位置由字元編碼數的二進製表示的位填入。

越靠右的x具有越少的特殊意義。

只用最短的那個足夠表達一個字元編碼數的多位元組串。

注意在多位元組串中，第一個位元組的開頭"1"的數目就是整個串中位元組的數目。

ASCII字母繼續使用1位元組儲存，重音文字、希臘字母或西里爾字母等使用2位元組來儲存，而常用的漢字就要使用3位元組。

輔助平面字元則使用4位元組。

在UTF-8+BOM格式檔案的開首，很多時都放置一個U+FEFF字元（UTF-8以EF,BB,BF代表），以顯示這個文字檔案是以UTF-8編碼。

UTF-8的特性編輯 UTF-8圖表說明 UTF-8 最小碼位 0000 最大碼位 10FFFF 每位元組所占位數 8bits Byteorder N/A 每個字元最小位元組數 1 每個字元最大位元組數 4 UCS字元U+0000到U+007F（ASCII）被編碼為位元組0x00到0x7F（ASCII相容），這也意味著只包含7位ASCII字元的檔案在ASCII和UTF-8兩種編碼方式下是一樣的。

所有>U+007F的UCS字元被編碼為一個多個位元組的串，每個位元組都有標記位集。

因此，ASCII位元組（0x00-0x7F）不可能作為任何其他字元的一部分。

表示非ASCII字元的多位元組串的第一個位元組總是在0xC0到0xFD的範圍裡，並指出這個字元包含多少個位元組。

多位元組串的其餘位元組都在0x80到0xBF範圍裡，這使得重新同步非常容易，並使編碼無國界，且很少受丟失位元組的影響。

可以編入所有可能的231個UCS代碼 UTF-8編碼字元理論上可以最多到6個位元組長，然而16位元BMP字元最多只用到3位元組長。

BigendianUCS-4位元組串的排列順序是預定的。

位元組0xFE和0xFF在UTF-8編碼中從未用到，同時，UTF-8以位元組為編碼單元，它的位元組順序在所有系統中都是一様的，沒有位元組序的問題，也因此它實際上並不需要BOM。

與UTF-16或其他Unicode編碼相比，對於不支援Unicode和XML的系統，UTF-8更不容易造成問題。

UTF-8編碼的優點編輯 總體來說，在Unicode字串中不可能由碼點數量決定顯示它所需要的長度，或者顯示字串之後在文字緩衝區中游標應該放置的位置；組合字元、變寬字型、不可列印字元和從右至左的文字都是其歸因。

所以儘管在UTF-8字串中字元數量與碼點數量的關係比UTF-32更為複雜，在實際中很少會遇到有不同的情形。

更詳細的說，UTF-8編碼具有以下幾點優點： ASCII是UTF-8的一個子集。

因為一個純ASCII字串也是一個合法的UTF-8字串，所以現存的ASCII文字不需要轉換。

為傳統的擴充ASCII字元集設計的軟體通常可以不經修改或很少修改就能與UTF-8一起使用。

使用標準的面向位元組的排序常式對UTF-8排序將產生與基於Unicode代碼點排序相同的結果。

（儘管這只有有限的有用性，因為在任何特定語言或文化下都不太可能有仍可接受的文字排列順序。

） UTF-8和UTF-16都是可延伸標記式語言文件的標準編碼。

所有其它編碼都必須通過顯式或文字聲明來指定。

[1]（頁面存檔備份，存於網際網路檔案館） 任何面向位元組的字串搜尋演算法都可以用於UTF-8的資料（只要輸入僅由完整的UTF-8字元組成）。

但是，對於包含字元記數的正規表示式或其它結構必須小心。

UTF-8字串可以由一個簡單的演算法可靠地辨識出來。

就是，一個字串在任何其它編碼中表現為合法的UTF-8的可能性很低，並隨字串長度增長而減小。

舉例說，字元值C0,C1,F5至FF從來沒有出現。

為了更好的可靠性，可以使用正規表示式來統計非法過長和替代值（可以檢視W3FAQ:MultilingualForms（頁面存檔備份，存於網際網路檔案館）上的驗證UTF-8字串的正規表示式）。

與UCS-2的比較：ASCII轉換成UCS-2，在編碼前插入一個0x0。

用這些編碼，會含括一些控制符，比如"或'/'，這在UNIX和一些C函式中，將會產生嚴重錯誤。

因此可以肯定，UCS-2不適合作為Unicode的外部編碼，也因此誕生了UTF-8。

UTF-8編碼的缺點編輯 編寫不良的解析器編輯 一份寫得很差（並且與當前標準的版本不相容）的UTF-8解析器可能會接受一些不同的偽UTF-8表示並將它們轉換到相同的Unicode輸出上。

這為設計用於處理八位表示的校驗常式提供了一種遺漏資訊的方式。

不利於正規表示式檢索編輯 正規表示式可以進行很多英文進階的模糊檢索。

例如，[a-h]表示a到h間所有字母。

同樣GBK編碼的中文也可以這樣利用正規表示式，比如在只知道一個字的讀音而不知道怎麼寫的情況下，也可用正規表示式檢索，因為GBK編碼是按讀音排序的。

但是UTF-8不是按讀音排序的，所以不利於用正規表示式檢索（雖然正規表示式檢索並未考慮中文中的多音字，但是由於中文的多音字數量不多，不少多音字還是同音不同調類型的多音字，所以大多數情況下正規表示式檢索是可以接受的）。

但是，Unicode是按部首排序的，因此在只知道一個字的部首而不知道如何發音的情況下，UTF-8可用正規表示式檢索而GBK不行。

其他編輯 與其他Unicode編碼相比，特別是UTF-16，在UTF-8中ASCII字元佔用的空間只有一半，可是在一些字元的UTF-8編碼佔用的空間就要多出1/3，特別是中文、日文和韓文（CJK）這樣的方塊文字。

UTF-8的衍生物編輯 Windows編輯 雖然不是標準，但許多Windows程式（包括Windows記事本）在UTF-8編碼的檔案的開首加入一段位元組串EFBBBF。

這是位元組順序記號U+FEFF的UTF-8編碼結果。

對於沒有預期要處理UTF-8的文字編輯器和瀏覽器會顯示成ISO-8859-1字串。

Posix系統編輯 Posix系統明確不建議使用位元組序遮罩EFBBBF。

[14]因為很多文字檔案期望以「#!」（Shebang）開頭指示要執行的程式。

Linux系統選擇使用Unicode規範形式NormalizationFormC（NFC），即優先使用預組裝字元（precomposedcharacter）而非組合字元序列（combiningcharactersequence）。

2002年9月發布的RedHatLinux8.0才開始正式把大多數區域設定的預設編碼設為UTF-8。

此前是各種語言的但位元組編碼為主。

2004年9月SuSELinux9.1開始，預設編碼遷移為UTF-8。

字串處理時，使用UTF-8或locale依賴的多位元組編碼情形，比使用C語言wchar_t的寬字元固定寬度編碼，要慢1至2個數量級。

[14] Java編輯 在通常用法下，Java程式語言在通過InputStreamReader和OutputStreamWriter讀取和寫入串的時候支援標準UTF-8。

但是，Java也支援一種非標準的變體UTF-8，供物件的序列化，Java本地介面和在class檔案中的嵌入常數時使用的modifiedUTF-8。

變種UTF-8編輯 標準和變種的UTF-8有兩個不同點。

第一，空字元（nullcharacter，U+0000）使用雙位元組的0xc00x80，而不是單位元組的0x00。

這保證了在已編碼字串中沒有嵌入空位元組。

因為C語言等語言程式中，單位元組空字元是用來標誌字串結尾的。

當已編碼字串放到這樣的語言中處理，一個嵌入的空字元將把字串一刀兩斷。

第二個不同點是基本多文種平面之外字元的編碼的方法。

在標準UTF-8中，這些字元使用4位元組形式編碼，而在修正的UTF-8中，這些字元和UTF-16一樣首先表示為代理對（surrogatepairs），然後再像CESU-8那樣按照代理對分別編碼。

這樣修正的原因更是微妙。

Java中的字元為16位元長，因此一些Unicode字元需要兩個Java字元來表示。

語言的這個性質蓋過了Unicode的增補平面的要求。

儘管如此，為了要保持良好的向下相容、要改變也不容易了。

這個修正的編碼系統保證了一個已編碼字串可以一次編為一個UTF-16碼，而不是一次一個Unicode碼點。

不幸的是，這也意味著UTF-8中需要4位元組的字元在變種UTF-8中變成需要6位元組。

因為變種UTF-8並不是UTF-8，所以使用者在交換資訊和使用網際網路的時候需要特別注意不要誤把變種UTF-8當成UTF-8資料。

MacOSX編輯 參見：統一碼等價性 MacOSX作業系統使用正式分解萬國碼（canonicallydecomposedUnicode），在檔案系統中使用UTF-8編碼進行檔案命名，這做法通常被稱為UTF-8-MAC。

正式分解萬國碼中，預組合字元是被禁止使用的，必須以組合字元取代。

這種方法使分類變得非常簡單，但是會搞混那些使用預組合字元為標準、組合字元用來顯示特殊字元的軟體。

Mac系統的這種NFD資料是萬國碼規格化（Unicodenormalization）的一種格式。

而其他系統，包括Windows和Linux，使用萬國碼規範的NFC形式，也是W3C標準使用的形式。

所以通常NFD資料必須轉換成NFC才能被其他平台或者網路使用。

蘋果開發者專區有關於此問題的討論：AppleQ&A1173（頁面存檔備份，存於網際網路檔案館）。

MySQL編輯 MySQL字元編碼集中有兩套UTF-8編碼實現：「utf8」和「utf8mb4」，其中「utf8」是一個字最多占據3位元組空間的編碼實現；而「utf8mb4」則是一個字最多占據4位元組空間的編碼實現，也就是UTF-8的完整實現。

這是由於MySQL在4.1版本開始支援UTF-8編碼（當時參考UTF-8草案版本為RFC 2279）時，為2003年，並且在同年9月限制了其實現的UTF-8編碼的空間占用最多為3位元組，而UTF-8正式形成標準化文件（RFC 3629）是其之後。

限制UTF-8編碼實現的編碼空間占用一般被認為是考慮到資料庫檔案設計的相容性和讀取最佳化，但實際上並沒有達到目的，而且在UTF-8編碼開始出現需要存入非基本多文種平面的Unicode字元（例如emoji字元）時導致無法存入（由於3位元組的實現只能存入基本多文種平面內的字元）。

直到2010年在5.5版本推出「utf8mb4」來代替、「utf8」重新命名為「utf8mb3」並調整「utf8」為「utf8mb3」的別名，並不建議使用舊「utf8」編碼，以此修正遺留問題。

[15][16][17][18] 參閱編輯 Alt碼 ASCII 位元組順序記號 Comparisonofemailclients#Features ComparisonofUnicodeencodings CharacterencodingsinHTML ISO/IEC8859 GB18030 iconv Unicodeande-mail UnicodeandHTML 通用字元集 UTF-16 UTF-9和UTF-18 寬字元 參考文獻編輯 ^1.01.1Davis,Mark.Unicodeover60percentoftheweb.OfficialGoogleBlog.2012-02-03[2019-11-23].（原始內容存檔於2018-08-09）.  ^Pike,Rob.UTF-8history.2003-04-30[2019-11-23].（原始內容存檔於2006-10-29）....UTF-8wasdesigned,infrontofmyeyes,onaplacematinaNewJerseydineronenightinSeptemberorso1992...SothatnightKenwrotepackingandunpackingcodeandIstartedtearingintotheCandgraphicslibraries.Thenextdayallthecodewasdone... . ^Pike,Rob;Thompson,Ken.HelloWorldorΚαλημέρακόσμεorこんにちは世界(PDF).ProceedingsoftheWinter1993USENIXConference.1993[2019-11-23].（原始內容存檔(PDF)於2017-10-11）.  ^EncodingStandard.encoding.spec.whatwg.org.[2019-11-23].（原始內容存檔於2015-02-04）（英語）.TheproblemsoutlinedheregoawaywhenexclusivelyusingUTF-8,whichisoneofthemanyreasonsthatisnowthemandatoryencodingforallthings.  ^UsageSurveyofCharacterEncodingsbrokendownbyRanking.w3techs.com.[2019-11-23].（原始內容存檔於2022-01-21）（英語）.  ^Historicaltrendsintheusageofcharacterencodings.[2019-11-14].  ^UTF-8UsageStatistics.BuiltWith.[2011-03-28].（原始內容存檔於2021-12-07）.  ^UsingInternationalCharactersinInternetMail.InternetMailConsortium.1998-08-01[2007-11-08].（原始內容存檔於2007-10-26）.  ^Specifyingthedocument'scharacterencoding,HTML5.2,WorldWideWebConsortium,14December2017[2018-06-03],（原始內容存檔於2019-06-13）  ^參考RFC2277section3.1 ^UsingInternationalCharactersinInternetMail.2007-10-26[2018-07-27].原始內容存檔於2007-10-26.  ^TheUnicodeStandard,Version13.0,Chapter3(PDF).[2020-03-23].（原始內容存檔(PDF)於2021-09-20）.  ^ISO10646标准下载页面.[2020-03-23].（原始內容存檔於2022-01-19）.  ^14.014.1UTF-8andUnicodeFAQforUnix/LinuxbyMarkusKuhn.[2005-06-16].（原始內容存檔於2018-09-24）.  ^MySQL ::MySQL8.0ReferenceManual ::10.9.3Theutf8CharacterSet(Aliasforutf8mb3).dev.mysql.com.[2020-04-03].（原始內容存檔於2021-10-31）.  ^MySQL ::MySQL8.0ReferenceManual ::10.9.2Theutf8mb3CharacterSet(3-ByteUTF-8UnicodeEncoding).dev.mysql.com.[2020-04-03].（原始內容存檔於2022-01-13）.  ^MySQL ::MySQL8.0ReferenceManual ::10.9.1Theutf8mb4CharacterSet(4-ByteUTF-8UnicodeEncoding).dev.mysql.com.[2020-04-03].（原始內容存檔於2021-10-25）.  ^Hooper,Adam.InMySQL,neveruse“utf8”.Use“utf8mb4”..Medium.2019-08-19[2020-04-03].（原始內容存檔於2020-11-30）（英語）.  外部連結編輯 RFC3629：UTF-8標準 RFC2277：IETFpolicyoncharactersetsandlanguages RobPiketellsthestoryofUTF-8'screation（頁面存檔備份，存於網際網路檔案館） OriginalUTF-8paper UTF-8testpagesbyUniversityHannover（頁面存檔備份，存於網際網路檔案館）andtheWorldWideWebConsortium（頁面存檔備份，存於網際網路檔案館） Unix/Linux:UTF-8和Unicode的常見問題集（頁面存檔備份，存於網際網路檔案館），LinuxUnicodeHOWTO，UTF-8andGentoo（頁面存檔備份，存於網際網路檔案館） TheUnicode/UTF-8-charactertable（頁面存檔備份，存於網際網路檔案館）displaysUTF-8inavarietyofformats（withUnicodeandHTMLencodinginformation） OnlineToolforURLencoding/decodingaccordingtoRFC3986andRFC3629（JavaScript，GPL） UTF-8測試頁 UTF-8（頁面存檔備份，存於網際網路檔案館）由統一碼聯盟出版的書編輯 TheUnicodeStandard,Version5.0,FifthEdition,TheUnicodeConsortium,Addison-WesleyProfessional,2006年10月27日。

ISBN0-321-48091-0 TheUnicodeStandard,Version4.0,TheUnicodeConsortium,Addison-WesleyProfessional，2003年8月27日。

ISBN0-321-18578-1 取自「https://zh.wikipedia.org/w/index.php?title=UTF-8&oldid=73706675」