這里"*"代表Ra象形文字(0x12345)。

標(biāo)識(shí)為UTF-16BE，并且不帶有BOM的文字：
   D8 08 DF 45 00 3D 00 52 00 61

標(biāo)識(shí)為UTF-16LE，并且不帶有BOM的文字：
   08 D8 45 DF 3D 00 52 00 61 00

采用Big-endian的文字，并且?guī)в蠦OM：
   FE FF D8 08 DF 45 00 3D 00 52 00 61

采用Little-endian的文字，并且?guī)в蠦OM：
   FF FE 08 D8 45 DF 3D 00 52 00 61 00

6. 不同標(biāo)準(zhǔn)的版本

ISO/IEC 10646經(jīng)常按照出版的修正案進(jìn)行更新；同樣地，我們也就有不同版本的
Unicdoe標(biāo)準(zhǔn)：1.0, 1.1, 2.0, 2.1以及我們寫作時(shí)最新的版本3.0。每一個(gè)新版本都取代前一
個(gè)版本，但是那些應(yīng)用，和一些比較重要的數(shù)據(jù)，并不會(huì)馬上進(jìn)行更新。

總得來(lái)說(shuō)，這些變化是增加新的字符，同時(shí)不會(huì)對(duì)舊的數(shù)據(jù)引起特別的問(wèn)題。然而，
ISO/IEC 10646的第五修正案刪除并擴(kuò)展了韓語(yǔ)Hangul模塊，這可能會(huì)使那些包含舊的
Hangul字符的數(shù)據(jù)在新版本中出現(xiàn)問(wèn)題。Unicode 2.0和Unicode 1.1有著同樣的不同。對(duì)
這樣一個(gè)不兼容的改變的比較正式的解釋是目前并沒(méi)有很多包含Hangul的應(yīng)用。這樣的聲
明很可能是真的，但并沒(méi)有得到過(guò)證實(shí)。這樣的改變被人們稱為“韓語(yǔ)混亂”，有關(guān)的委員
會(huì)已經(jīng)保證將來(lái)再不會(huì)出現(xiàn)類似的不兼容的改變。

新的版本所帶來(lái)的不兼容的改變是和MIME字符標(biāo)識(shí)標(biāo)簽有關(guān)，將在附錄A中進(jìn)行討論。

7. IANA計(jì)劃

IANA準(zhǔn)備根據(jù)RFC 2278，并按照附錄A.1, A.2,和A.3中所提到的登記模板進(jìn)行新的
字符集登記。

8. 安全性考慮

正如本文第6節(jié)和附錄A中所提到的，UTF-16基于ISO 10646并經(jīng)常和ISO 10646
字符集一并使用。處理的程序必須能夠處理那些在處理程序被設(shè)計(jì)出來(lái)的時(shí)候還沒(méi)有并定義
的字符，同時(shí)還要能夠阻止攻擊者通過(guò)發(fā)送包含未知的字符而可能帶來(lái)的對(duì)接收者的損害。

處理程序在處理任何類型，包括被編碼為UTF-16的文本的時(shí)候，必須對(duì)那些控制字符
保持警惕并作出檢查，因?yàn)檫@些字符可能對(duì)某個(gè)顯示終端或鍵盤進(jìn)行重新編程。同樣地，處
理程序在解釋文本實(shí)體的時(shí)候（比如查找結(jié)合在其中的程序代碼），必須非常仔細(xì)，以不致
于在沒(méi)有警告接收者的情況下就執(zhí)行這些代碼。

UTF-16中的文字可能會(huì)包含特殊的字符，比如“對(duì)象替換字符(0xFFFC)”，這些字符
可能會(huì)產(chǎn)生外部處理過(guò)程，這取決于處理程序的解釋和外來(lái)的數(shù)據(jù)流的可執(zhí)行性。所產(chǎn)生的
外部處理過(guò)程可能會(huì)帶來(lái)一些副作用，比如允許發(fā)送一個(gè)消息來(lái)攻擊消息接收者。

那些應(yīng)用UTF-16的程序必須仔細(xì)考慮安全方面的問(wèn)題，如何來(lái)處理非法的UTF-16序
列（也就是說(shuō)，序列中含有成對(duì)的非法字符或者是不成對(duì)的字符）。我們可以想象得到，在
某些情況下，攻擊者可能可以利用某些UTF-16處理程序，通過(guò)發(fā)送一個(gè)UTF-16語(yǔ)法并不
允許的八位字節(jié)序列來(lái)使其產(chǎn)生一些反常的行為。

