[要約] RFC 2781は、ISO 10646のエンコーディングであるUTF-16についての要約を提供しています。このRFCの目的は、UTF-16の特徴と使用方法を説明し、国際化されたテキストデータのエンコーディングに関するガイドラインを提供することです。
Network Working Group P. Hoffman
Request for Comments: 2781 Internet Mail Consortium
Category: Informational F. Yergeau
Alis Technologies
February 2000
UTF-16, an encoding of ISO 10646
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document describes the UTF-16 encoding of Unicode/ISO-10646, addresses the issues of serializing UTF-16 as an octet stream for transmission over the Internet, discusses MIME charset naming as described in [CHARSET-REG], and contains the registration for three MIME charset parameter values: UTF-16BE (big-endian), UTF-16LE (little-endian), and UTF-16.
この文書は、Unicode / ISO-10646のUTF-16符号化を記載しており、インターネットを介して送信するためのオクテットストリームとしてUTF-16をシリアル化の問題に対処し、[CHARSET-REG]に記載されているようにMIME文字セットの命名について説明し、登録が含まれていUTF-16BE（ビッグエンディアン）、UTF-16LE（リトルエンディアン）、およびUTF-16：3つのMIME charsetパラメータ値について。
The Unicode Standard [UNICODE] and ISO/IEC 10646 [ISO-10646] jointly define a coded character set (CCS), hereafter referred to as Unicode, which encompasses most of the world's writing systems [WORKSHOP]. UTF-16, the object of this specification, is one of the standard ways of encoding Unicode character data; it has the characteristics of encoding all currently defined characters (in plane 0, the BMP) in exactly two octets and of being able to encode all other characters likely to be defined (the next 16 planes) in exactly four octets.
Unicode標準[UNICODE]およびISO / IEC 10646 [ISO-10646]共同以下世界の書記体系[WORKSHOP]のほとんどを包含するユニコード、と呼ばれるコード化文字セット（CCS）を、定義します。 UTF-16は、この明細書の目的は、符号化Unicode文字データの標準的な方法の一つです。それは正確に2つのオクテットに（プレーン0、BMPにおける）現在定義されているすべての文字をエンコードするのとちょうど4オクテットで定義される可能性が高い他のすべての文字（次の16面）をコードすることができるという特徴を有します。
The Unicode Standard further defines additional character properties and other application details of great interest to implementors. Up to the present time, changes in Unicode and amendments to ISO/IEC 10646 have tracked each other, so that the character repertoires and code point assignments have remained in sync. The relevant standardization committees have committed to maintain this very useful synchronism, as well as not to assign characters outside of the 17 planes accessible to UTF-16.
Unicode標準は、さらに追加の文字プロパティと実装者への大きな関心の他のアプリケーションの詳細を定義します。文字レパートリーとコードポイントの割り当てが同期に残っているように、現在までに、ISO / IEC 10646にユニコードに変更および修正は、互いを追跡しました。関連する標準化委員会は、UTF-16へのアクセス17枚の平面の外に文字を割り当てるには、この非常に便利な同期を維持するだけでなく、しないことを約束しています。
The IETF policy on character sets and languages [CHARPOLICY] says that IETF protocols MUST be able to use the UTF-8 character encoding scheme [UTF-8]. Some products and network standards already specify UTF-16, making it an important encoding for the Internet. This document is not an update to the [CHARPOLICY] document, only a description of the UTF-16 encoding.
文字セットと言語[CHARPOLICY]上のIETF方針は、IETFプロトコルがUTF-8文字符号化スキーム[UTF-8]を使用できなければならないと述べています。一部の製品およびネットワーク規格は、すでにインターネットのための重要なエンコーディング作り、UTF-16を指定します。この文書では、[CHARPOLICY】文書の更新、UTF-16エンコーディングの説明だけではありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [MUSTSHOULD].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [MUSTSHOULD]に記載されているように解釈されます。
Throughout this document, character values are shown in hexadecimal notation. For example, "0x013C" is the character whose value is the character assigned the integer value 316 (decimal) in the CCS.
本明細書を通して、文字値は16進表記で示されています。例えば、「0x013C」は、その値がCCSの整数値316（10進数）を割り当てられた文字である文字です。
UTF-16 is described in the Unicode Standard, version 3.0 [UNICODE]. The definitive reference is Annex Q of ISO/IEC 10646-1 [ISO-10646]. The rest of this section summarizes the definition is simple terms.
UTF-16は、Unicode規格、バージョン3.0 [UNICODE]に記載されています。決定的な基準は、ISO / IEC 10646-1の附属書Q [ISO-10646]です。このセクションの残りの部分は、定義は簡単な言葉でまとめています。
In ISO 10646, each character is assigned a number, which Unicode calls the Unicode scalar value. This number is the same as the UCS-4 value of the character, and this document will refer to it as the "character value" for brevity. In the UTF-16 encoding, characters are represented using either one or two unsigned 16-bit integers, depending on the character value. Serialization of these integers for transmission as a byte stream is discussed in Section 3.
ISO 10646では、各文字はUnicodeはUnicodeのスカラー値を呼び出し番号が割り当てられます。この数は、文字のUCS-4値と同じであり、この文書は簡潔にするため、「文字の値」と呼ぶことにします。 UTF-16符号化では、文字は、文字の値に応じて、1つまたは2つの符号なし16ビット整数を使用して表されます。バイトストリームとして伝送のためのこれらの整数の直列化は、第3節で議論されます。
The rules for how characters are encoded in UTF-16 are:
文字はUTF-16でエンコードされているどのようにするためのルールは以下のとおりです。
- Characters with values less than 0x10000 are represented as a single 16-bit integer with a value equal to that of the character number.
- 値を持つ文字は以下0x10000番地より文字数と等しい値を有する単一の16ビット整数として表されます。
- Characters with values between 0x10000 and 0x10FFFF are represented by a 16-bit integer with a value between 0xD800 and 0xDBFF (within the so-called high-half zone or high surrogate area) followed by a 16-bit integer with a value between 0xDC00 and 0xDFFF (within the so-called low-half zone or low surrogate area).
- 0x10000番地とから0x10FFFFの間の値を持つ文字は0xDC00の間の値を持つ16ビット整数に続く（いわゆる高ハーフゾーンまたは高サロゲート領域内）0xD800と0xDBFFの間の値を持つ16ビットの整数で表されそして0xDFFF（いわゆる低ハーフゾーンまたは低い代理エリア内）。
- Characters with values greater than 0x10FFFF cannot be encoded in UTF-16.
- から0x10FFFFより大きい値を持つ文字は、UTF-16でエンコードすることができません。
Note: Values between 0xD800 and 0xDFFF are specifically reserved for use with UTF-16, and don't have any characters assigned to them.
注：0xD800と0xDFFF間の値は、特にUTF-16で使用するために予約されており、それらに割り当てられた任意の文字を持っていません。
Encoding of a single character from an ISO 10646 character value to UTF-16 proceeds as follows. Let U be the character number, no greater than 0x10FFFF.
UTF-16進行にISO 10646文字値から単一の文字のエンコーディングは、次のように。 Uがから0x10FFFFより大きくない文字の数を、とします。
1) If U < 0x10000, encode U as a 16-bit unsigned integer and terminate.
1）U <0x10000番地場合、16ビットの符号なし整数としてUを符号化し、終了します。
2) Let U' = U - 0x10000. Because U is less than or equal to 0x10FFFF, U' must be less than or equal to 0xFFFFF. That is, U' can be represented in 20 bits.
0x10000番地 - 2）U」= Uましょう。 Uは、以下から0x10FFFFに等しいので、U」は以下0xFFFFFと等しくなければなりません。すなわち、U」は20ビットで表現することができるされています。
3) Initialize two 16-bit unsigned integers, W1 and W2, to 0xD800 and 0xDC00, respectively. These integers each have 10 bits free to encode the character value, for a total of 20 bits.
3）それぞれ0xD800と0xDC00に、2つの16ビット符号なし整数、W1及びW2を初期化します。これらの整数はそれぞれ、20ビットの合計、文字値を符号化する自由10ビットを有します。
4) Assign the 10 high-order bits of the 20-bit U' to the 10 low-order bits of W1 and the 10 low-order bits of U' to the 10 low-order bits of W2. Terminate.
4）W2の10下位ビットに「W1の10下位ビットとUの10下位ビットに」20ビットUの10上位ビットを割り当てます。終了します。
Graphically, steps 2 through 4 look like: U' = yyyyyyyyyyxxxxxxxxxx W1 = 110110yyyyyyyyyy W2 = 110111xxxxxxxxxx
U」= yyyyyyyyyyxxxxxxxxxx W1 = W2 = 110110yyyyyyyyyy 110111xxxxxxxxxx：グラフ、など4外観を通して2ステップ
Decoding of a single character from UTF-16 to an ISO 10646 character value proceeds as follows. Let W1 be the next 16-bit integer in the sequence of integers representing the text. Let W2 be the (eventual) next integer following W1.
ISO 10646文字値が進むにUTF-16からの単一の文字の解読次のように。 W1は、テキストを表す整数のシーケンス内の次の16ビットの整数とします。 W2はW1以下の（最終的な）次の整数とします。
1) If W1 < 0xD800 or W1 > 0xDFFF, the character value U is the value of W1. Terminate.
1）W1 <0xD800またはW1> 0xDFFF場合、文字値Uは、W1の値です。終了します。
2) Determine if W1 is between 0xD800 and 0xDBFF. If not, the sequence is in error and no valid character can be obtained using W1. Terminate.
2）W1は0xD800と0xDBFF間にあるかどうかを確認。そうでない場合、シーケンスは誤りであると有効な文字は、W1を使用して取得することはできません。終了します。
3) If there is no W2 (that is, the sequence ends with W1), or if W2 is not between 0xDC00 and 0xDFFF, the sequence is in error. Terminate.
3）はW2（つまり存在しない場合、配列）がW1で終わる、またはW2は0xDC00と0xDFFFの間にない場合、シーケンスは誤りです。終了します。
4) Construct a 20-bit unsigned integer U', taking the 10 low-order bits of W1 as its 10 high-order bits and the 10 low-order bits of W2 as its 10 low-order bits.
4）その10上位ビットと10下位ビットとしてW2の10下位ビットとしてW1の10下位ビットを取って、20ビットの符号なし整数U」を構築します。
5) Add 0x10000 to U' to obtain the character value U. Terminate.
5）U.は終了文字値を取得するために「Uに0x10000番地を追加します。
Note that steps 2 and 3 indicate errors. Error recovery is not specified by this document. When terminating with an error in steps 2 and 3, it may be wise to set U to the value of W1 to help the caller diagnose the error and not lose information. Also note that a string decoding algorithm, as opposed to the single-character decoding described above, need not terminate upon detection of an error, if proper error reporting and/or recovery is provided.
手順2と3を注記は、エラーを示しています。エラー回復は、この文書で指定されていません。ステップ2および3のエラーで終了する場合、呼び出し側がエラーを診断し、情報を失わない助けるためにW1の値にUを設定するのが賢明かもしれません。また、適切なエラー報告及び/又は回復が設けられている場合は、文字列の復号化アルゴリズムは、上述した単一文字の復号とは対照的に、エラーの検出時に停止する必要はないことに注意してください。
Appendix A of this specification contains registrations for three MIME charsets: "UTF-16BE", "UTF-16LE", and "UTF-16". MIME charsets represent the combination of a CCS (a coded character set) and a CES (a character encoding scheme). Here the CCS is Unicode/ISO 10646 and the CES is the same in all three cases, except for the serialization order of the octets in each character, and the external determination of which serialization is used.
"UTF-16BE"、 "UTF-16LE"、および "UTF-16"：この仕様の付録Aは、3つのMIME文字セットのための登録が含まれています。 MIME文字セットは、CCS（コード化文字セット）およびCES（文字符号化方式）の組み合わせを表します。ここではCCSは、Unicode / ISO 10646で、CESは、各文字のオクテットの直列化順序を除いて、すべての3つの場合で同じであり、シリアライズの外部決意が使用されています。
This section describes which of the three labels to apply to a stream of text. Section 4 describes how to interpret the labels on a stream of text.
このセクションでは、テキストのストリームに適用する3つのラベルのかを説明します。第4節では、テキストの流れにラベルを解釈する方法について説明します。
Historically, computer hardware has processed two-octet entities such as 16-bit integers in one of two ways. So-called "big-endian" hardware handles two-octet entities with the higher-order octet first, that is at the lower address in memory; when written out to disk or to a network interface (serializing), the high-order octet thus appears first in the data stream. On the other hand, "Little-endian" hardware handles two-octet entities with the lower-order octet first. Hardware of both kinds is common today.
歴史的には、コンピュータのハードウェアは、2つの方法のいずれかで、このような16ビット整数として2オクテットエンティティを処理しました。いわゆる「ビッグエンディアン」ハードウェアは最初の高次オクテットと2オクテットエンティティを扱う、それは、メモリ内の下位アドレスです。ディスクまたはネットワークインタフェース（シリアライズ）に書き出されたときに、上位オクテットは、このようにデータ・ストリームに最初に表示されます。一方、「リトルエンディアン」のハードウェアは、最初に下位のオクテットを持つ2つのオクテットエンティティを処理します。両方の種類のハードウェアは、今日一般的です。
For example, the unsigned 16-bit integer that represents the decimal number 258 is 0x0102. The big-endian serialization of that number is the octet 0x01 followed by the octet 0x02. The little-endian serialization of that number is the octet 0x02 followed by the octet 0x01. The following C code fragment demonstrates a way to write 16- bit quantities to a file in big-endian order, irrespective of the hardware's native byte order.
例えば、進数258を表す符号なし16ビット整数は0x0102です。その数のビッグエンディアン連載は、オクテット0x02の続くオクテット0x01です。その数のリトルエンディアンのシリアライゼーションは、オクテットが0x01に続くオクテット0x02です。次のCコードフラグメントは関係なく、ハードウェアのネイティブのバイトオーダーの、ビッグエンディアン順にファイルへの16ビット量を記述する方法を示しています。
void write_be(unsigned short u, FILE f) /* assume short is 16 bits */
{
putc(u >> 8, f); /* output high-order byte */
putc(u & 0xFF, f); /* then low-order */
}
The term "network byte order" has been used in many RFCs to indicate big-endian serialization, although that term has yet to be formally defined in a standards-track document. Although ISO 10646 prefers big-endian serialization (section 6.3 of [ISO-10646]), little-endian order is also sometimes used on the Internet.
その用語は、まだ正式に標準トラック文書で定義する必要がありますが、用語「ネットワークバイト順序」がビッグエンディアンのシリアル化を示すために、多くのRFCで使用されてきました。 ISO 10646は、ビッグエンディアン連載（[ISO-10646]のセクション6.3）を好むが、リトルエンディアン順序はまた時々、インターネット上で使用されています。
The Unicode Standard and ISO 10646 define the character "ZERO WIDTH NON-BREAKING SPACE" (0xFEFF), which is also known informally as "BYTE ORDER MARK" (abbreviated "BOM"). The latter name hints at a second possible usage of the character, in addition to its normal use as a genuine "ZERO WIDTH NON-BREAKING SPACE" within text. This usage, suggested by Unicode section 2.4 and ISO 10646 Annex F (informative), is to prepend a 0xFEFF character to a stream of Unicode characters as a "signature"; a receiver of such a serialized stream may then use the initial character both as a hint that the stream consists of Unicode characters and as a way to recognize the serialization order. In serialized UTF-16 prepended with such a signature, the order is big-endian if the first two octets are 0xFE followed by 0xFF; if they are 0xFF followed by 0xFE, the order is little-endian. Note that 0xFFFE is not a Unicode character, precisely to preserve the usefulness of 0xFEFF as a byte-order mark.
Unicode標準とISO 10646の文字も「バイトオーダーマーク」（略して「BOM」）として非公式に知られている「ZERO WIDTH NON-BREAKING SPACE」（0xFEFF）を定義します。後者の名前は、テキスト内の本物の「ZERO WIDTH NON-BREAKING SPACE」としての通常の使用に加えて、文字の第二の可能な使用法を示唆します。 Unicodeのセクション2.4およびISO 10646附属書F（参考）によって提案されたこの用法では、「署名」としてUnicode文字のストリームに0xFEFFの文字を付加することです。このようなシリアル化されたストリームの受信機は、ストリームがUnicode文字で構成されていることをヒントとして、および直列化順序を認識するための方法として、両方の初期文字を使用することができます。最初の2つのオクテットが0xFFで0xFEのに続いている場合はシリアル化されたUTF-16のような署名が付加では、順序はビッグエンディアンです。彼らは0xFFを0xFEのが続いている場合、順序はリトルエンディアンです。正確にバイトオーダーマークとして0xFEFFの有用性を維持するために、0xFFFEというのUnicode文字ではないことに注意してください。
It is important to understand that the character 0xFEFF appearing at any position other than the beginning of a stream MUST be interpreted with the semantics for the zero-width non-breaking space, and MUST NOT be interpreted as a byte-order mark. The contrapositive of that statement is not always true: the character 0xFEFF in the first position of a stream MAY be interpreted as a zero-width non-breaking space, and is not always a byte-order mark. For example, if a process splits a UTF-16 string into many parts, a part might begin with 0xFEFF because there was a zero-width non-breaking space at the beginning of that substring.
文字0xFEFFはゼロ幅改行なしスペースのためのセマンティクスを解釈しなければならないストリームの先頭以外の任意の位置に現れると、バイトオーダーマークとして解釈されてはならないことを理解することが重要です。ストリームの最初の位置にある文字0xFEFFはゼロ幅改行なしスペースとして解釈されるかもしれない、と常にバイトオーダーマークではありません。そのステートメントのcontrapositiveは常に真ではありません。プロセスは、多くの部分にUTF-16文字列を分割した場合、その部分文字列の先頭にゼロ幅改行なしスペースがあったので、例えば、一部は0xFEFFで始まるかもしれません。
The Unicode standard further suggests than an initial 0xFEFF character may be stripped before processing the text, the rationale being that such a character in initial position may be an artifact of the encoding (an encoding signature), not a genuine intended "ZERO WIDTH NON-BREAKING SPACE". Note that such stripping might affect an external process at a different layer (such as a digital signature or a count of the characters) that is relying on the presence of all characters in the stream.
ユニコード規格は、さらに、初期0xFEFF文字が、初期位置に、文字エンコード（符号化署名）のアーチファクトであり得ることである理論的根拠はなく、本物の意図「ZERO WIDTHテキストを処理する前に剥離することができるよりも示唆しているNON- 「SPACEを壊します。そのようなストリッピングは、ストリーム内のすべての文字の存在に依存している（例えば、デジタル署名や文字のカウントとして）異なる層に外部プロセスに影響を与える可能性があることに留意されたいです。
In particular, in UTF-16 plain text it is likely, but not certain, that an initial 0xFEFF is a signature. When concatenating two strings, it is important to strip out those signatures, because otherwise the resulting string may contain an unintended "ZERO WIDTH
具体的には、UTF-16、プレーンテキストでは、初期0xFEFFが署名であることを、そうではなく、一定です。 2つの文字列を連結する場合は、特に結果の文字列が意図しない「ZERO WIDTHを含めることがあるので、それらの署名を取り除くことが重要です
NON-BREAKING SPACE" at the connection point. Also, some specifications mandate an initial 0xFEFF character in objects labelled as UTF-16 and specify that this signature is not part of the object.
接続点におけるNON-BREAKING SPACE」。また、一部の仕様が任務UTF-16として標識し、この署名は、オブジェクトの一部ではないことを指定したオブジェクトの最初の0xFEFF文字。
Any labelling application that uses UTF-16 character encoding, and explicitly labels the text, and knows the serialization order of the characters in text, SHOULD label the text as either "UTF-16BE" or "UTF-16LE", whichever is appropriate based on the endianness of the text. This allows applications processing the text, but unable to look inside the text, to know the serialization definitively.
UTF-16文字エンコーディングを使用して、明示的にテキストをラベル、テキストの文字の直列化順序を知っている任意のラベリングアプリケーションは、基づいて、適切な方、「UTF-16BE」または「UTF-16LE」のいずれかのようなテキストにラベルを付けるべきですテキストのエンディアンに。これにより、アプリケーションは、テキストを処理できますが、決定的にシリアライズを知るために、テキスト内で見ることができません。
Text in the "UTF-16BE" charset MUST be serialized with the octets which make up a single 16-bit UTF-16 value in big-endian order. Systems labelling UTF-16BE text MUST NOT prepend a BOM to the text.
「UTF-16BE」文字セット内のテキストは、ビッグエンディアン順に1つの16ビットのUTF-16値を構成するオクテットをシリアル化する必要があります。システムラベリングUTF-16BEテキストはテキストにBOMを付加してはなりません。
Text in the "UTF-16LE" charset MUST be serialized with the octets which make up a single 16-bit UTF-16 value in little-endian order. Systems labelling UTF-16LE text MUST NOT prepend a BOM to the text.
「UTF-16LE」文字セット内のテキストは、リトルエンディアンの順序で1つの16ビットのUTF-16値を構成するオクテットをシリアル化する必要があります。システムラベルUTF-16LEテキストはテキストにBOMを付加してはなりません。
Any labelling application that uses UTF-16 character encoding, and puts an explicit charset label on the text, and does not know the serialization order of the characters in text, MUST label the text as "UTF-16", and SHOULD make sure the text starts with 0xFEFF.
UTF-16文字エンコーディングを使用して、テキストに明示的な文字セットのラベルを置き、テキストの文字の直列化順序を知らない、「UTF-16」などのテキストをラベル付けしなければならない、と確認する必要があります任意のラベリングアプリケーションテキストは0xFEFFで始まります。
An exception to the "SHOULD" rule of using "UTF-16BE" or "UTF-16LE" would occur with document formats that mandate a BOM in UTF-16 text, thereby requiring the use of the "UTF-16" tag only.
それによってのみ「UTF-16」タグの使用を必要とし、UTF-16テキストにBOMを強制文書フォーマットで起こる「UTF-16BE」または「UTF-16LE」を使用しての「SHOULD」ルールの例外。
When a program sees text labelled as "UTF-16BE", "UTF-16LE", or "UTF-16", it can make some assumptions, based on the labelling rules given in the previous section. These assumptions allow the program to then process the text.
プログラムは「UTF-16BE」、「UTF-16LE」、または「UTF-16」と表示テキストを見ているとき、それは前のセクションで与えられたラベリングルールに基づいて、いくつかの仮定を行うことができます。これらの仮定は、プログラムは、テキストを処理することができます。
Text labelled "UTF-16BE" can always be interpreted as being big-endian. The detection of an initial BOM does not affect de-serialization of text labelled as UTF-16BE. Finding 0xFF followed by 0xFE is an error since there is no Unicode character 0xFFFE.
「UTF-16BE」と表示されたテキストは、常にビッグエンディアンであると解釈することができます。最初のBOMの検出は、UTF-16BEとしてラベルテキストのデシリアライズには影響を与えません。何のUnicode文字0xFFFEというのがないので0xFEのに続いて発見0xFFではエラーです。
Text labelled "UTF-16LE" can always be interpreted as being little-endian. The detection of an initial BOM does not affect de-serialization of text labelled as UTF-16LE. Finding 0xFE followed by 0xFF is an error since there is no Unicode character 0xFFFE, which would be the interpretation of those octets under little-endian order.
「UTF-16LE」というテキストは常にリトルエンディアンであると解釈することができます。最初のBOMの検出は、UTF-16LEとしてラベルテキストのデシリアライズには影響を与えません。リトルエンディアンの順序の下でそれらのオクテットの解釈だろう何のUnicode文字0xFFFEというは、存在しないため0xFEのが0xFFに続いて検索するとエラーになります。
Text labelled with the "UTF-16" charset might be serialized in either big-endian or little-endian order. If the first two octets of the text is 0xFE followed by 0xFF, then the text can be interpreted as being big-endian. If the first two octets of the text is 0xFF followed by 0xFE, then the text can be interpreted as being little-endian. If the first two octets of the text is not 0xFE followed by 0xFF, and is not 0xFF followed by 0xFE, then the text SHOULD be interpreted as being big-endian.
「UTF-16」の文字セットで標識したテキストは、ビッグエンディアンかリトルエンディアン順のいずれかでシリアル化される可能性があります。テキストの最初の2つのオクテットが0xFEのが0xFFが続いている場合は、テキストはビッグエンディアンであると解釈することができます。テキストの最初の2つのオクテットが0xFFが0xFEのが続いている場合は、テキストはリトルエンディアンであると解釈することができます。テキストの最初の2つのオクテットが0xFEのが0xFFが続かない、とは0xFFが0xFEのが続いていない場合、テキストはビッグエンディアンであるとして解釈されるべきです。
All applications that process text with the "UTF-16" charset label MUST be able to read at least the first two octets of the text and be able to process those octets in order to determine the serialization order of the text. Applications that process text with the "UTF-16" charset label MUST NOT assume the serialization without first checking the first two octets to see if they are a big-endian BOM, a little-endian BOM, or not a BOM. All applications that process text with the "UTF-16" charset label MUST be able to interpret both big-endian and little-endian text.
プロセステキスト「UTF-16」との文字セットのラベルは、少なくともテキストの最初の2つのオクテットを読み、テキストの直列化順序を決定するために、それらのオクテットを処理することができることができなければならないすべてのアプリケーション。 「UTF-16」文字セットのラベルを持つプロセスのテキストは最初、彼らはビッグエンディアンBOM、リトルエンディアンBOM、またはないBOMをしているかどうかを確認するために最初の2つのオクテットをチェックせずにシリアル化を仮定してはいけませんアプリケーション。 「UTF-16」文字セットのラベルを持つプロセスのテキストはビッグエンディアンとリトルエンディアンテキストの両方を解釈できなければなりませんすべてのアプリケーション。
For the sake of example, let's suppose that there is a hieroglyphic character representing the Egyptian god Ra with character value 0x12345 (this character does not exist at present in Unicode).
例のために、の文字値0x12345（この文字はUnicodeで、現時点では存在しない）とエジプトの神Raが表す象形文字があると仮定してみましょう。
The examples here all evaluate to the phrase:
ここでの例は、すべてのフレーズに評価します。
*=Ra
＊＝ら
where the "*" represents the Ra hieroglyph (0x12345).
ここで、 "*" はRaはヒエログリフ（0x12345）を表しています。
Text labelled with UTF-16BE, without a BOM: D8 08 DF 45 00 3D 00 52 00 61
テキストBOMなしで、UTF-16BEで標識：D8 08 DF 45 00 3D 00 52 00 61
Text labelled with UTF-16LE, without a BOM: 08 D8 45 DF 3D 00 52 00 61 00
00 52 00 61 00 08 D8 45 DF 3D：BOMなしのUTF-16LEで標識されたテキスト、
Big-endian text labelled with UTF-16, with a BOM: FE FF D8 08 DF 45 00 3D 00 52 00 61
BOMで、UTF-16で標識したビッグエンディアンのテキスト：FE FF D8 08 DF 45 00 3D 00 52 00 61
Little-endian text labelled with UTF-16, with a BOM: FF FE 08 D8 45 DF 3D 00 52 00 61 00
リトルエンディアンのテキストはBOMで、UTF-16で標識された：00 52 00 61 00 FF FE 08 D8 45 DF 3Dを
ISO/IEC 10646 is updated from time to time by published amendments; similarly, different versions of the Unicode standard exist: 1.0, 1.1, 2.0, 2.1, and 3.0 as of this writing. Each new version replaces the previous one, but implementations, and more significantly data, are not updated instantly.
ISO / IEC 10646は、時間から公表改正により、時刻に更新されます。同様に、ユニコード規格の異なるバージョンが存在する：1.0、1.1、2.0、2.1、及びこれを書いているとして3.0。それぞれの新しいバージョンは、以前のものに置き換えられますが、実装、およびより大幅データは、即座に更新されません。
In general, the changes amount to adding new characters, which does not pose particular problems with old data. Amendment 5 to ISO/IEC 10646, however, has moved and expanded the Korean Hangul block, thereby making any previous data containing Hangul characters invalid under the new version. Unicode 2.0 has the same difference from Unicode 1.1. The official justification for allowing such an incompatible change was that no significant implementations and data containing Hangul existed, a statement that is likely to be true but remains unprovable. The incident has been dubbed the "Korean mess", and the relevant committees have pledged to never, ever again make such an incompatible change.
一般的には、変更が古いデータで特定の問題を提起しない、新しい文字を追加することに達します。 ISO / IEC 10646への改正5は、しかし、移動したことにより、新しいバージョンで無効ハングル文字を含む任意の以前のデータを作り、韓国語ハングルのブロックを拡大しました。ユニコード2.0は、Unicode 1.1から同じ違いがあります。こうした互換性のない変更を可能にするための公式の正当化は、ハングルを含む有意な実装とデータは、真である可能性が高いですが、unprovableまま声明を存在しないということでした。事件は「韓国の混乱」と呼ばれており、関連する委員会は、決して、二度とこうした互換性のない変更を行うことを約束しています。
New versions, and in particular any incompatible changes, have consequences regarding MIME character encoding labels, to be discussed in Appendix A.
新バージョンでは、特に互換性のない変更は、MIME文字エンコーディングのラベルに関する結果は、付録Aで説明することがあります
IANA is to register the character sets found in Appendixes A.1, A.2, and A.3 according to RFC 2278, using registration templates found in those appendixes.
IANAはこれらの付録で見つかった登録テンプレートを使って、RFC 2278によると付録A.1、A.2、およびA.3で見つかった文字セットを登録することです。
UTF-16 is based on the ISO 10646 character set, which is frequently being added to, as described in Section 6 and Appendix A of this document. Processors must be able to handle characters that are not defined at the time that the processor was created in such a way as to not allow an attacker to harm a recipient by including unknown characters.
UTF-16は、このドキュメントのセクション6および付録Aで説明したように、頻繁に追加されているISO 10646文字セットに基づいています。プロセッサは、プロセッサが、攻撃者が不明な文字を含めることによって、受信者に害を与えることはできませような方法で作成された時点で定義されていない文字を処理できなければなりません。
Processors that handle any type of text, including text encoded as UTF-16, must be vigilant in checking for control characters that might reprogram a display terminal or keyboard. Similarly, processors that interpret text entities (such as looking for embedded programming code), must be careful not to execute the code without first alerting the recipient.
UTF-16としてエンコードされたテキストを含むテキストのいずれかのタイプを処理プロセッサは、ディスプレイ端末やキーボードを再プログラムするかもしれない制御文字のチェックに警戒する必要があります。同様に、（例えば、埋め込まれたプログラミングコードを探しなど）テキストエンティティを解釈するプロセッサは、最初の受信者に警告することなく、コードを実行しないように注意しなければなりません。
Text in UTF-16 may contain special characters, such as the OBJECT REPLACEMENT CHARACTER (0xFFFC), that might cause external processing, depending on the interpretation of the processing program and the availability of an external data stream that would be executed. This external processing may have side-effects that allow the sender of a message to attack the receiving system.
UTF-16のテキストは、このような処理プログラムの解釈と実行されます外部のデータ・ストリームの可用性に応じて、外部処理が発生する可能性がありますOBJECT交換CHARACTER（0xFFFC）、などの特殊文字を含んでいてもよいです。この外部処理は、メッセージの送信者が受信システムを攻撃することを可能にする副作用を有することができます。
Implementors of UTF-16 need to consider the security aspects of how they handle illegal UTF-16 sequences (that is, sequences involving surrogate pairs that have illegal values or unpaired surrogates). It is conceivable that in some circumstances an attacker would be able to exploit an incautious UTF-16 parser by sending it an octet sequence that is not permitted by the UTF-16 syntax, causing it to behave in some anomalous fashion.
UTF-16の実装者は、彼らが（不正な値または不対サロゲートを持ってサロゲートペアを含むことがあり、シーケンス）違法なUTF-16シーケンスをどのように処理するかのセキュリティ面を考慮する必要があります。いくつかの状況で、攻撃者は、それはいくつかの異常なやり方で行動させ、それをUTF-16構文によって許可されていないオクテットのシーケンスを送信することにより、事も無げUTF-16のパーサを利用することができるだろうと考えられます。
[CHARPOLICY] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[CHARPOLICY] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[CHARSET-REG] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2278, January 1998.
[CHARSET-REG]解放され、N.とJ.ポステル、 "IANA文字セット登録手順"、BCP 19、RFC 2278、1998年1月。
[HTTP-1.1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP-1.1]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、「ハイパーテキスト転送プロトコル - HTTP / 1.1 」、RFC 2616、1999年6月。
[ISO-10646] ISO/IEC 10646-1:1993. International Standard -- Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. 22 amendments and two technical corrigenda have been published up to now. UTF-16 is described in Annex Q, published as Amendment 1. Many other amendments are currently at various stages of standardization. A second edition is in preparation, probably to be published in 2000; in this new edition, UTF-16 will probably be described in Annex C.
[ISO-10646] ISO / IEC 10646-1：1993。国際規格 - 情報技術 - ユニバーサルマルチオクテット符号化文字セット（UCS） - 第1部：アーキテクチャと基本多言語面。 22の改正及び2本の技術正誤表は、今までに発表されています。 UTF-16は、1。他の多くの改正は、標準化の様々な段階で現在の改正として出版され、附属書Qに記載されています。第二版は、おそらく2000年に出版されるために、準備中です。この新版では、UTF-16は、おそらく、附属書Cで説明します
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[MUSTSHOULD]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[UNICODE] The Unicode Consortium, "The Unicode Standard -- Version 3.0", ISBN 0-201-61633-5. Described at
[UNICODE]ユニコードコンソーシアム、 "Unicode標準 - バージョン3.0"、ISBN 0-201-61633-5。で説明
<http://www.unicode.org/unicode/standard/versions/Unicode3.0.html>.
＜ｈっｔｐ：／／ｗっｗ。うにこで。おｒｇ／うにこで／ｓたんだｒｄ／ゔぇｒしおんｓ／うにこで３。０。ｈｔｍｌ＞。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[UTF-8] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 2279、1998年1月。
[WORKSHOP] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, R., Crispin., M. and P. Svanberg, "Report of the IAB Character Set Workshop", RFC 2130, April 1997.
【WORKSHOP]ウイダー、C.、プレストン、C.、シモンセン、K.、Alvestrand、H.、アトキンソン、R.、クリスピン。、M.およびP. Svanberg、 "ワークショップを設定IAB文字の報告"、RFC 2130 、1997年4月。
Deborah Goldsmith wrote a great deal of the initial wording for this specification. Martin Duerst proposed numerous significant changes. Other significant contributors include:
デボラ・ゴールドスミスは、この仕様書のための最初の文言の多くを書きました。マーティン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
マティAlloucheウォルト・ダニエルズマーク・デイビスネッドフリードAsmusフライタークロイドHonomichlダンケーゲル村田誠ラリーMasinterマーカス・シーラーKeldシモンセンケンウィスラー
Some of the text in this specification was copied from [UTF-8], and that document was worked on by many people. Please see the acknowledgments section in that document for more people who may have contributed indirectly to this document.
この仕様のテキストの一部は、[UTF-8]からコピーし、その文書には、多くの人々が作業ました。このドキュメントに間接的に貢献している可能性がより多くの人々のためにその文書の謝辞のセクションを参照してください。
A. Charset registrations
A.文字セット登録
This memo is meant to serve as the basis for registration of three MIME charsets [CHARSET-REG]. The proposed charsets are "UTF-16BE", "UTF-16LE", and "UTF-16". These strings label objects containing text consisting of characters from the repertoire of ISO/IEC 10646 including all amendments at least up to amendment 5 (Korean block), encoded to a sequence of octets using the encoding and serialization schemes outlined above.
このメモは、三のMIME文字セット[CHARSET-REG]の登録のための基礎として役立つことを意味します。提案されている文字セットは "UTF-16BE"、 "UTF-16LE"、および "UTF-16" です。上記で概説した符号化および直列化スキームを使用して、オクテットの配列にコードされる少なくとも改正5（韓国のブロック）までのすべての修正を含むISO / IEC 10646のレパートリーの文字からなるテキストを含むこれらの文字列ラベルオブジェクト。
Note that "UTF-16BE", "UTF-16LE", and "UTF-16" are NOT suitable for use in media types under the "text" top-level type, because they do not encode line endings in the way required for MIME "text" media types. An exception to this is HTTP, which uses a MIME-like mechanism, but is exempt from the restrictions on the text top-level type (see section 19.4.2 of HTTP 1.1 [HTTP-1.1]).
彼らはのために必要な方法で、行末をコードしていないので、「UTF-16BE」、「UTF-16LE」、および「UTF-16」は、「テキスト」トップレベルタイプの下にメディアタイプでの使用に適していないことに注意してくださいMIME "text" のメディアタイプ。これに対する例外はMIMEのようなメカニズムを使用してHTTPであるが、テキストトップレベルタイプの制限から除外され（HTTP 1.1 [HTTP-1.1]のセクション19.4.2を参照されたいです）。
It is noteworthy that the labels described here do not contain a version identification, referring generically to ISO/IEC 10646. This is intentional, the rationale being as follows:
次のように根拠があること、ISO / IEC 10646に一般的に参照する。これは意図的なものです、ここで説明したラベルは、バージョンIDが含まれていないことは注目に値します。
A MIME charset is designed to give just the information needed to interpret a sequence of bytes received on the wire into a sequence of characters, nothing more (see RFC 2045, section 2.2, in [MIME]). As long as a character set standard does not change incompatibly, version numbers serve no purpose, because one gains nothing by learning from the tag that newly assigned characters may be received that one doesn't know about. The tag itself doesn't teach anything about the new characters, which are going to be received anyway.
MIME文字セットはバイトのシーケンスを解釈するために必要な情報だけを与えるように設計されている（[MIME]で、RFC 2045、セクション2.2を参照）、文字のシーケンスにワイヤ上では何も受信しません。新しく割り当てられた文字は、1が知らないことを受信することができ、タグから学ぶずつゲイン何ので、限り文字集合規格は互換性のない変更されないように、バージョン番号が、何の目的を果たしていません。タグ自体はとにかく受信されようとしている新しい文字、については何も教えていません。
Hence, as long as the standards evolve compatibly, the apparent advantage of having labels that identify the versions is only that, apparent. But there is a disadvantage to such version-dependent labels: when an older application receives data accompanied by a newer, unknown label, it may fail to recognize the label and be completely unable to deal with the data, whereas a generic, known label would have triggered mostly correct processing of the data, which may well not contain any new characters.
したがって、限り標準が互換性進化として、バージョンを識別するラベルを有するの見かけの利点はそれだけで、明らかです。しかし、このようなバージョン依存のラベルに欠点がある：古いアプリケーションが新しい、未知のラベルを伴ってデータを受信したとき、それはラベルを認識し、データを扱うことが完全にできないことに失敗する可能性があり、一般的な、知られているラベルのに対しでしょうよく、新しい文字を含めることはできませんデータの大部分は正しい処理を引き起こしました。
The "Korean mess" (ISO/IEC 10646 amendment 5) is an incompatible change, in principle contradicting the appropriateness of a version independent MIME charset as described above. But the compatibility problem can only appear with data containing Korean Hangul characters encoded according to Unicode 1.1 (or equivalently ISO/IEC 10646 before amendment 5), and there is arguably no such data to worry about, this being the very reason the incompatible change was deemed acceptable.
「韓国の混乱」（ISO / IEC 10646改正5）は、上述のようにバージョンの独立したMIME文字セットの妥当性を矛盾原理的に互換性のない変化です。しかし、互換性の問題は（修正5の前または同等にISO / IEC 10646）は、Unicode 1.1に基づいてエンコードされた韓国語のハングル文字を含むデータを表示することができ、そして心配するようなデータが間違いなくありません、これは互換性のない変更だった非常に理由であること許容できるとみなされます。
In practice, then, a version-independent label is warranted, provided the label is understood to refer to all versions after Amendment 5, and provided no incompatible change actually occurs. Should incompatible changes occur in a later version of ISO/IEC 10646, the MIME charsets defined here will stay aligned with the previous version until and unless the IETF specifically decides otherwise.
実際には、次に、バージョンに依存しないラベルが保証され、ラベルが改正5後のすべてのバージョンを指すと理解し、実際に発生全く互換性のない変更が設けられていないが提供されます。互換性のない変更がISO / IEC 10646の以降のバージョンで発生する必要があり、ここで定義されたMIME文字セットは、までとIETFは、特にそうでないことを決定しない限り、以前のバージョンに合わせたままになります。
A.1 Registration for UTF-16BE
UTF-16BEのためA.1登録
To: ietf-charsets@iana.org Subject: Registration of new charset
To：ietf-charsets@iana.org件名：新しい文字セットの登録
Charset name(s): UTF-16BE
文字セット名（複数可）：UTF-16BE
Published specification(s): This specification
公開された仕様（S）：この仕様
Suitable for use in MIME content types under the "text" top-level type: No
「テキスト」トップレベルタイプ下のMIMEコンテンツタイプに使用するのに適した：いいえ
Person & email address to contact for further information: Paul Hoffman <phoffman@imc.org> Francois Yergeau <fyergeau@alis.com>
人とEメールアドレスは、詳細のために連絡する：ポール・ホフマン<phoffman@imc.org>フランソワYergeau <fyergeau@alis.com>
A.2 Registration for UTF-16LE
UTF-16LE用A.2登録
To: ietf-charsets@iana.org Subject: Registration of new charset
To：ietf-charsets@iana.org件名：新しい文字セットの登録
Charset name(s): UTF-16LE
文字セット名（複数可）：UTF-16LE
Published specification(s): This specification
公開された仕様（S）：この仕様
Suitable for use in MIME content types under the "text" top-level type: No
「テキスト」トップレベルタイプ下のMIMEコンテンツタイプに使用するのに適した：いいえ
Person & email address to contact for further information: Paul Hoffman <phoffman@imc.org> Francois Yergeau <fyergeau@alis.com>
人とEメールアドレスは、詳細のために連絡する：ポール・ホフマン<phoffman@imc.org>フランソワYergeau <fyergeau@alis.com>
A.3 Registration for UTF-16
UTF-16用A.3登録
To: ietf-charsets@iana.org Subject: Registration of new charset
To：ietf-charsets@iana.org件名：新しい文字セットの登録
Charset name(s): UTF-16
文字セット名（複数可）：UTF-16
Published specification(s): This specification
公開された仕様（S）：この仕様
Suitable for use in MIME content types under the "text" top-level type: No
「テキスト」トップレベルタイプ下のMIMEコンテンツタイプに使用するのに適した：いいえ
Person & email address to contact for further information: Paul Hoffman <phoffman@imc.org> Francois Yergeau <fyergeau@alis.com>
人とEメールアドレスは、詳細のために連絡する：ポール・ホフマン<phoffman@imc.org>フランソワYergeau <fyergeau@alis.com>
Authors' Addresses
著者のアドレス
Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 USA
ポール・ホフマンインターネットメールコンソーシアムセグレ127場所サンタクルス、CA 95060 USA
EMail: phoffman@imc.org
メールアドレス：phoffman@imc.org
Francois Yergeau Alis Technologies 100, boul. Alexis-Nihon, Suite 600 Montreal QC H4M 2P2 Canada
フランソワYergeauアリス・テクノロジーズ100、BOUL。アレクシス日本、スイート600モントリオールQC H4L 2P2カナダ
EMail: fyergeau@alis.com
メールアドレス：fyergeau@alis.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。