UTF-8

UTF-8 （简体）

跳過字詞轉換說明

此條目可能需要進行清理，以符合維基百科的品質標準。（2007年12月31日） 請盡量協助改善這篇條目，詳細資訊請參見討論頁。

UTF-8（8 位元 Universal Character Set／Unicode Transformation Format）是一種針對 Unicode 的可變長度字元編碼（定長碼）,也是一種前綴碼。它可以用來表示 Unicode 標準中的任何字元，且其編碼中的第一個位元組仍與 ASCII 相容，這使得原來處理 ASCII 字元的軟體無須或只須做少部份修改，即可繼續使用。因此，它逐漸成為電子郵件、網頁及其他儲存或傳送文字的應用中，優先採用的編碼。

UTF-8 使用一至四個位元組為每個字元編碼：

1. 128 個 US-ASCII 字元只需一個位元組編碼（Unicode 範圍由 U+0000 至 U+007F）。
2. 帶有附加符號的拉丁文、希臘文、西里爾字母、亞美尼亞語、希伯來文、阿拉伯文、敘利亞文及它拿字母則需要二個位元組編碼（Unicode 範圍由 U+0080 至 U+07FF）。
3. 其他基本多文種平面（BMP）中的字元（這包含了大部分常用字）使用三個位元組編碼。
4. 其他極少使用的 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]

目錄 1 歷史 2 描述 3 UTF-8編碼位元組含義 4 UTF-8的衍生物 4.1 Windows 4.2 Java 4.3 變種 UTF-8 4.4 Mac OS X 5 設計UTF-8的理由 6 優點及缺點 7 使用UTF-8的原因 8 UTF-8的編碼方式 9 UTF-8的特性 10 UTF-8編碼的缺點 10.1 不利於正規表式檢索 10.2 其他 10.3 utf8_unicode_ci 和 utf8_general_ci 區別 11 註釋 12 參考 13 由統一碼聯盟出版的書 14 外部連結

歷史

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詳細規格的檔案，但這些檔案在定義上有些許的不同：

• 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中不存在任何字元，基本多文種平面中約定了這個範圍用於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個字元需要雙位元組編碼，包括帶附加符號的拉丁字母，希臘字母，西里爾字母，科普特語字母，亞美尼亞語字母，希伯來文字母和阿拉伯字母的字元。基本多文種平面中其餘的字元使用三個位元組，剩餘字元使用四個位元組。

根據這種方式可以處理更大數量的字元。原來的規範允許長達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編碼中的任意位元組B,如果B的第一位為0，則B為ASCII碼,並且B獨立的表示一個字元;

如果B的第一位為1,第二位為0,則B為一個非ASCII字元(該字元由多個位元組表示)中的一個位元組,並且不為字元的第一個位元組編碼;

如果B的前兩位為1,第三位為0,則B為一個非ASCII字元(該字元由多個位元組表示)中的第一個位元組,並且該字元由兩個位元組表示;

如果B的前三位為1,第四位為0,則B為一個非ASCII字元(該字元由多個位元組表示)中的第一個位元組,並且該字元由三個位元組表示;

如果B的前四位為1,第五位為0,則B為一個非ASCII字元(該字元由多個位元組表示)中的第一個位元組,並且該字元由四個位元組表示;

因此,對UTF-8編碼中的任意位元組,根據第一位,可判斷是否為ASCII字元;根據前二位,可判斷該位元組是否為一個字元編碼的第一個位元組; 根據前四位(如果前兩位均為1),可確定該位元組為字元編碼的第一個位元組,並且可判斷對應的字元由幾個位元組表示;根據前五位(如果前四位為1),可判斷編碼是否有錯誤或資料傳輸過程中是否有錯誤。

UTF-8的衍生物

Windows

雖然不是標準，但許多Windows 程式（包括Windows 筆記本）在UTF-8編碼的檔案的開首加入一段位元組串EF BB BF。這是位元組順序記號 U+FEFF 的 UTF-8 編碼結果。對於沒有預期要處理UTF-8的文字編輯器和瀏覽器會顯示成 ISO-8859-1 字串 ""。

Java

在通常用法下，Java程式語言在透過InputStreamReader 和OutputStreamWriter讀取和寫入串的時候支援標準UTF-8。但是，Java也支援一種非標準的變體UTF-8，供物件的系列化，Java原生介面和在class檔案中的嵌入常數時使用的modified UTF-8。

變種 UTF-8

標準和變種的UTF-8有兩個不同點。第一，空字元（null character，U+0000）使用雙位元組的 0xc0 0x80，而不是單位元組的 0x00。這保證了在已編碼字串中沒有嵌入空位元組。因為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分1，對更長的序列的機率就更低了。

優點及缺點

關於字串長度的一個註解：

總體來說，在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：

Unicode和UTF-8之間的轉換關係表

UCS-4編碼	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圖表說明

	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）這樣的象形文字，所以具體因素因文檔而異，但不論哪種情況，差別都不可能很明顯。

utf8_unicode_ci 和 utf8_general_ci 區別

在 phpMyAdmin 中有多種字符集，其中 utf8_unicode_ci 和 utf8_general_ci 是最常用的，但是 utf8_general_ci 對某些語言的支援有一些小問題，如果可以接受，那最好使用 utf8_general_ci ，因為它速度快。否則，請使用較為精確的 utf8_unicode_ci，不過速度會慢一些。

註釋

現代韓文（廢棄中文字元以後的）不是象形文字是拼音文字 日文是拼音文字和中文象形字元的組合

參考

• Alt codes
• ASCII
• 位元組順序記號
• 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
• 寬字元

由統一碼聯盟出版的書

• 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

Unicode 相關的條目
Unicode字元列表 | Unicode聯盟 | Unicode技術委員會 | ISO 10646（通用字符集） | UTF-7 | UTF-8 | UTF-16 / UCS-2 | UTF-32 / UCS-4
基本多文種平面 | 輔助平面 | 中日韓統一表意文字 | CJKV | 表意文字小組（IRG） | IICore | 完整Unicode編碼表

xxx

stock | retire | vm
Why are we here?
All text is available under the terms of the GNU Free Documentation License
This page is cache of Wikipedia. History