rfcrfc2781.txt

本程序为在linux下实现FTP传输文件的实现

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

标识为UTF-16BE，并且不带有BOM的文字：
   D8 08 DF 45 00 3D 00 52 00 61

标识为UTF-16LE，并且不带有BOM的文字：
   08 D8 45 DF 3D 00 52 00 61 00

采用Big-endian的文字，并且带有BOM：
   FE FF D8 08 DF 45 00 3D 00 52 00 61

采用Little-endian的文字，并且带有BOM：
   FF FE 08 D8 45 DF 3D 00 52 00 61 00

6. 不同标准的版本

ISO/IEC 10646经常按照出版的修正案进行更新；同样地，我们也就有不同版本的
Unicdoe标准：1.0, 1.1, 2.0, 2.1以及我们写作时最新的版本3.0。每一个新版本都取代前一
个版本，但是那些应用，和一些比较重要的数据，并不会马上进行更新。

总得来说，这些变化是增加新的字符，同时不会对旧的数据引起特别的问题。然而，
ISO/IEC 10646的第五修正案删除并扩展了韩语Hangul模块，这可能会使那些包含旧的
Hangul字符的数据在新版本中出现问题。Unicode 2.0和Unicode 1.1有着同样的不同。对
这样一个不兼容的改变的比较正式的解释是目前并没有很多包含Hangul的应用。这样的声
明很可能是真的，但并没有得到过证实。这样的改变被人们称为“韩语混乱”，有关的委员
会已经保证将来再不会出现类似的不兼容的改变。

新的版本所带来的不兼容的改变是和MIME字符标识标签有关，将在附录A中进行讨论。

7. IANA计划

IANA准备根据RFC 2278，并按照附录A.1, A.2,和A.3中所提到的登记模板进行新的
字符集登记。

8. 安全性考虑

正如本文第6节和附录A中所提到的，UTF-16基于ISO 10646并经常和ISO 10646
字符集一并使用。处理的程序必须能够处理那些在处理程序被设计出来的时候还没有并定义
的字符，同时还要能够阻止攻击者通过发送包含未知的字符而可能带来的对接收者的损害。

处理程序在处理任何类型，包括被编码为UTF-16的文本的时候，必须对那些控制字符
保持警惕并作出检查，因为这些字符可能对某个显示终端或键盘进行重新编程。同样地，处
理程序在解释文本实体的时候（比如查找结合在其中的程序代码），必须非常仔细，以不致
于在没有警告接收者的情况下就执行这些代码。

UTF-16中的文字可能会包含特殊的字符，比如“对象替换字符(0xFFFC)”，这些字符
可能会产生外部处理过程，这取决于处理程序的解释和外来的数据流的可执行性。所产生的
外部处理过程可能会带来一些副作用，比如允许发送一个消息来攻击消息接收者。

那些应用UTF-16的程序必须仔细考虑安全方面的问题，如何来处理非法的UTF-16序
列（也就是说，序列中含有成对的非法字符或者是不成对的字符）。我们可以想象得到，在
某些情况下，攻击者可能可以利用某些UTF-16处理程序，通过发送一个UTF-16语法并不
允许的八位字节序列来使其产生一些反常的行为。

9. 参考文献

   [CHARPOLICY]  Alvestrand, H., "有关字符集和语言的IETF策略", BCP 18, RFC 
2277, January 1998.

   [CHARSET-REG] Freed, N. 和J. Postel, "IANA字符集登记过程", BCP 19, RFC 2278, 
January 1998.

   [HTTP-1.1]    Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                 Masinter, L., Leach, P. 和T. Berners-Lee, "超文本传输协议-- 
HTTP/1.1", RFC 2616, June 1999.

   [ISO-10646]   ISO/IEC 10646-1:1993. 国际标准 --
                 信息技术科技 – 全球化的多字节编码字符集 (UCS) – 第一部分: 架构
和基本的语言模块. 到目前为止已出版22个修正案和2个技术勘误表。UTF-16在第一修
正案中的附录Q作出了规定。其他的许多修正案仍然在标准化过程中的不同阶段。目前正
在准备第二版，预计将在2000年出版。在新的版本中。UTF-16可能会在附录C中作出描
述。

   [MUSTSHOULD]  Bradner, S., "RFC中所使用的用来确定需求程度的关键字", BCP 14, 
RFC 2119, March 1997.

   [UNICODE]     Unicode联盟, "Unicode标准 –第三版", ISBN 0-201-61633-5. 全文发