9. 參考文獻(xiàn)

   [CHARPOLICY]  Alvestrand, H., "有關(guān)字符集和語(yǔ)言的IETF策略", BCP 18, RFC 
2277, January 1998.

   [CHARSET-REG] Freed, N. 和J. Postel, "IANA字符集登記過(guò)程", BCP 19, RFC 2278, 
January 1998.

   [HTTP-1.1]    Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                 Masinter, L., Leach, P. 和T. Berners-Lee, "超文本傳輸協(xié)議-- 
HTTP/1.1", RFC 2616, June 1999.

   [ISO-10646]   ISO/IEC 10646-1:1993. 國(guó)際標(biāo)準(zhǔn) --
                 信息技術(shù)科技 – 全球化的多字節(jié)編碼字符集 (UCS) – 第一部分: 架構(gòu)
和基本的語(yǔ)言模塊. 到目前為止已出版22個(gè)修正案和2個(gè)技術(shù)勘誤表。UTF-16在第一修
正案中的附錄Q作出了規(guī)定。其他的許多修正案仍然在標(biāo)準(zhǔn)化過(guò)程中的不同階段。目前正
在準(zhǔn)備第二版，預(yù)計(jì)將在2000年出版。在新的版本中。UTF-16可能會(huì)在附錄C中作出描
述。

   [MUSTSHOULD]  Bradner, S., "RFC中所使用的用來(lái)確定需求程度的關(guān)鍵字", BCP 14, 
RFC 2119, March 1997.

   [UNICODE]     Unicode聯(lián)盟, "Unicode標(biāo)準(zhǔn) –第三版", ISBN 0-201-61633-5. 全文發(fā)
布于：<http://www.unicode.org/unicode/standard/versions/Unicode3.0.html>.

   [UTF-8]       Yergeau, F., "UTF-8, ISO 10646的轉(zhuǎn)換格式", RFC 2279, January 
1998.

   [WORKSHOP]    Weider, C., Preston, C., Simonsen, K., Alvestrand, H.,
                 Atkinson, R., Crispin., M. 和P. Svanberg, "IAB字符集
	        工作小組的報(bào)告", RFC 2130, April 1997.

10. 致謝

Deborah Goldsmith為本方案的初稿作了大量的工作。Martin Duerst提出了許多重要的
修改建議，其他需要感謝的包括：

   Mati Allouche
   Walt Daniels
   Mark Davis
   Ned Freed
   Asmus Freytag
   Lloyd Honomichl
   Dan Kegel
   Murata Makoto
   Larry Masinter
   Markus Scherer
   Keld Simonsen
   Ken Whistler

本方案由多人協(xié)同完成，其中某些段落摘抄自[UTF-8]。對(duì)于其他間接對(duì)本文作出過(guò)貢獻(xiàn)的
人均列于本文“致謝”一節(jié)。

A. 字符集登記

本備忘錄將作為為三個(gè)MIME字符集進(jìn)行登記[CHARSET-REG]的基礎(chǔ)。這些建議的字符集
是"UTF-16BE","UTF-16LE"和"UTF-16"。用這些字串標(biāo)識(shí)的對(duì)象包含由ISO/IEC 10646中
所列舉的文字所組成的文本，該方案包含至少截至到第5修正案的所有修正案（韓語(yǔ)模塊），
同時(shí)按照上文所提到的方案編碼并線性化成為一系列字節(jié)流。

需要注意的是"UTF-16BE", "UTF-16LE"和"UTF-16"并不適合于描述“文字”的頂級(jí)媒體類
型。 不過(guò)有個(gè)例外情況就是在采用類似MIME方案的HTTP協(xié)議中，被免除了頂級(jí)文本類
型的限制（參見(jiàn)HTTP1.1[HTTP-1.1]第19.4.2節(jié)）。

有一點(diǎn)非常引人注意的就是這里所描述的標(biāo)簽并沒(méi)有包括版本識(shí)別號(hào)，通常指的是ISO/IEC 
10646。這點(diǎn)是有意被忽略的，其中的原因如下：

