UTF-8
维基百科，自由的百科全书
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]
目录 |
[编辑] 歷史
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位元的符號，也就是所謂的最高有效位元。
1992年8月，這個建議由IBMX/Open的代表流傳到一些感興趣的團體。與此同時，貝爾實驗室Plan 9作業系統工作小組的肯·汤普逊對這編碼系統作出重大的修改，讓編碼可以自我同步（self-synchronizing），使得不必從字串的開首讀取，也能找出字符間的分界。1992年9月2日，汤普逊和Pike一起在美國新澤西州一架餐車的餐桌墊上描繪出此設計的要點。接下來的日子，Pike及汤普逊將它實現，並將這編碼系統完全應用在Plan 9當中，及後他將有關成果回饋X/Open。
1993年1月25-29日的在聖地牙哥舉行的USENIX會議首次正式介紹UTF-8。
自1996年起，微軟的CAB（MS Cabinet）規格在UTF-8標準正式落實前就明確容許在任何地方使用UTF-8編碼系統。但有關的編碼器實際上從來沒有實作這方面的規格。
[编辑] 描述
目前有好幾份關於UTF-8詳細規格的文件，但這些文件在定義上有些許的不同：
- RFC 3629 / STD 63（2003），這份文件制定了UTF-8是標準的網際網路協議元素
- 第四版，The Unicode Standard，§3.9－§3.10（2003）
- ISO/IEC 10646-1:2000附加文件D（2000）
它們取代了以下那些被淘汰的定義：
- ISO/IEC 10646-1:1993修正案2／附加文件R（1996）
- 第二版，The Unicode Standard，附錄A（1996）
- RFC 2044（1996）
- RFC 2279（1998）
- 第三版，The Unicode Standard，§2.3（2000）及勘誤表#1：UTF-8 Shortest Form（2000）
- Unicode Standard 附加文件#27: Unicode 3.1（2001）
事實上，所有定義的基本原理都是相同的，它們之間最主要的不同是支援的字元範圍及無效輸入的處理方法。
Unicode字元的位元被分割為數個部分，並分配到UTF-8的位元組串中較低的位元的位置。在U+0080的以下字元都使用內含其字元的單位元組編碼。這些編碼正好對應7位元的ASCII字符。在其他情況，有可能需要多達4個字元組來表示一個字元。這些多位元組的最高有效位元會設定成1，以防止與7位元的ASCII字符混淆，並保持標準的位元組主導字串（standard byte-oriented string）運作順利。
| 代碼範圍 十六進制 |
標量值(scalar value) 二進制 |
UTF-8 二進制 / 十六進制 |
註釋 |
|---|---|---|---|
| 000000 - 00007F 128個代碼 |
00000000 00000000 0zzzzzzz | 0zzzzzzz(00-7F) | ASCII字元範圍，位元組由零開始 |
| 七個z | 七個z | ||
| 000080 - 0007FF 1920個代碼 |
00000000 00000yyy yyzzzzzz | 110yyyyy(C2-DF) 10zzzzzz(80-BF) | 第一個位元組由110開始，接著的位元組由10開始 |
| 三個y；二個y；六個z | 五個y；六個z | ||
| 000800 - 00D7FF 00E000 - 00FFFF 61440個代碼 [Note 1] |
00000000 xxxxyyyy yyzzzzzz | 1110xxxx(E0-EF) 10yyyyyy 10zzzzzz | 第一個位元組由1110開始，接著的位元組由10開始 |
| 四個x；四個y；二個y；六個z | 四個x；六個y；六個z | ||
| 010000 - 10FFFF 1048576個代碼 |
000wwwxx xxxxyyyy yyzzzzzz | 11110www(F0-F4) 10xxxxxx 10yyyyyy 10zzzzzz | 由11110開始，接著的位元組由10開始 |
| 三個w；二個x；四個x；四個y；二個y；六個z | 三個w；六個x；六個y；六個z |
- Note 1 Unicode在範圍D800-DFFF中不存在任何字元，BMP中約定了這個範圍用於UTF-16擴展標識辅助平面（兩個UTF-16表示一個辅助平面字符）. 當然，任何編碼都是可以被轉換到這個範圍，但在unicode中他們並不代表任何合法的值。
例如，希伯来语字母 aleph (א)的Unicode代码是 U+05D0，按照以下方法改成 UTF-8:
- 它属于 U+0080到U+07FF区域，这个表说明它使用双字节, 110yyyyy 10zzzzzz.
- 十六进制 的 0x05D0换算成二进制就是 101-1101-0000.
- 这11位数按顺序放入"y"部分和"z"部分: 11010111 10010000.
- 最后结果就是双字节，用十六进制写起来就是 0xD7 0x90，这就是这个字符aleph (א)的UTF-8编码。
所以开始的128个字元(US-ASCII)只需一字节，接下来的1920个字符需要双字节编码，包括带变音符号的拉丁字母, 希腊字母, 西里尔字母, 科普特语字母, 亚美尼亚语字母, 希伯来文字母和阿拉伯字母的字元。BMP其余的字元使用三个字节，剩余字符使用四个字节。
根据这种方式可以处理更大数量的字元。原来的规范允许长达6字节的序列，可以覆盖到31位元 (通用字符集原来的极限)。尽管如此，2003年11月UTF-8 被 RFC 3629 重新规范，只能使用原来Unicode定义的区域， U+0000到U+10FFFF。根据这些规范，以下字节值将无法出现在合法 UTF-8序列中:
| 编码(二进制) | 编码(十六进制) | 注释 |
|---|---|---|
| 1100000x | C0, C1 | 过长编码：双字节序列的头字节，但码点<= 127 |
| 1111111x | FE, FF | 无法达到: 7 或8字节序列的头字节 |
| 111110xx 1111110x |
F8, F9, FA, FB, FC, FD | 被RFC 3629规范: 5 或 6字节序列的头字节 |
| 11110101 1111011x |
F5, F6, F7 | 被RFC 3629规范: 码点超过10FFFF的头字节 |
虽然至少有两类在技术上是受以前的 UTF-8规范所支援，但这些編碼上还没有被赋予字元，所以不会在实际的文本中出现。 算法设计与霍夫曼编码类似。
[编辑] UTF-8的衍生物
[编辑] Windows
雖然不是標準，但許多Windows 程序(包括Windows 筆記本) 在UTF-8編碼的檔案的開首加入一段位元組串EF BB BF。這是編碼成UTF-8的Byte Order Mark U+FEFF。沒有預期要處理UTF-8的文字編輯器和瀏覽器會會顯示為ISO-8859-1字符""。
[编辑] Java
在通常用法下，Java程序语言在通过Template:Javadoc:SE 和Template:Javadoc:SE读取和写入串的时候支持标准UTF-8。但是，Java也支持一种非标准的变体UTF-8，供对象的系列化，Java本地界面和在class文件中的嵌入常数時使用的Template:Javadoc:SE。
标准和改正的UTF-8有两个不同点。第一，空字符 (null character，U+0000)使用双字节，而不是单字节，分别是11000000 10000000。这保证了在已编码字串中没有嵌入空字节。因为C语言等语言程序中，单字节空字符是用来标志串串结尾的。当已编码字串放到这样的语言中處理，一个嵌入的空字符将把字串一刀两断。
第二个不同点是基本多文種平面之外字符的编码的方法。在标准UTF-8中，这些字符使用4字节形式编码，而在改正的UTF-8中，这些字符和UTF-16一样首先表示为代理对(surrogate pairs)，然后再像CESU-8那样按照代理对分别编码。这样改正的原因更是微妙。Java中的字符为16位长，因此一些Unicode字符需要两个Java字符来表示。语言的这个性质蓋過了Unicode的增补平面的要求。尽管如此，為了要保持良好的向后兼容、要改變也不容易了。这个改正的编码系統保证了一个已编码字串可以一次编为一个UTF-16码，而不是一次一个Unicode码点。 不幸的是，这也意味着UTF-8中需要4字节的字符在改正UTF-8中变成需要6字节。
因为改正的UTF-8并不是 UTF-8，所以用户在交换信息和使用互联网的时候需要特别注意不要误把改正UTF-8當成UTF-8数据。
[编辑] Mac OS X
Mac OS X操作系统使用正式分解万国码(canonically decomposed Unicode)，在文件系统中使用UTF-8编码进行文件命名，這做法通常被称为UTF-8-MAC。正式分解万国码中，预分解字符是被禁止使用的，必须以组合字符取代。
这种方法使分类变得非常简单，但是会搞混那些使用预分解字符为标准、组合字符用来显示特殊字符的软件。Mac系统的这种NFD数据是万国码规范化(Unicode normalization)的一种格式。而其他系统, 包括Windows和 Linux, 使用万国码规范的NFC形式，也是W3C标准使用的形式。所以NFD数据必须典型的转换成NFC才能被其他平台或者网络使用。
在此有关于此问题的讨论 Apple Q&A 1173.
[编辑] 設計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，對更長的序列的機率就更低了。
[编辑] 過長的資料排列（overlong forms）、輸入無效及保安的考慮
[编辑] 优点及缺点
关于字符串长度的一个注解:
总体来说，在Unicode字符串中不可能由码点数量决定显示它所需要的长度，或者显示字符串之后在文本缓冲区中光标应该放置的位置；组合字符、变宽字体、不可打印字符和从右至左的文字都是其归因。
所以尽管在UTF-8字符串中字元数量与码点数量的关系比UTF-32更为复杂，在实际中很少会遇到有不同的情形。
- 总体
- 优点
- 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。
[编辑] UTF-8的編碼方式
UTF-8是UNICODE的一種變長度的編碼表達方式 〈一般UNICODE為雙位元組(指UCS2)〉，它由Ken Thompson于1992年建立，現在已經標准化為RFC 3629。UTF-8就是以8位为单元对UCS进行编码，而UTF-8不使用大尾序和小尾序的形式，每個使用UTF-8儲存的字符，除了第一個字節外，其餘字節的頭兩個位元都是以 "10" 開始，使文字處理器能夠較快地找出每個字符的開始位置。
但為了與以前的ASCII碼相容 (ASCII為一個位元組)，因此 UTF-8 選擇了使用可變長度字節來儲存 Unicode：
| UCS-2编码 | UTF-8字节流 |
|---|---|
| U-00000000 – U-0000007F: | 0xxxxxxx |
| U-00000080 – U-000007FF: | 110xxxxx 10xxxxxx |
| U-00000800 – U-0000FFFF: | 1110xxxx 10xxxxxx 10xxxxxx |
| U-00010000 – U-001FFFFF: | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx |
| U-00200000 – U-03FFFFFF: | 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx |
| U-04000000 – U-7FFFFFFF: | 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx |
-
- 在ASCII碼的範圍，用一個位元組表示，超出ASCII碼的範圍就用位元組表示，這就形成了我們上面看到的UTF-8的表示方法，這様的好處是當UNICODE文件中只有ASCII碼時，儲存的文件都為一個位元組，所以就是普通的ASCII文件無異，讀取的時候也是如此，所以能與以前的ASCII文件相容。
-
- 大於ASCII碼的，就會由上面的第一位元組的前幾位表示該unicode字元的長度，比如110xxxxxx前三位的二進位表示告訴我們這是個 2BYTE的UNICODE字元；1110xxxx是個三位的UNICODE字元，依此類推；xxx 的位置由字符編碼數的二進製表示的位填入. 越靠右的 x 具有越少的特殊意義.只用最短的那個足夠表達一個字符編碼數的多字節串. 注意在多字節串中, 第一個字節的開頭"1"的數目就是整個串中字節的數目.。
ASCII字母繼續使用1字節儲存，重音文字、希臘字母或西里爾字母等使用2字節來儲存，而常用的漢字就要使用3字節。辅助平面字元則使用4字節。
在UTF-8文件的開首，很多時都放置一個U+FEFF字符 (UTF-8 以 EF,BB,BF 代表)，以顯示這個文字檔案是以UTF-8編碼。
[编辑] UTF-8的特性
| UTF-8 | |
|---|---|
| Smallest code point | 0000 |
| Largest code point | 10FFFF |
| Code unit size | 8 bits |
| Byte order | N/A |
| Minimal bytes/character | 1 |
| Maximal bytes/character | 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 字節長。
- Bigendian UCS-4 字節串的排列順序是預定的。
- 字節 0xFE 和 0xFF 在 UTF-8 編碼中從未用到，同時，UTF-8以位元組為編碼單元，它的位元組順序在所有系統中都是一様的，没有位元組序的問題，也因此它實際上并不需要BOM。
- 與 UTF-16 或其他 Unicode 編碼相比，對於不支援 Unicode 和 XML 的系統，UTF-8 更不容易造成問題。
【註】
- UTF為UCS / Unicode Transformation Format“Unicode轉換格式”的縮寫。
- UCS的中文全稱為：信息技術--通用多八位編碼字符集 (Universal Multi-octet Coded Character Set)，由ISO/IEC 10646 標準描述。
[编辑] UTF-8編碼的缺點
[编辑] 不利于正则表达式检索
正则表达式可以进行很多英文高级的模糊检索。例如，[a-h]表示a到h间所有字母。
同样GBK编码的中文也可以这样利用正则表达式，比如在只知道一个字的读音而不知道怎么写的情况下，也可用正则表达式检索，因为GBK编码是按读音排序的。只是UTF-8不是按读音排序的，所以会对正则表达式检索造成不利影响。但是這種使用方式並未考慮中文中的破音字，因此影響不大。Unicode是按部首排序的，因此在只知道一個字的部首而不知道如何發音的情况下，UTF-8 可用正则表达式检索而GBK不行。
[编辑] 其他
與其他 Unicode 編碼相比，特別是UTF-16，在 UTF-8 中 ASCII 字元佔用的空間只有一半，可是在一些字元的 UTF-8 編碼佔用的空間就要多出，特別是中文、日文和韓文（CJK）這樣的象形文字，所以具體因素因文檔而異，但不論哪種情況，差別都不可能很明顯。
[编辑] 註釋
[编辑] 參考
- Alt codes
- ASCII
- Byte Order Mark
- Comparison of email clients#Features
- Comparison of Unicode encodings
- Character encodings in HTML
- ISO/IEC 8859
- GB18030
- UTF-8 in URIs
- Unicode and e-mail
- Unicode and HTML
- Universal Character Set
- UTF-16
- UTF-9 和 UTF-18
- 寬字元
[编辑] 由Unicode Consortium出版的書
- The Unicode Standard, Version 5.0, Fifth Edition, The Unicode Consortium, Addison-Wesley Professional,2006年10月27日. ISBN 0-321-48091-0
- The Unicode Standard, Version 4.0, The Unicode Consortium, Addison-Wesley Professional,2003年8月27日. ISBN 0-321-18578-1
[编辑] 外部連結
- RFC 3629：UTF-8 標準
- RFC 2277：IETF policy on character sets and languages
- Rob Pike tells the story of UTF-8's creation
- Original UTF-8 paper
- UTF-8 test pages by University Hannover and the World Wide Web Consortium
- Unix/Linux: UTF-8和Unicode的常見問題集, Linux Unicode HOWTO, UTF-8 and Gentoo
- The Unicode/UTF-8-character table displays UTF-8 in a variety of formats (with Unicode and HTML encoding information)
- Online Tool for URL encoding/decoding according to RFC 3986 and RFC 3629 (JavaScript, GPL)
- UTF-8 測試頁
- 另一個 UTF-8 測試頁
- UTF-8
- UTF-8 and Debian
| Unicode 相關的條目 |
|---|
| Unicode字符列表 | Unicode聯盟 | Unicode技術委員會 | ISO 10646 (通用字符集) | UTF-7 | UTF-8 | UTF-16 / UCS-2 | UTF-32 / UCS-4 |
| 基本多文種平面 | 辅助平面 | 中日韓統一表意文字 | CJKV | 表意文字小組 (IRG) | IICore | 完整Unicode編碼表 |