布于：<http://www.unicode.org/unicode/standard/versions/Unicode3.0.html>.

   [UTF-8]       Yergeau, F., "UTF-8, ISO 10646的转换格式", RFC 2279, January 
1998.

   [WORKSHOP]    Weider, C., Preston, C., Simonsen, K., Alvestrand, H.,
                 Atkinson, R., Crispin., M. 和P. Svanberg, "IAB字符集
	        工作小组的报告", 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

本方案由多人协同完成，其中某些段落摘抄自[UTF-8]。对于其他间接对本文作出过贡献的
人均列于本文“致谢”一节。

A. 字符集登记

本备忘录将作为为三个MIME字符集进行登记[CHARSET-REG]的基础。这些建议的字符集
是"UTF-16BE","UTF-16LE"和"UTF-16"。用这些字串标识的对象包含由ISO/IEC 10646中
所列举的文字所组成的文本，该方案包含至少截至到第5修正案的所有修正案（韩语模块），
同时按照上文所提到的方案编码并线性化成为一系列字节流。

需要注意的是"UTF-16BE", "UTF-16LE"和"UTF-16"并不适合于描述“文字”的顶级媒体类
型。 不过有个例外情况就是在采用类似MIME方案的HTTP协议中，被免除了顶级文本类
型的限制（参见HTTP1.1[HTTP-1.1]第19.4.2节）。

有一点非常引人注意的就是这里所描述的标签并没有包括版本识别号，通常指的是ISO/IEC 
10646。这点是有意被忽略的，其中的原因如下：

MIME字符集被设计为用来给出在将收到的一系列字节解释为字符时所需要的信息，但不提
供其他的信息（参看RFC 2045[MIME]，2.2节）。只要字符集标准不会作出不兼容的改变，
版本号其实毫无用处，因为当接收者收到新设定的字符而其又不认识的时候，它也不能从版
本标识里面得知什么。版本标识本身并不会对将要收到的新的字符作出任何解释。

所以，只要标准一直保持兼容，让标签能够标识版本号好象也仅仅只是外观上的要求。但这
样对于那些和版本有关的标签来说却是一个缺点：如果一个旧的应用收到由新的应用发来的
数据，并带有未知的标签，它将不能辨认该标签，同时完全不能处理数据。而如果使用一个
通用的，大家都知道的标签却可以触发基本上正确的数据处理过程，而这些数据相当可能并
没有包含任何新的字符。

“韩语混乱”(ISO/IEC 10646第5修正案)是一个不兼容的改变，并且和上文所描述的MIME
字符集与版本无关的原则相抵触。但只有在数据包含了被按照Unicode 1.1(或者说第5修正
案以前的ISO/IEC 10646版本)编码的韩国Hangul字符，兼容性问题才会出现。虽然仍然
有人争论认为不会有这种数据，因而不必担心，但是，这仍然是将这个改变认为是不兼容的
改变的主要原因。

那么，在实际操作中，应该使用一个版本号无关的标签，这个标签被理解为在第5修正案
以后的所有版本，并且不会发生任何不兼容的改变。就算在以后ISO/IEC 10646的版本中
再有不兼容的改变，这里所定义的MIME字符集将仍然和以前的版本保持一致，除非IETE
对此再作出其他的规定。

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

   To: [e-mail]
   Subject: 新的字符集登记

   Charset name(s): UTF-16BE

   Published specification(s): 本方案适用于描述“文本”的MIME内容类型
   top-level type: No
   Person & email address to contact for further information:
   Paul Hoffman <[e-mail]>
   Francois Yergeau <[e-mail]>

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

   To: [e-mail]
   Subject: 新的字符集登记

   Charset name(s): UTF-16LE

   Published specification(s): 本方案适用于描述“文本”的MIME内容类型
   top-level type: No

   Person & email address to contact for further information:
   Paul Hoffman <[e-mail]>
   Francois Yergeau <[e-mail]>

A.3 Registration for UTF-16

   To: [e-mail]
   Subject: 新的字符集登记

   Charset name(s): UTF-16

   Published specification(s): 本方案适用于描述“文本”的MIME内容类型
   top-level type: No

   Person & email address to contact for further information:
   Paul Hoffman <[e-mail]>
   Francois Yergeau <[e-mail]>

作者地址

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

   EMail: [e-mail]

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

   EMail: [e-mail]

版权说明

   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协会给予RFC编辑部门的资金。


RFC 2781 UTF-16, an encoding of ISO 10646		UTF-16，一种ISO10646的编码方式
RFC文档中文翻译计划		1