本備忘錄的狀態(tài)
本文檔講述了一種Internet社區(qū)的Internet標(biāo)準(zhǔn)跟蹤協(xié)議，它需要進一步進行討論和建
議以得到改進。請參考最新版的“Internet正式協(xié)議標(biāo)準(zhǔn)”(STD1)來獲得本協(xié)議的標(biāo)準(zhǔn)化程
度和狀態(tài)。本備忘錄的發(fā)布不受任何限制。
版權(quán)聲明
版權(quán)所屬Internet社區(qū)（1998），保留全部權(quán)力。
摘要
ISO/IEC10646-1定義了一種多8比特字節(jié)字符集，稱作通用字符集（UCS），它包含了世
界上大多數(shù)可書寫的字符系統(tǒng)。然而，多8比特字節(jié)字符與許多當(dāng)前的應(yīng)用和協(xié)議不一致，
從而導(dǎo)致了一些被稱為UCS轉(zhuǎn)換格式（UTF）的發(fā)展。每一種UTF有不同的特征。本備忘錄中
的UTF-8保留了全部US-ASCII范圍字符，提供了對文件系統(tǒng)、依靠于US-ASCII值的分析器
和其他軟件的兼容性，并且對其他字符值透明。本備忘錄用來更新和替換RFC2044，非凡對
相關(guān)標(biāo)準(zhǔn)的版本問題進行了說明。
目錄
1、介紹 2
2、UTF-8定義 3
3、標(biāo)準(zhǔn)版本 4
4、例子 4
5、MIME注冊 4
6、安全考慮 5
鳴謝 5
參考 5
作者地址 6
版權(quán)說明 7

1、介紹
ISO/IEC10646-1[ISO-10646]定義了一種多8比特字節(jié)字符集，稱作通用字符集（UCS），
它包含了世界上大多數(shù)可書寫的字符系統(tǒng)。已定義了兩種多8比特字節(jié)編碼，對每一個字符
采用四個8比特字節(jié)編碼的稱為UCS-4，對每一個字符采用兩個8比特字節(jié)編碼的稱為
UCS-2。它們僅能夠?qū)CS的前64K字符進行編址，超出此范圍的其它部分當(dāng)前還沒有分配
編址。
值得注重的是統(tǒng)一的字符編碼標(biāo)準(zhǔn)[UNICODE]定義了同樣的字符集，而且它進一步定義
了對實現(xiàn)器非常重要的額外字符屬性和其他應(yīng)用細節(jié)，但是沒有定義UCS-4編碼。直到現(xiàn)在，
Unicode的變化和ISO/IEC10646修正彼此穿插，因此他們的字符指令和編碼分配保持同步。
相關(guān)的標(biāo)準(zhǔn)委員會同意維持這種非常有用的同步。
然而，UCS-2和UCS-4編碼很難在許多當(dāng)前的應(yīng)用和協(xié)議中使用，這些應(yīng)用和協(xié)議假定
字符為一個8或7比特的字節(jié)。即使新的可以處理16比特字符的系統(tǒng)，卻不能處理UCS-4
數(shù)據(jù)。這種情況導(dǎo)致一種稱為UCS轉(zhuǎn)換格式（UTF）的發(fā)展，它每一種有不同的特征。
UTF-1僅僅是歷史上的重要，它已經(jīng)從ISO/IEC1064中刪除。UCS-7擁有僅采用8比特
字節(jié)就可對全部BMP指令進行編碼的性質(zhì)，它的最高比特位為零(其他7比特位為US-ASCII
值,[US-ASCII])，被認為是郵件安全的編碼([RFC2152])。本備忘錄中的UTF-8對象，使用了
8比特字節(jié)的所有位，保持全部US-ASCII取值范圍的性質(zhì)：US-ASCII字符用一個8比特字
節(jié)編碼，采用通常的US-ASCII值，因此，在此值下的任何一個8比特位字節(jié)僅僅代表一個
US-ASCII字符，而不會為其他字符。
UTF-16計劃用于從保留的范圍中，轉(zhuǎn)換UCS-4指令的一個子集為UCS-2值對。UTF-16
影響UTF-8，因為保留范圍的UCS-2值必須當(dāng)作UTF-8變換進行非凡處理。
UTF-8采用變化的8比特字節(jié)數(shù)對UCS-2或UCS-4字符編碼。8比特字節(jié)數(shù)量，以及每
一字節(jié)的值依靠于ISO/IEC10646中對此字符指定的整型值。這種轉(zhuǎn)換格式有下列特性（所
有的值為16進制）：
－從00000000到0000007F（US-ASCII指令）字符值對應(yīng)于8比特字節(jié)的00到7F（7
比特US-ASCII值）。由此的結(jié)論就是普通的ASCII字符串轉(zhuǎn)換后仍然是有效的UTF-8
字符串。
－US-ASCII值不會出現(xiàn)在其他的UTF-8編碼字符流中。這提供了與文件系統(tǒng)或其他軟件
（比如C庫中PRintf()函數(shù)）的兼容性，方便解析器解析US-ASCII值，且對其他值透
明。
－UTF-8向UCS-4，UCS-2兩者中任一個進行相互轉(zhuǎn)換比較輕易。
－多8比特字節(jié)序列的第一個8比特字節(jié)指明了系列中8比特字節(jié)的數(shù)目。
－8比特字節(jié)值FE和FF永遠不會出現(xiàn)。
－在8比特字符流中字符邊界從哪里開始較輕易發(fā)現(xiàn)。
－UCS-4字符串的字典分類順序保留。由于分類順序在任一情況下不是文化上有效，因此
它的重要性當(dāng)然有限。
－Boyer-Moore快速搜索算法可以用于UTF-8數(shù)據(jù)。
－UTF-8字符串可以通過一個簡單的算法進行可靠性驗證，也就是說，在任何一種編碼下，
驗證有效UTF-8字符串的耗費是低廉的，隨著字符長度增加而縮小。