MIME字符集被設(shè)計(jì)為用來(lái)給出在將收到的一系列字節(jié)解釋為字符時(shí)所需要的信息，但不提
供其他的信息（參看RFC 2045[MIME]，2.2節(jié)）。只要字符集標(biāo)準(zhǔn)不會(huì)作出不兼容的改變，
版本號(hào)其實(shí)毫無(wú)用處，因?yàn)楫?dāng)接收者收到新設(shè)定的字符而其又不認(rèn)識(shí)的時(shí)候，它也不能從版
本標(biāo)識(shí)里面得知什么。版本標(biāo)識(shí)本身并不會(huì)對(duì)將要收到的新的字符作出任何解釋。

所以，只要標(biāo)準(zhǔn)一直保持兼容，讓標(biāo)簽?zāi)軌驑?biāo)識(shí)版本號(hào)好象也僅僅只是外觀上的要求。但這
樣對(duì)于那些和版本有關(guān)的標(biāo)簽來(lái)說(shuō)卻是一個(gè)缺點(diǎn)：如果一個(gè)舊的應(yīng)用收到由新的應(yīng)用發(fā)來(lái)的
數(shù)據(jù)，并帶有未知的標(biāo)簽，它將不能辨認(rèn)該標(biāo)簽，同時(shí)完全不能處理數(shù)據(jù)。而如果使用一個(gè)
通用的，大家都知道的標(biāo)簽卻可以觸發(fā)基本上正確的數(shù)據(jù)處理過(guò)程，而這些數(shù)據(jù)相當(dāng)可能并
沒(méi)有包含任何新的字符。

“韓語(yǔ)混亂”(ISO/IEC 10646第5修正案)是一個(gè)不兼容的改變，并且和上文所描述的MIME
字符集與版本無(wú)關(guān)的原則相抵觸。但只有在數(shù)據(jù)包含了被按照Unicode 1.1(或者說(shuō)第5修正
案以前的ISO/IEC 10646版本)編碼的韓國(guó)Hangul字符，兼容性問(wèn)題才會(huì)出現(xiàn)。雖然仍然
有人爭(zhēng)論認(rèn)為不會(huì)有這種數(shù)據(jù)，因而不必?fù)?dān)心，但是，這仍然是將這個(gè)改變認(rèn)為是不兼容的
改變的主要原因。

那么，在實(shí)際操作中，應(yīng)該使用一個(gè)版本號(hào)無(wú)關(guān)的標(biāo)簽，這個(gè)標(biāo)簽被理解為在第5修正案
以后的所有版本，并且不會(huì)發(fā)生任何不兼容的改變。就算在以后ISO/IEC 10646的版本中
再有不兼容的改變，這里所定義的MIME字符集將仍然和以前的版本保持一致，除非IETE
對(duì)此再作出其他的規(guī)定。

A.1 UTF-16BE的字符登記

   To: ietf-charsets@iana.org
   Subject: 新的字符集登記

   Charset name(s): UTF-16BE

   Published specification(s): 本方案適用于描述“文本”的MIME內(nèi)容類型
   top-level type: No
   Person & email address to contact for further information:
   Paul Hoffman <phoffman@imc.org>
   Francois Yergeau <fyergeau@alis.com>

A.2 UTF-16LE的字符登記

   To: ietf-charsets@iana.org
   Subject: 新的字符集登記

   Charset name(s): UTF-16LE

   Published specification(s): 本方案適用于描述“文本”的MIME內(nèi)容類型
   top-level type: No

   Person & email address to contact for further information:
   Paul Hoffman <phoffman@imc.org>
   Francois Yergeau <fyergeau@alis.com>

A.3 Registration for UTF-16

   To: ietf-charsets@iana.org
   Subject: 新的字符集登記

   Charset name(s): UTF-16

   Published specification(s): 本方案適用于描述“文本”的MIME內(nèi)容類型
   top-level type: No

   Person & email address to contact for further information:
   Paul Hoffman <phoffman@imc.org>
   Francois Yergeau <fyergeau@alis.com>

作者地址

   Paul Hoffman
   Internet Mail Consortium
   127 Segre Place
   Santa Cruz, CA  95060 USA

   EMail: phoffman@imc.org

   Francois Yergeau
   Alis Technologies
   100, boul. Alexis-Nihon, Suite 600
   Montreal  QC  H4M 2P2 Canada

   EMail: fyergeau@alis.com

版權(quán)說(shuō)明

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

致謝
感謝Internet協(xié)會(huì)給予RFC編輯部門的資金。


RFC 2781 UTF-16, an encoding of ISO 10646		UTF-16，一種ISO10646的編碼方式
RFC文檔中文翻譯計(jì)劃		1