Network Working Group F. Yergeau
Request for Comments: 3629 Alis Technologies
STD: 63 November 2003
Obsoletes: 2279
Category: Standards Track
UTF-8, a transformation format of ISO 10646
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.
ISO / IEC 10646-1は、世界の書記体系の大部分を含むユニバーサル文字セット（UCS）と呼ばれる大規模な文字セットを定義します。 UCSの原案エンコーディングは、しかし、現在の多くのアプリケーションとプロトコルと互換性がありませんでしたが、これはUTF-8の開発、このメモのオブジェクトにつながっています。 UTF-8は、ファイルシステム、パーサとUS-ASCII値に依存しているが、他の値に対して透明である他のソフトウェアとの互換性を提供し、完全なUS-ASCIIの範囲を維持する特性を有しています。このメモは廃止し、RFC 2279に置き換えられます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational conventions . . . . . . . . . . . . . . . . . . . . 3
3. UTF-8 definition . . . . . . . . . . . . . . . . . . . . . . . 4
4. Syntax of UTF-8 Byte Sequences . . . . . . . . . . . . . . . . 5
5. Versions of the standards . . . . . . . . . . . . . . . . . . 6
6. Byte order mark (BOM) . . . . . . . . . . . . . . . . . . . . 6
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. MIME registration . . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
12. Changes from RFC 2279 . . . . . . . . . . . . . . . . . . . . 11
13. Normative References . . . . . . . . . . . . . . . . . . . . . 12
14. Informative References . . . . . . . . . . . . . . . . . . . . 12
15. URI's . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
16. Intellectual Property Statement . . . . . . . . . . . . . . . 13
17. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
18. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14
ISO/IEC 10646 [ISO.10646] defines a large character set called the Universal Character Set (UCS), which encompasses most of the world's writing systems. The same set of characters is defined by the Unicode standard [UNICODE], which further defines additional character properties and other application details of great interest to implementers. Up to the present time, changes in Unicode and amendments and additions 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.
ISO / IEC 10646は、[ISO.10646]世界の書記体系のほとんどを網羅ユニバーサル文字セット（UCS）と呼ばれる大規模な文字セットを定義します。文字の同じセットは、さらに追加の文字特性および実装に大きな関心のある他のアプリケーションの詳細を定義するUnicode標準[UNICODE]、によって定義されます。文字レパートリーとコードポイントの割り当てが同期に残っているように、現在まで、UnicodeおよびISO / IEC 10646の修正および追加の変化は、互いを追跡しました。関連する標準化委員会は、この非常に便利な同期を維持するためにコミットしています。
ISO/IEC 10646 and Unicode define several encoding forms of their common repertoire: UTF-8, UCS-2, UTF-16, UCS-4 and UTF-32. In an encoding form, each character is represented as one or more encoding units. All standard UCS encoding forms except UTF-8 have an encoding unit larger than one octet, making them hard to use in many current applications and protocols that assume 8 or even 7 bit characters.
UTF-8、UCS-2、UTF-16、UCS-4、UTF-32：ISO / IEC 10646とUnicodeは、それらの共通のレパートリーのいくつかの符号化形式を定義します。符号化形式で、各文字は、一の以上の符号化単位として表されます。 UTF-8以外のすべての標準のUCSのエンコード形式は、彼らが硬い8あるいは7ビット文字を想定して、現在の多くのアプリケーションとプロトコルで使用すること、1つのオクテットよりも大きな符号化ユニットを持っています。
UTF-8, the object of this memo, has a one-octet encoding unit. It uses all bits of an octet, but has the quality of preserving the full US-ASCII [US-ASCII] range: US-ASCII characters are encoded in one octet having the normal US-ASCII value, and any octet with such a value can only stand for a US-ASCII character, and nothing else.
UTF-8は、このメモの目的は、1オクテットの符号化部を有しています。これは、オクテットのすべてのビットを使用するが、完全なUS-ASCII [US-ASCII]の範囲を維持する品質を有している：US-ASCII文字は通常US-ASCII値を有する1つのオクテットで符号化され、そしてそのような値を有する任意のオクテット唯一のUS-ASCII文字、そして他には何のために立つことができます。
UTF-8 encodes UCS characters as a varying number of octets, where the number of octets, and the value of each, depend on the integer value assigned to the character in ISO/IEC 10646 (the character number, a.k.a. code position, code point or Unicode scalar value). This encoding form has the following characteristics (all values are in hexadecimal):
UTF-8は、オクテットの数、及びそれぞれの値は、ISO / IEC 10646の文字（文字番号、別名コードの位置、コードポイントに割り当てられた整数値に依存オクテットの可変数としてUCS文字をエンコードまたはUnicodeスカラー値）。この符号化形式は、以下の特性を（すべての値は16進数である）を有します。
o Character numbers from U+0000 to U+007F (US-ASCII repertoire) correspond to octets 00 to 7F (7 bit US-ASCII values). A direct consequence is that a plain ASCII string is also a valid UTF-8 string.
U + 0000からU + 007F（US-ASCIIレパートリー）7F（7ビットUS-ASCII値）オクテット00に対応するようにO文字数。直接の結果は、プレーンなASCII文字列も有効なUTF-8文字列であるということです。
o US-ASCII octet values do not appear otherwise in a UTF-8 encoded character stream. This provides compatibility with file systems or other software (e.g., the printf() function in C libraries) that parse based on US-ASCII values but are transparent to other values.
O US-ASCIIオクテット値はUTF-8でエンコードされた文字ストリームにはそれ以外の場合は表示されません。これは、ファイル・システムまたは他のソフトウェアとの互換性を提供する（例えば、Cライブラリ内のprintf（）関数）US-ASCII値に基づいて、他の値に対して透明であるパース。
o Round-trip conversion is easy between UTF-8 and other encoding forms.
Oのラウンドトリップ変換は、UTF-8および他の符号化形式の間で簡単です。
o The first octet of a multi-octet sequence indicates the number of octets in the sequence.
マルチオクテットシーケンスの最初のオクテットシーケンスoにおけるオクテットの数を示します。
o The octet values C0, C1, F5 to FF never appear.
FFへのオクテット値C0、C1、F5 Oが表示されません。
o Character boundaries are easily found from anywhere in an octet stream.
Oの文字の境界はどこでも手軽オクテットストリームの中から発見されました。
o The byte-value lexicographic sorting order of UTF-8 strings is the same as if ordered by character numbers. Of course this is of limited interest since a sort order based on character numbers is almost never culturally valid.
oをUTF-8文字列のバイト値辞書式ソート順は、文字番号で注文した場合と同じです。文字番号に基づいてソート順がほとんどない文化的に有効ではありませんので、もちろん、これは限られた関心があります。
o The Boyer-Moore fast search algorithm can be used with UTF-8 data.
Oボイヤー - ムーア高速検索アルゴリズムがUTF-8のデータを使用することができます。
o UTF-8 strings can be fairly reliably recognized as such by a simple algorithm, i.e., the probability that a string of characters in any other encoding appears as valid UTF-8 is low, diminishing with increasing string length.
O UTF-8文字列は、かなり確実に単純なアルゴリズム、すなわち、他のエンコーディングの文字列が有効なUTF-8が増加文字列の長さと減少、低い出現確率によってそのように認識することができます。
UTF-8 was devised in September 1992 by Ken Thompson, guided by design criteria specified by Rob Pike, with the objective of defining a UCS transformation format usable in the Plan9 operating system in a non-disruptive manner. Thompson's design was stewarded through standardization by the X/Open Joint Internationalization Group XOJIG (see [FSS_UTF]), bearing the names FSS-UTF (variant FSS/UTF), UTF-2 and finally UTF-8 along the way.
UTF-8は、非破壊的方法でPlan9オペレーティングシステムで使用可能なUCS変換フォーマットを定義する目的で、ロブ・パイクによって指定された設計基準によって導か、ケン・トンプソンによって1992年9月考案されました。トンプソンのデザインは、道に沿って名前FSS-UTF（バリアントFSS / UTF）、UTF-2、最終的にはUTF-8を保持する、（[FSS_UTF]参照）は、X / Open共同国際グループXOJIGによって標準化によるstewardedました。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
UCS characters are designated by the U+HHHH notation, where HHHH is a string of from 4 to 6 hexadecimal digits representing the character number in ISO/IEC 10646.
UCS文字はHHHHは、ISO / IEC 10646の文字の数を表すから4〜6桁の16進数の文字列であるU + HHHH表記によって指定されます。
UTF-8 is defined by the Unicode Standard [UNICODE]. Descriptions and formulae can also be found in Annex D of ISO/IEC 10646-1 [ISO.10646]
UTF-8は、Unicode標準[UNICODE]で定義されます。説明および数式はまた、ISO / IEC 10646-1 [ISO.10646]の付録Dに見出すことができます
In UTF-8, characters from the U+0000..U+10FFFF range (the UTF-16 accessible range) are encoded using sequences of 1 to 4 octets. The only octet of a "sequence" of one has the higher-order bit set to 0, the remaining 7 bits being used to encode the character number. In a sequence of n octets, n>1, the initial octet has the n higher-order bits set to 1, followed by a bit set to 0. The remaining bit(s) of that octet contain bits from the number of the character to be encoded. The following octet(s) all have the higher-order bit set to 1 and the following bit set to 0, leaving 6 bits in each to contain bits from the character to be encoded.
UTF-8で、U + 0000..U + 10FFFFの範囲（UTF-16アクセス可能な範囲）から文字が1〜4オクテットのシーケンスを用いて符号化されます。一方の「配列」の唯一のオクテットは0に設定上位ビット、文字番号を符号化するために使用され、残りの7ビットを有します。 nオクテットのシーケンス、N> 1において、最初のオクテットは、オクテットの残りのビット（s）は、文字の数からビットを含む0に設定ビットに続く1にセットN上位ビットを有しますエンコードします。次のオクテット（S）すべてが符号化されるキャラクタからのビットを含むように各6ビットを残し、1に設定され、上位ビットが0に設定され、次のビットを有します。
The table below summarizes the format of these different octet types. The letter x indicates bits available for encoding bits of the character number.
下の表は、これらの異なるオクテットタイプのフォーマットをまとめました。文字xは文字の数のビットを符号化するために利用可能なビットを示しています。
Char. number range | UTF-8 octet sequence
(hexadecimal) | (binary)
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
Encoding a character to UTF-8 proceeds as follows:
次のようにUTF-8進行に文字をコードします：
1. Determine the number of octets required from the character number and the first column of the table above. It is important to note that the rows of the table are mutually exclusive, i.e., there is only one valid way to encode a given character.
1.文字の数及び上記の表の最初の列から必要なオクテットの数を決定します。指定された文字をエンコードするための唯一の有効な方法があり、テーブルの行は、すなわち、相互に排他的であることに注意することが重要です。
2. Prepare the high-order bits of the octets as per the second column of the table.
2.表の第2列に従ってオクテットの上位ビットを準備します。
3. Fill in the bits marked x from the bits of the character number, expressed in binary. Start by putting the lowest-order bit of the character number in the lowest-order position of the last octet of the sequence, then put the next higher-order bit of the character number in the next higher-order position of that octet, etc. When the x bits of the last octet are filled in, move on to the next to last octet, then to the preceding one, etc. until all x bits are filled in.
3ビットに入力2進数で表す、キャラクタ数のビットからXをマーク。など、そのオクテットの次の高次の位置に文字番号の次の上位ビットを入れ、その後、シーケンスの最後のオクテットの最下位位置の文字番号の最下位ビットを入れて起動します。最後のオクテットのxビットが充填され、その後、前述のいずれかに、最後のオクテット隣に移動し、等すべてのXビットが充填されるまで。
The definition of UTF-8 prohibits encoding character numbers between U+D800 and U+DFFF, which are reserved for use with the UTF-16 encoding form (as surrogate pairs) and do not directly represent characters. When encoding in UTF-8 from UTF-16 data, it is necessary to first decode the UTF-16 data to obtain character numbers, which are then encoded in UTF-8 as described above. This contrasts with CESU-8 [CESU-8], which is a UTF-8-like encoding that is not meant for use on the Internet. CESU-8 operates similarly to UTF-8 but encodes the UTF-16 code values (16-bit quantities) instead of the character number (code point). This leads to different results for character numbers above 0xFFFF; the CESU-8 encoding of those characters is NOT valid UTF-8.
UTF-8の定義は（サロゲートペアとして）UTF-16エンコード形式で使用するために予約されており、直接文字を表すものではないU + D800とU + DFFF間符号化文字番号を禁止します。 UTF-16データから、UTF-8で符号化するとき、最初に上述のようにUTF-8でエンコードされた文字の数を得るために、UTF-16データを復号化する必要があります。これは、インターネット上で使用するためのものではありませんUTF-8のようなエンコーディングであるCESU-8 [CESU-8]、とは対照的です。 CESU-8は、UTF-8と同様に動作するが、UTF-16コード値（16ビットの量）の代わりに、文字番号（コードポイント）をコードします。これは0xFFFFの上の文字番号の異なる結果につながります。これらの文字のCESU-8エンコーディングは、有効なUTF-8ではありません。
Decoding a UTF-8 character proceeds as follows:
次のようにUTF-8文字の進行をデコードします：
1. Initialize a binary number with all bits set to 0. Up to 21 bits may be needed.
1. 21ビット必要とされるかもしれないまで0に設定されているすべてのビットの2進数を初期化します。
2. Determine which bits encode the character number from the number of octets in the sequence and the second column of the table above (the bits marked x).
2.配列と上記の表の2列目のオクテットの数から文字数を（ビットXをマーク）コードするビットを決定します。
3. Distribute the bits from the sequence to the binary number, first the lower-order bits from the last octet of the sequence and proceeding to the left until no x bits are left. The binary number is now equal to the character number.
NO xビットが残っていないまで、3進数、左側に配列及び手続の最後のオクテットから第1の下位ビットにシーケンスからのビットを配布。 2進数になりまし文字数に等しいです。
Implementations of the decoding algorithm above MUST protect against decoding invalid sequences. For instance, a naive implementation may decode the overlong UTF-8 sequence C0 80 into the character U+0000, or the surrogate pair ED A1 8C ED BE B4 into U+233B4. Decoding invalid sequences may have security consequences or cause other problems. See Security Considerations (Section 10) below.
上記復号化アルゴリズムの実装は、無効なシーケンスをデコードから保護しなければなりません。例えば、ナイーブな実装は文字U + 0000、またはU + 233B4にED A1 8C EDはB4 BEサロゲートペアにすぎるUTF-8配列C0 80を復号することができます。無効なシーケンスをデコードすることは、セキュリティ上の影響を持っているか、他の問題を引き起こす可能性があります。以下のセキュリティに関する考慮事項（第10節）を参照してください。
For the convenience of implementors using ABNF, a definition of UTF-8 in ABNF syntax is given here.
ABNF、ABNF構文でUTF-8の定義を使用して実装者の利便性のために、ここで与えられています。
A UTF-8 string is a sequence of octets representing a sequence of UCS characters. An octet sequence is valid UTF-8 only if it matches the following syntax, which is derived from the rules for encoding UTF-8 and is expressed in the ABNF of [RFC2234].
UTF-8文字列は、UCS文字のシーケンスを表すオクテットのシーケンスです。オクテットシーケンスは、UTF-8を符号化するためのルールに由来するとのABNF [RFC2234]で表され、次の構文を、一致した場合にのみ有効なUTF-8です。
UTF8-octets = *( UTF8-char ) UTF8-char = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4 UTF8-1 = %x00-7F UTF8-2 = %xC2-DF UTF8-tail
UTF8-オクテット= *（UTF8-CHAR）UTF8-CHAR = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4 UTF8-1 =％x00-7F UTF8-2 =％XC2-DF UTF8テール
UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) / %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail ) UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) / %xF4 %x80-8F 2( UTF8-tail ) UTF8-tail = %x80-BF
UTF8-3 =％xE0％XA0-BF UTF8テール/％XE1-EC 2（UTF8-テール）/％XED％x80-9F UTF8テール/％XEE-EF 2（UTF8-尾）UTF8-4 =％ XF0％X90-BF 2（UTF8-テール）/％XF1-F3 3（UTF8-テール）/％XF4％x80-8F 2（UTF8-尾）UTF8-尾=％のX80-BF
NOTE -- The authoritative definition of UTF-8 is in [UNICODE]. This grammar is believed to describe the same thing Unicode describes, but does not claim to be authoritative. Implementors are urged to rely on the authoritative source, rather than on this ABNF.
注 - UTF-8の正式な定義は[UNICODE]です。この文法は、Unicodeが記述する同じことを記述するために考えられているが、信頼できると主張しません。実装者は、信頼できるソースではなく、このABNFに頼るように促しています。
ISO/IEC 10646 is updated from time to time by publication of amendments and additional parts; similarly, new versions of the Unicode standard are published over time. Each new version obsoletes and replaces the previous one, but implementations, and more significantly data, are not updated instantly.
ISO / IEC 10646は、時間の修正および追加部品の出版によって時間に更新されます。同様に、Unicode標準の新バージョンでは、時間の経過とともに公開されています。それぞれの新しいバージョンでは廃止と前のものに置き換えられますが、実装、およびより大幅データは、即座に更新されません。
In general, the changes amount to adding new characters, which does not pose particular problems with old data. In 1996, Amendment 5 to the 1993 edition of ISO/IEC 10646 and Unicode 2.0 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 justification for allowing such an incompatible change was that there were no major implementations and no significant amounts of data containing Hangul. The incident has been dubbed the "Korean mess", and the relevant committees have pledged to never, ever again make such an incompatible change (see Unicode Consortium Policies [1]).
一般的には、変更が古いデータで特定の問題を提起しない、新しい文字を追加することに達します。 1996年には、ISO / IEC 10646とUnicode 2.0の1993年版への改正5が移動し、それによって新しいバージョンで無効ハングル文字を含む任意の以前のデータを作り、韓国語ハングルブロックを拡大しました。ユニコード2.0は、Unicode 1.1から同じ違いがあります。こうした互換性のない変更を可能にするための正当化には、主要な実装とハングルを含むデータの有意な量が存在しないということでした。事件は「韓国の混乱」と呼ばれており、関連する委員会は、決して、二度とこうした互換性のない変更（[1]のUnicodeコンソーシアムのポリシーを参照）を作成することを約束しています。
New versions, and in particular any incompatible changes, have consequences regarding MIME charset labels, to be discussed in MIME registration (Section 8).
新バージョンでは、特に互換性のない変更は、MIME登録（セクション8）で議論されるMIME文字セットのラベルに関する結果を、持っています。
The UCS character U+FEFF "ZERO WIDTH NO-BREAK SPACE" is also known informally as "BYTE ORDER MARK" (abbreviated "BOM"). This character can be used as a genuine "ZERO WIDTH NO-BREAK SPACE" within text, but the BOM name hints at a second possible usage of the character: to prepend a U+FEFF character to a stream of UCS characters as a "signature". A receiver of such a serialized stream may then use the initial character as a hint that the stream consists of UCS characters and also to recognize which UCS encoding is involved and, with encodings having a multi-octet encoding unit, as a way to recognize the serialization order of the octets. UTF-8 having a single-octet encoding unit, this last function is useless and the BOM will always appear as the octet sequence EF BB BF.
UCS文字U + FEFF "ZERO WIDTH NO-BREAK SPACEの" も "バイトオーダーマーク"（略して "BOM"）として非公式に知られています。この文字は、テキスト内の本物の「ZERO WIDTH NO-BREAKのSPACE」として使用することができますが、BOMの名前は、文字の第二の可能な用法でヒント：「シグネチャとしてUCS文字のストリームにU + FEFFの文字を付加します」。このようなシリアル化されたストリームの受信機は、ストリームがUCS文字で構成されていることをヒントとして最初の文字を使用することができ、また、認識する方法として、符号化方式は、マルチオクテット符号化部を有する、関与するUCS符号化認識としますオクテットの直列化順序。 UTF-8シングルオクテット符号化部を備え、この最後の機能は無用であり、BOMは常にオクテット配列EF BB BFとして表示されます。
It is important to understand that the character U+FEFF 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 signature. When interpreted as a signature, the Unicode standard suggests than an initial U+FEFF character may be stripped before processing the text. Such stripping is necessary in some cases (e.g., when concatenating two strings, because otherwise the resulting string may contain an unintended "ZERO WIDTH NO-BREAK SPACE" at the connection point), but 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. It is therefore RECOMMENDED to avoid stripping an initial U+FEFF interpreted as a signature without a good reason, to ignore it instead of stripping it when appropriate (such as for display) and to strip it only when really necessary.
文字U + FEFFはゼロ幅改行なしスペースのためのセマンティクスを解釈しなければならないストリームの先頭以外の任意の位置に現れると、署名と解釈してはならないことを理解することが重要です。署名として解釈する際、ユニコード規格は、初期U + FEFF文字がテキストを処理する前に剥離することができるよりも示唆しています。そのようなストリッピングは、（（2つの文字列を連結するときに、さもなければ結果の文字列が接続点に意図しない「ZERO WIDTH NO-BREAK空間」を含むことができるので、例えば、）いくつかの場合には必要であるが、異なる層で外部プロセスに影響を与える可能性ストリーム内のすべての文字の存在に依存しているデジタル署名又は文字の数）として。従って、（例えばディスプレイ用として）の代わりに適切な場合、それを剥離することを無視して、本当に必要な時だけにそれを除去するために、正当な理由なしに署名として解釈最初のU + FEFF剥離避けることが推奨されます。
U+FEFF in the first position of a stream MAY be interpreted as a zero-width non-breaking space, and is not always a signature. In an attempt at diminishing this uncertainty, Unicode 3.2 adds a new character, U+2060 "WORD JOINER", with exactly the same semantics and usage as U+FEFF except for the signature function, and strongly recommends its exclusive use for expressing word-joining semantics. Eventually, following this recommendation will make it all but certain that any initial U+FEFF is a signature, not an intended "ZERO WIDTH NO-BREAK SPACE".
ストリームの最初の位置にU + FEFFはゼロ幅改行なしスペースとして解釈され、常に署名ではないかもしれません。この不確実性を減少させるの試みでは、ユニコード3.2は、署名機能を除いて、U + FEFFとまったく同じ意味と用法で、新しいキャラクター、U + 2060「WORD JOINER」を追加し、強く言葉の表現のための排他的な使用を推奨していますセマンティクスに参加。結局、この勧告に従うことになりますそれはすべてが、任意の初期U + FEFFは署名ではなく、意図した「ZERO WIDTH NO-BREAK SPACEの」ある特定のこと。
In the meantime, the uncertainty unfortunately remains and may affect Internet protocols. Protocol specifications MAY restrict usage of U+FEFF as a signature in order to reduce or eliminate the potential ill effects of this uncertainty. In the interest of striking a balance between the advantages (reduction of uncertainty) and drawbacks (loss of the signature function) of such restrictions, it is useful to distinguish a few cases:
一方で、不確実性は、残念ながら残っていると、インターネット・プロトコルに影響を与える可能性があります。プロトコル仕様は、この不確実性の潜在的な悪影響を軽減または排除するために、署名としてU + FEFFの使用を制限することができます。そのような制限の利点（不確実性の減少）と欠点（署名機能の喪失）との間のバランスをとるの利益のために、いくつかのケースを区別することは有用です。
o A protocol SHOULD forbid use of U+FEFF as a signature for those textual protocol elements that the protocol mandates to be always UTF-8, the signature function being totally useless in those cases.
Oプロトコルは、プロトコルの義務は、常にUTF-8、署名機能は、これらの場合に全く役に立たないことすべきものテキストプロトコル要素の署名としてU + FEFFの使用を禁止すべきです。
o A protocol SHOULD also forbid use of U+FEFF as a signature for those textual protocol elements for which the protocol provides character encoding identification mechanisms, when it is expected that implementations of the protocol will be in a position to always use the mechanisms properly. This will be the case when the protocol elements are maintained tightly under the control of the implementation from the time of their creation to the time of their (properly labeled) transmission.
Oプロトコルはまた、プロトコルの実装が常に正しくメカニズムを使用する立場になることが予想される場合、プロトコルは、文字コード識別機構を提供するためにそれらのテキストプロトコル要素の署名としてU + FEFFの使用を禁止すべきです。これは、プロトコル要素は、それらの（適切に標識された）送信時に、作成時から実装の制御下にしっかり保持されている場合であろう。
o A protocol SHOULD NOT forbid use of U+FEFF as a signature for those textual protocol elements for which the protocol does not provide character encoding identification mechanisms, when a ban would be unenforceable, or when it is expected that implementations of the protocol will not be in a position to always use the mechanisms properly. The latter two cases are likely to occur with larger protocol elements such as MIME entities, especially when implementations of the protocol will obtain such entities from file systems, from protocols that do not have encoding identification mechanisms for payloads (such as FTP) or from other protocols that do not guarantee proper identification of character encoding (such as HTTP).
プロトコルは禁止が執行不能であろう場合、プロトコルは、文字符号化識別メカニズムを提供しないため、それらのテキストプロトコル要素に対する署名としてU + FEFFの使用を禁止すべきではない、またはそれは、プロトコルの実装がないことが予想される場合、O常に適切メカニズムを使用する立場にあります。後者の2つのケースは、プロトコルの実装が（FTPなど）ペイロードの識別機構をコードする持っていないプロトコルからまたは他のから、ファイルシステムからそのような実体を取得する場合は特に、このようなMIMEエンティティとして大きなプロトコル要素で発生する可能性があります（HTTPなど）文字エンコーディングの適切な識別を保証するものではありませんプロトコル。
When a protocol forbids use of U+FEFF as a signature for a certain protocol element, then any initial U+FEFF in that protocol element MUST be interpreted as a "ZERO WIDTH NO-BREAK SPACE". When a protocol does NOT forbid use of U+FEFF as a signature for a certain protocol element, then implementations SHOULD be prepared to handle a signature in that element and react appropriately: using the signature to identify the character encoding as necessary and stripping or ignoring the signature as appropriate.
プロトコルは、特定のプロトコル要素に対する署名としてU + FEFFの使用を禁止するとき、そのプロトコル要素の任意の初期U + FEFFは「ZERO WIDTH NO-BREAK空間」と解釈されなければなりません。プロトコルは、特定のプロトコル要素に対する署名としてU + FEFFの使用を禁止していない場合、その後の実装は、その要素に署名を処理するために用意されるべきであり、適切に反応：必要に応じて文字コードを識別するために署名を使用してストリッピングまたは無視します適切な署名。
The character sequence U+0041 U+2262 U+0391 U+002E "A<NOT IDENTICAL TO><ALPHA>." is encoded in UTF-8 as follows:
文字列U + 0041 U + 2262 U + 0391 U + 002E "<ALPHA> <と同一ではありません>。"次のようにUTF-8でエンコードされています。
--+--------+-----+--
41 E2 89 A2 CE 91 2E
--+--------+-----+--
The character sequence U+D55C U+AD6D U+C5B4 (Korean "hangugeo", meaning "the Korean language") is encoded in UTF-8 as follows:
次のように文字列U + D55C U + AD6D U +のC5B4（「韓国語」を意味韓国「hangugeo」は）UTF-8でエンコードされています。
--------+--------+--------
ED 95 9C EA B5 AD EC 96 B4
--------+--------+--------
The character sequence U+65E5 U+672C U+8A9E (Japanese "nihongo", meaning "the Japanese language") is encoded in UTF-8 as follows:
以下のように（「日本語」を意味日本の「日本語」、）文字列U + 65E5 U + 672C U + 8A9EはUTF-8でエンコードされています。
--------+--------+--------
E6 97 A5 E6 9C AC E8 AA 9E
--------+--------+--------
The character U+233B4 (a Chinese character meaning 'stump of tree'), prepended with a UTF-8 BOM, is encoded in UTF-8 as follows:
次のようにUTF-8 BOM前に付加文字U + 233B4（「木の切り株」を意味漢字）は、UTF-8でエンコードされています。
--------+-----------
EF BB BF F0 A3 8E B4
--------+-----------
This memo serves as the basis for registration of the MIME charset parameter for UTF-8, according to [RFC2978]. The charset parameter value is "UTF-8". This string labels media types containing text consisting of characters from the repertoire of ISO/IEC 10646 including all amendments at least up to amendment 5 of the 1993 edition (Korean block), encoded to a sequence of octets using the encoding scheme outlined above. UTF-8 is suitable for use in MIME content types under the "text" top-level type.
このメモは、[RFC2978]によれば、UTF-8のMIME charsetパラメータの登録のための基礎として役立ちます。 charsetパラメータ値は "UTF-8" です。この文字列は、少なくとも上記で概説した符号化方式を使用して、オクテットの配列にコードされる1993年版（韓国ブロック）の改正5までのすべての修正を含むISO / IEC 10646のレパートリーの文字からなるテキストを含むメディアタイプをラベル。 UTF-8は、「テキスト」のトップレベルタイプ下のMIMEコンテンツタイプでの使用に適しています。
It is noteworthy that the label "UTF-8" does not contain a version identification, referring generically to ISO/IEC 10646. This is intentional, the rationale being as follows:
ISO / IEC 10646に一般的に参照する。これは、次のように根拠があること、意図的である、ラベル「UTF-8」バージョンIDが含まれていないことは注目に値します。
A MIME charset label 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 [RFC2045], section 2.2). 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文字セットラベルが文字のシーケンスにワイヤ上で受信したバイトのシーケンスを解釈するために必要な情報だけを提供するように設計され、より多くの何も（、[RFC2045]セクション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.
したがって、限り標準が互換性進化として、バージョンを識別するラベルを有するの見かけの利点はそれだけで、明らかです。しかし、このようなバージョン依存のラベルに欠点がある：古いアプリケーションが新しい、未知のラベルを伴ってデータを受信したとき、それはラベルを認識し、データを扱うことが完全にできないことに失敗する可能性があり、一般的な、知られているラベルのに対しでしょうよく、新しい文字を含めることはできませんデータの大部分は正しい処理を引き起こしました。
Now the "Korean mess" (ISO/IEC 10646 amendment 5) is an incompatible change, in principle contradicting the appropriateness of a version independent MIME charset label 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 charset label defined here will stay aligned with the previous version until and unless the IETF specifically decides otherwise.
実際には、次に、バージョンに依存しないラベルが保証され、ラベルが改正5後のすべてのバージョンを指すと理解し、実際に発生全く互換性のない変更が設けられていないが提供されます。 ISO / IEC 10646の以降のバージョンでの変更を互換性のない必要があります発生IETFは、特にそうでないことを決定するまでとしない限り、ここで定義されたMIME文字セットラベルは、以前のバージョンに合わせたままになります。
The entry for UTF-8 in the IANA charset registry has been updated to point to this memo.
IANA文字セットレジストリでUTF-8のエントリはこのメモを指すように更新されました。
Implementers of UTF-8 need to consider the security aspects of how they handle illegal UTF-8 sequences. It is conceivable that in some circumstances an attacker would be able to exploit an incautious UTF-8 parser by sending it an octet sequence that is not permitted by the UTF-8 syntax.
UTF-8の実装者は、彼らが違法なUTF-8シーケンスをどのように処理するかのセキュリティ面を考慮する必要があります。いくつかの状況で、攻撃者はそれをUTF-8構文によって許可されていないオクテットのシーケンスを送信することにより、事も無げUTF-8パーサを利用することができるだろうと考えられます。
A particularly subtle form of this attack can be carried out against a parser which performs security-critical validity checks against the UTF-8 encoded form of its input, but interprets certain illegal octet sequences as characters. For example, a parser might prohibit the NUL character when encoded as the single-octet sequence 00, but erroneously allow the illegal two-octet sequence C0 80 and interpret it as a NUL character. Another example might be a parser which prohibits the octet sequence 2F 2E 2E 2F ("/../"), yet permits the illegal octet sequence 2F C0 AE 2E 2F. This last exploit has actually been used in a widespread virus attacking Web servers in 2001; thus, the security threat is very real.
この攻撃の特に微妙な形は、その入力のUTF-8でエンコードされたフォームに対するセキュリティが重要な妥当性チェックを実行するが、文字などの特定の違法オクテットシーケンスを解釈するパーサに対して行うことができます。例えば、パーサは単一オクテットシーケンス00として符号化されたときにNUL文字を禁止するが、誤って不正2オクテット配列C0 80を可能にし、NUL文字として解釈するかもしれません。別の例は、オクテット列2F 2E 2E 2F（「/../」）を禁止し、まだ違法オクテット配列2F C0 AE 2E 2Fを可能にするパーサであるかもしれません。 ;これは実際に2001年にWebサーバーを攻撃する広範なウイルスで使用されてきた最後の活用しますこのように、セキュリティ上の脅威は非常に現実的です。
Another security issue occurs when encoding to UTF-8: the ISO/IEC 10646 description of UTF-8 allows encoding character numbers up to U+7FFFFFFF, yielding sequences of up to 6 bytes. There is therefore a risk of buffer overflow if the range of character numbers is not explicitly limited to U+10FFFF or if buffer sizing doesn't take into account the possibility of 5- and 6-byte sequences.
UTF-8にエンコードする際に別のセキュリティ問題が発生します。UTF-8のISO / IEC 10646の記述は、最大6バイトのシーケンスを得、U + 7FFFFFFFまでの符号化文字番号を可能にします。文字番号の範囲を明示的にU + 10FFFFまたはバッファサイズは、アカウントに5員環と6バイトのシーケンスの可能性を取らない場合には限定されない場合は、バッファオーバーフローの危険性があります。
Security may also be impacted by a characteristic of several character encodings, including UTF-8: the "same thing" (as far as a user can tell) can be represented by several distinct character sequences. For instance, an e with acute accent can be represented by the precomposed U+00E9 E ACUTE character or by the canonically equivalent sequence U+0065 U+0301 (E + COMBINING ACUTE). Even though UTF-8 provides a single byte sequence for each character sequence, the existence of multiple character sequences for "the same thing" may have security consequences whenever string matching, indexing, searching, sorting, regular expression matching and selection are involved. An example would be string matching of an identifier appearing in a credential and in access control list entries. This issue is amenable to solutions based on Unicode Normalization Forms, see [UAX15].
（限り、ユーザは言うことができるように）いくつかの異なる文字列で表すことができる「同じもの」：セキュリティは、UTF-8を含むいくつかの文字エンコーディングの特性によって影響を受ける可能性があります。例えば、急性アクセント付きeは合成済みU + 00E9 E ACUTE文字によって、または正準等価配列U + 0065 U + 0301（E + ACUTEを組み合わせる）で表すことができます。 UTF-8は、各文字列のための単一のバイトシーケンスを提供していても、「同じもの」のための複数の文字列の存在は、セキュリティの結果をもたらす可能性がある時はいつでも文字列マッチング、インデックス作成、検索、ソート、正規表現のマッチングと選択が関与しています。例では、信用証明書およびアクセス制御リストエントリに現れる識別子の文字列照合であろう。この問題は、Unicode正規化フォームに基づくソリューションに従順である、[UAX15]を参照してください。
The following have participated in the drafting and discussion of this memo: James E. Agenbroad, Harald Alvestrand, Andries Brouwer, Mark Davis, Martin J. Duerst, Patrick Faltstrom, Ned Freed, David Goldsmith, Tony Hansen, Edwin F. Hart, Paul Hoffman, David Hopwood, Simon Josefsson, Kent Karlsson, Dan Kohn, Markus Kuhn, Michael Kung, Alain LaBonte, Ira McDonald, Alexey Melnikov, MURATA Makoto, John Gardiner Myers, Chris Newman, Dan Oscarsson, Roozbeh Pournader, Murray Sargent, Markus Scherer, Keld Simonsen, Arnold Winkler, Kenneth Whistler and Misha Wolf.
このメモの起草と議論に参加した以下：ジェームズ・E. Agenbroad、ハラルドAlvestrand、アンドリーズ・ブラウワー、マーク・デイビス、マーティン・J. Duerst、パトリックFaltstrom、ネッドフリード、デビッド・ゴールドスミス、トニー・ハンセン、エドウィン・F.ハート、ポールホフマン、デビッド・ホップウッド、サイモンJosefsson氏、ケント・カールソン、ダンコーン、マーカス・クーン、マイケル・クン、アラン・ラボンテ、アイラマクドナルド、アレクセイ・メルニコフ、村田誠、ジョン・ガーディナーマイヤーズ、クリス・ニューマン、ダンOscarsson、Roozbeh Pournader、マレー・サージェント、マーカス・シーラー、Keldシモンセン、アーノルド・ウィンクラー、ケネス・ウィスラーとミーシャウルフ。
o Restricted the range of characters to 0000-10FFFF (the UTF-16 accessible range).
O 0000-10FFFF文字の範囲（UTF-16アクセス可能な範囲）を制限しました。
o Made Unicode the source of the normative definition of UTF-8, keeping ISO/IEC 10646 as the reference for characters.
OメイドのUnicode UTF-8の規範的定義のソース、文字の基準としてISO / IEC 10646を保ちます。
o Straightened out terminology. UTF-8 now described in terms of an encoding form of the character number. UCS-2 and UCS-4 almost disappeared.
O用語をまっすぐに。 UTF-8は現在、文字番号のエンコーディング形式の観点から説明します。 UCS-2およびUCS-4はほとんど姿を消しました。
o Turned the note warning against decoding of invalid sequences into a normative MUST NOT.
O規範にしないMUST無効なシーケンスのデコードに対して警告ノートを回しました。
o Added a new section about the UTF-8 BOM, with advice for protocols.
Oプロトコルのためのアドバイスで、UTF-8 BOMについての新しいセクションを追加しました。
o Removed suggested UNICODE-1-1-UTF-8 MIME charset registration.
O削除はUNICODE-1-1-UTF-8 MIME文字セット登録を示唆しました。
o Added an ABNF syntax for valid UTF-8 octet sequences
Oの有効なUTF-8オクテットのシーケンスのためのABNF構文を追加しました
o Expanded Security Considerations section, in particular impact of Unicode normalization
Unicode正規化の特定の影響にO拡張Security Considerations部、
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[ISO.10646] International Organization for Standardization, "Information Technology - Universal Multiple-octet coded Character Set (UCS)", ISO/IEC Standard 10646, comprised of ISO/IEC 10646-1:2000, "Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane", ISO/IEC 10646-2:2001, "Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 2: Supplementary Planes" and ISO/IEC 10646- 1:2000/Amd 1:2002, "Mathematical symbols and other characters".
[ISO.10646]国際標準化のために、 - ISO / IEC 10646-1で構成される "情報技術ユニバーサルマルチオクテット符号化文字集合（UCS）"、ISO / IEC規格10646：2000、「情報技術 - ユニバーサルマルチ-Octetコード化文字セット（UCS） - 第1部：アーキテクチャと基本多言語面 "ISO / IEC 10646-2：2001、" 情報技術 - ユニバーサルマルチオクテット符号化文字セット（UCS） - 第2部：補足飛行機」およびISO / IEC 10646- 1：2000 / Amdの1：2002、 "数学記号と他の文字"。
[UNICODE] The Unicode Consortium, "The Unicode Standard -- Version 4.0", defined by The Unicode Standard, Version 4.0 (Boston, MA, Addison-Wesley, 2003. ISBN 0-321-18578-1), April 2003, <http://www.unicode.org/unicode/standard/ versions/enumeratedversions.html#Unicode_4_0_0>.
ユニコード規格によって定義された、バージョン4.0（ボストン、MA、アディソン・ウェズリー、2003 ISBN 0-321-18578-1）、2003年4月、< - [UNICODE]ユニコードコンソーシアム、 "バージョン4.0のUnicode標準" http://www.unicode.org/unicode/standard/バージョン/ enumeratedversions.html＃Unicode_4_0_0>。
[CESU-8] Phipps, T., "Unicode Technical Report #26: Compatibility Encoding Scheme for UTF-16: 8-Bit (CESU-8)", UTR 26, April 2002, <http://www.unicode.org/unicode/reports/tr26/>.
[CESU-8]フィップス、T.、 "Unicodeのテクニカルレポート＃26：互換エンコーディングスキームUTF-16：8ビット（CESU-8）"、UTR 26、2002年4月、<のhttp：//www.unicode。 ORG /ユニコード/レポート/ TR26 />。
[FSS_UTF] X/Open Company Ltd., "X/Open Preliminary Specification -- File System Safe UCS Transformation Format (FSS-UTF)", May 1993, <http://wwwold.dkuug.dk/jtc1/sc22/wg20/docs/ N193-FSS-UTF.pdf>.
[FSS_UTF] X / Openカンパニーリミテッド、 "X / Openの予備仕様 - システム安全UCS変換フォーマット（FSS-UTF）ファイル"、1993年5月に、<http://wwwold.dkuug.dk/jtc1/sc22/wg20 /ドキュメント/ N193-FSS-UTF.pdf>。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[RFC2978]フリード、N.とJ.ポステル、 "IANA文字セット登録手順"、BCP 19、RFC 2978、2000年10月。
[UAX15] Davis, M. and M. Duerst, "Unicode Standard Annex #15: Unicode Normalization Forms", An integral part of The Unicode Standard, Version 4.0.0, April 2003, <http:// www.unicode.org/unicode/reports/tr15>.
[UAX15]デイビス、M.とM. Duerst、 "Unicode規格附属書＃15：Unicode正規化フォーム"、Unicode標準の不可欠な部分、バージョン4.0.0、2003年4月、<のhttp：// www.unicode.org /ユニコード/レポート/ TR15>。
[US-ASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[US-ASCII]米国規格協会、 "コード化文字セット - 情報交換のための7ビットの米国標準コード"、ANSI X3.4、1986。
[1] <http://www.unicode.org/unicode/standard/policies.html>
「１」 ＜ｈっｔｐ：／／ｗっｗ。うにこで。おｒｇ／うにこで／ｓたんだｒｄ／ぽぃしえｓ。ｈｔｍｌ＞
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
Francois Yergeau Alis Technologies 100, boul. Alexis-Nihon, bureau 600 Montreal, QC H4M 2P2 Canada
フランソワYergeauアリス・テクノロジーズ100、BOUL。アレクシス日本、スイート600モントリオール、QC H4L 2P2カナダ
Phone: +1 514 747 2547 Fax: +1 514 747 2561 EMail: fyergeau@alis.com
電話：+1 514 747 2547ファックス：+1 514 747 2561 Eメール：fyergeau@alis.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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 assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
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機能のための基金は現在、インターネット協会によって提供されます。