UTF-8源于X/Open聯(lián)合國際化組織XOJIG的項目，用于描述文件系統(tǒng)的安全UCS轉(zhuǎn)
換格式[FSS-UTF]，以便和UNIX系統(tǒng)兼容，以及在一種單一編碼中支持多種語言的文字。
最開始的作者是GaryMiller,GregerLeijonhufvud和JohnEntenmann。后來KenThompson
和RobPike對UTF-8格式作了大量的工作。
也可以從Unicode技術(shù)支持報告#4和Unicode標(biāo)準(zhǔn)2.0[UNICODE]中找到UTF-8的描
述。權(quán)威性的引用，包括對UTF-16數(shù)據(jù)包含UTF-8的規(guī)定，在ISO/IEC10646-1[ISO-10646]
附錄R中進行了闡述。
2、UTF-8定義
在UTF-8中，字符采用1到6個8比特字節(jié)的序列進行編碼。僅僅一個8比特字節(jié)的一
個序列中，字節(jié)的高位為0，其他的7位用于字符值編碼。n（n>1）個8比特字節(jié)的一個序
列中，初始的8比特字節(jié)中高n位為1，接著一位為0，此字節(jié)余下的位包含被編碼字符值的
位。接著的所有8比特字節(jié)的最高位為1，接著下一位為0，余下每個字節(jié)6位包含被編碼字
符的位。
下表總結(jié)了這些不同的8比特字節(jié)類型格式。字母x指出此位來自于進行編碼的UCS-4
字符值。
UCS-4范圍（16進制）UTF-8系列（二進制）
00000000-0000007F0xxxxxxx
00000080-000007FF110xxxxx10xxxxxx
00000800-0000FFFF1110xxxx10xxxxxx10xxxxxx

00010000-001FFFFF11110xxx10xxxxxx10xxxxxx10xxxxxx
00200000-03FFFFFF111110xx10xxxxxx10xxxxxx10xxxxxx10xxxxxx
04000000-7FFFFFFF1111110x10xxxxxx...10xxxxxx

從UCS-4到UTF-8編碼過程如下：
1）從字符值和上表第一列中決定需要的8比特字節(jié)數(shù)目。著重指出的是上表中的行是相
互排斥的，也就是說，對于一個給定的UCS-4字符，僅僅有一個有效的編碼。
2）按照上表中第二列每行那樣預(yù)備8比特字節(jié)的高位。
3）將字符值的位填充在標(biāo)記為x地方，從字符值的低位開始，將它們放在系列中最后的
8比特字節(jié)中，然后字符值的接著位放置到下一個8比特字節(jié)，如此重復(fù)，直到所有標(biāo)
記位x的位都進行了填充。

理論上，簡單的通過用2個0值的8比特字節(jié)來擴展每個UCS-2字符，則從UCS-2到
UTF-8編碼的算法可以從上面得到。然而，從D800到DFFF間的UCS-2值對（用Unicode
說法是代理對），實際上是通過UTF-16來進行UCS-4字符轉(zhuǎn)換，因此需要非凡對待：UTF-16
轉(zhuǎn)換必須未完成，先轉(zhuǎn)換到于UCS-4字符，然后按照上面過程進行轉(zhuǎn)換。
從UTF-8到UCS-4解碼過程如下：
1）初始化UCS-4字符4個8比特字節(jié)的所有位為0。
2）根據(jù)序列中8比特字節(jié)數(shù)和上表中第二列（標(biāo)記為x位）來決定哪些位編碼用于字符
值。
3）從編碼序列分配位到UCS-4字符。首先從序列最后一個8比特字節(jié)的最低位開始，接
著向左進行，直到所有標(biāo)記為x的位完成。
假如UTF-8序列長度不大于3個8比特字節(jié)，解碼過程可以直接賦予UCS-2。

注重——上面解碼算法的實際實現(xiàn)應(yīng)該進行安全保護，以便處理解碼無效的系列。例如，
一個幼稚的實現(xiàn)可能（錯誤）解碼無效的UTF-8系列C080為字符U+0000，它可能導(dǎo)致安
全問題和/或其他問題。參見下面的安全考慮部分。
更具體的算法和公式可以在[FSS_UTF]，[UNICODE]或[ISO-10646]附錄R中找到。
3、標(biāo)準(zhǔn)版本
ISO/IEC10646通過發(fā)布修正進行了一次次更新。同樣地，Unicode標(biāo)準(zhǔn)的不同版本有：
1.0,1.1和2.0。每一個新版本廢除和替換了舊版本，但是實現(xiàn)和較重要的數(shù)據(jù)沒有馬上更新。
一般地，增加新字符的改變不會對舊數(shù)據(jù)引發(fā)非凡的問題。然而，ISO/IEC10646修正5
移動和擴展了韓文Hangul組，因此包含Hangul字符的以前版本數(shù)據(jù)在新版本下無效。Unicode
2.0對Unicode1.1有同樣的不同。答應(yīng)這樣不協(xié)調(diào)變化的正式理由是在實現(xiàn)上和數(shù)據(jù)中不存
在Hangul。這個改變事件被稱為“韓文混亂”，相關(guān)的委員會保證永遠不會再進行這樣不協(xié)
調(diào)的改變。
關(guān)于MIME字符編碼標(biāo)簽，新版本和特定的任何不協(xié)調(diào)的改變都有前因后果，第5節(jié)將
進行討論。
4、例子
UCS-2系列"A<NOTIDENTICALTO><ALPHA>."(0041,2262,0391,002E)用UTF-8編碼
如下：
41E289A2CE912E
對韓文"hangugo"(D55C,AD6D,C5B4)，表示Hangul字符的UCS-2序列可以編碼如下：
ED959CEAB5ADEC96B4
對日文"nihongo"(65E5,672C,8A9E)，表示漢字的UCS-2序列可以編碼如下：
E697A5E69CACE8AA9E
5、MIME注冊
本備忘錄計劃服務(wù)于MIME字符集參數(shù)[CHARSET-REG]注冊基礎(chǔ)。被提到的字符集參
數(shù)值是UTF-8。這個字符標(biāo)簽媒介類型包含由ISO/IEC10646指令組成的字符文本，ISO/IEC
10646包括了直到修正5（韓文組）的所有修正版本。此類型使用上面概述的編碼方案進行8
比特字節(jié)序列編碼。UTF-8適合于在文本的上層類型下使用MIME內(nèi)容類型
值得注重的是，"UTF-8"標(biāo)簽不包含一般由ISO/IEC10646提交的版本標(biāo)識。特意這樣做
的原因如下：
MIME字符集標(biāo)簽的設(shè)計僅用于給予需要翻譯從有線接收的字節(jié)序列到字符序列的信
息，而沒有其他的用途(參見RFC2045,2.2節(jié)[MIME])。只要字符集標(biāo)準(zhǔn)沒有不兼容的改變，
版本數(shù)字沒有意義，因為一方接收到不熟悉的新分配字符，通過標(biāo)簽的理解得不到任何東西。
標(biāo)簽可能被隨時接收，標(biāo)簽自己對新字符不提供任何信息。
因此，只要標(biāo)準(zhǔn)適當(dāng)?shù)馗倪M，擁有標(biāo)識版本標(biāo)簽的益處是顯而可見，但對依靠于版本的
標(biāo)簽不利因素為：當(dāng)舊的應(yīng)用收到一個包含新的不熟悉標(biāo)簽的數(shù)據(jù)時，它可能熟悉標(biāo)簽失敗，
而不能完成對數(shù)據(jù)的處理；而一個普通的熟悉標(biāo)簽會引發(fā)大多數(shù)正確的數(shù)據(jù)處理，它可能不
包含任何新的字符。
現(xiàn)今“韓文混亂”(ISO/IEC10646修正5)是一種不協(xié)調(diào)的變化，理論上同上面描述的與
版本無關(guān)的MIME字符集標(biāo)簽的適用性相矛盾。但是兼容性問題僅會出現(xiàn)在包含采用Unicode
1.1（或等同的ISO/IEC10646修正5以前）編碼的韓文Hangul字符數(shù)據(jù)中。可以證實沒有這
樣的數(shù)據(jù)值得擔(dān)心，因此，這是不協(xié)調(diào)改變可以被接收的主要原因。
實際上，假定標(biāo)簽理解為對修正5以后的所有版本進行引用，并且假定實際不會出現(xiàn)不
協(xié)調(diào)的改變，則獨立于版本的標(biāo)簽是有理由的。由此，除非ISO/IEC10646以后版本出現(xiàn)不
兼容改變，這里的MIME字符集定義將同以前的版本保持一致，除非IETF明確規(guī)定為不同。
也計劃注冊字符集參數(shù)值為"UNICODE-1-1-UTF-8"，唯一用途是用于可標(biāo)簽的文本數(shù)
據(jù)。可標(biāo)簽的文本數(shù)據(jù)包含沒有考慮進ISO/IEC10646修正5（即修正5前的代碼點分配）的
Hangul音節(jié)編碼成UTF－8。其他的UTF-8數(shù)據(jù)不應(yīng)該使用此標(biāo)簽，非凡是不包含任何Hangul
音節(jié)的數(shù)據(jù)。非常重要的強烈建議是反對不考慮ISO/IEC10646修正5的情況下，創(chuàng)建任何
新的包含Hangul的數(shù)據(jù)。
6、安全考慮
UTF-8實現(xiàn)需要進行安全考慮的方面是如何處理非法的UTF-8序列。可以想象，在某些
環(huán)境中攻擊者可能進行的攻擊是發(fā)送一個UTF-8語法不答應(yīng)的8比特字節(jié)序列給不謹(jǐn)慎的
UTF-8分析器。
這種攻擊一個非凡敏感的形態(tài)是攻擊分析器。此分析器對輸入的UTF-8編碼格式執(zhí)行安
全鑒定有效性檢查，但是解釋了一些非法的8比特字節(jié)作為字符。例如，當(dāng)碰到單個8比特
字節(jié)序列00時，分析器可能禁止NUL字符，但是答應(yīng)非法的兩個8比特字節(jié)序列C080，
解釋它為NUL字符。另一個例子是禁止8比特字節(jié)序列2F2E2E2F("/../")的分析器，答應(yīng)
非法8比特字節(jié)序列2FC0AE2E2F。
鳴謝
下列人員參與本備忘錄的起草和討論：
JamesE.AgenbroadAndriesBrouwer
MartinJ.DrstNedFreed
DavidGoldsmithEdwinF.Hart
KentKarlssonMarkusKuhn
MichaelKungAlainLaBonte
JohnGardinerMyersMurraySargent
KeldSimonsenArnoldWinkler
參考
[CHARSET-REG]Freed,N.,andJ.Postel,"IANACharsetRegistration
Procedures",BCP19,RFC2278,January1998.

[FSS_UTF]X/OpenCAESpecificationC501ISBN1-85912-082-228cm.
22p.pbk.172g.4/95,X/OpenCompanyLtd.,"File
SystemSafeUCSTransformationFormat(FSS_UTF)",
X/OpenPreleminarySpecification,DocumentNumber
P316.AlsopublishedinUnicodeTechnicalReport#4.

[ISO-10646]ISO/IEC10646-1:1993.InternationalStandard--
Informationtechnology--UniversalMultiple-Octet
CodedCharacterSet(UCS)--Part1:Architectureand
BasicMultilingualPlane.Fiveamendmentsanda
technicalcorrigendumhavebeenpublisheduptonow.
UTF-8isdescribedinAnnexR,publishedasAmendment
2.UTF-16isdescribedinAnnexQ,publishedas
Amendment1.17otheramendmentsarecurrentlyat
variousstagesofstandardization.

[MIME]Freed,N.,andN.Borenstein,"MultipurposeInternet
MailExtensions(MIME)PartOne:FormatofInternet
MessageBodies",RFC2045.N.Freed,N.Borenstein,
"MultipurposeInternetMailExtensions(MIME)Part
Two:MediaTypes",RFC2046.K.Moore,"MIME
(MultipurposeInternetMailExtensions)PartThree:
MessageHeaderExtensionsforNon-ASCIIText",RFC
2047.N.Freed,J.Klensin,J.Postel,"Multipurpose
InternetMailExtensions(MIME)PartFour:
RegistrationProcedures",RFC2048.N.Freed,N.
Borenstein,"MultipurposeInternetMailExtensions
(MIME)PartFive:ConformanceCriteriaandExamples",
RFC2049.AllNovember1996.

[RFC2152]Goldsmith,D.,andM.Davis,"UTF-7:AMail-safe
TransformationFormatofUnicode",RFC1642,Taligent
inc.,May1997.(ObsoletesRFC1642)

[UNICODE]TheUnicodeConsortium,"TheUnicodeStandard--
Version2.0",Addison-Wesley,1996.

[US-ASCII]CodedCharacterSet--7-bitAmericanStandardCodefor
InformationInterchange,ANSIX3.4-1986.
作者地址
FrancoisYergeau
AlisTechnologies
100,boul.Alexis-Nihon
Suite600
MontrealQCH4M2P2
Canada

Phone:+1(514)747-2547
Fax:+1(514)747-2561
EMail:fyergeau@alis.com

版權(quán)說明
Copyright(C)TheInternetSociety(1998).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseeXPlainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurpoSEOf
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.