この文書はRFC3629の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
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.
ＩＳＯ／ＩＥＣ １０６４６-１は世界の言語表記法の大部分をカバーする、
共通文字集合（ＵＣＳ）と呼ばれる大きい文字集合を定義します。ＵＣＳの
元来の提案されたコーディングは、多くの現在のアプリケーションとプロト
コルと両立できませんでした、そしてこれはこの文書の対象のＵＴＦ−８の
開発を導きました。ＵＴＦ−８が合衆国−ＡＳＣＩＩ範囲のコーディングを
完全に維持し、合衆国−ＡＳＣＩＩ値に依存し他の値は透過なファイルシス
テムやパーサや他のソフトウェアに互換性を提供します。この文書はＲＦＣ
２２７９を時代遅れにし、置き換えます。
Table of Contents
目次
1. Introduction
1. はじめに
2. Notational conventions
2. 表記
3. UTF-8 definition
3. ＵＴＦ−８定義
4. Syntax of UTF-8 Byte Sequences
4. ＵＴＦ−８バイト列の構文
5. Versions of the standards
5. 標準の版
6. Byte order mark (BOM)
6. バイト順マーク（ＢＯＭ）
7. Examples
7. 例
8. MIME registration
8. ＭＩＭＥ登録
9. IANA Considerations
9. ＩＡＮＡの考慮
10. Security Considerations
10. セキュリティの考察
11. Acknowledgements
11. 謝辞
12. Changes from RFC 2279
12. ＲＦＣ２２７９からの変更
13. Normative References
13. 参照する参考文献
14. Informative References
14. 有益な参考文献
15. URIs
15. ＵＲＩ
16. Intellectual Property Statement
16. 知的所有権宣言
17. Author's Address
17. 著者のアドレス
18. Full Copyright Statement
18. 著作権表示全文
1. Introduction
1. はじめに
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.10646]は一般的文字集合（ＵＣＳ）と呼ば
れる大きい文字集合を定義し、これは世界の言語表記法の大部分をカバーし
ます。同じ文字集合はユニコード標準[UNICODE]で定義され、そしてこれはさ
らに追加の文字特性と実装者に非常に重要な他のアプリケーションの詳細を
定義します。現在の時点で、ユニコードの改正とＩＳＯ／ＩＥＣ １０６４６
の改正と追加は、お互いに追跡していて、それで文字の種類とコードポイン
ト割当は同期しています。適切な標準化委員会はこの非常に有用な同時性を
維持する事を約束しました。
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, 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.
このメモの対象のＵＴＦ−８は、１オクテットのコーディング単位を持ちま
す。これはすべてのオクテットのビットを使います、しかし合衆国−ＡＳＣ
ＩＩ[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):
ＵＴＦ−８がＵＣＳ文字を様々な数のオクテットにコード化し、そしてオク
テット数と値はそれぞれＩＳＯ／ＩＥＣ１０６４６で文字に割り当てられた
整数値に依存します（文字番号、別名、コード位置、コードポイント、ユニ
コードスカラー値）。このコーディング形式は次の特徴を持ちます（すべて
の値は１６進数です）：
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.
o 文字番号のU+0000からU+007Fまで（合衆国−ＡＳＣＩＩ範囲）がオクテッ
ト00から7Fに対応します（７ビット合衆国−ＡＳＣＩＩ値）。重要な事は、
簡素なＡＳＣＩＩ文字列は同時に正しいＵＴＦ−８文字列であるというこ
とです。
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 合衆国−ＡＳＣＩＩオクテット値が他にＵＴＦ−８コード文字列に現われ
ません。これは合衆国−ＡＳＣＩＩ値に基づいて文の解析をし、他の値に
対して透過なファイルシステムや他のソフトウェア（例えば、Ｃライブラ
リのprintf()関数）に互換性に提供します。
o Round-trip conversion is easy between UTF-8 and other encoding
forms.
o ＵＴＦ−８と他の形式間の相互変換は容易です。
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.
o オクテット値のC0とC1とF5からFFは決して現われません。
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 ＵＴＦ−８文字列のバイト値の辞書順序は、文字番号による順序と同じで
す。文字番号に基づいた並び替えは文化的にはほとんど正しくないので、
もちろんこれは限定された意味を持ちます。
o The Boyer-Moore fast search algorithm can be used with UTF-8 data.
o ボイヤ−ムーアの高速捜索アルゴリズムはＵＴＦ−８データに使うことが
できます。
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 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.
ＵＴＦ−８は、破壊的でない方法でＰｌａｎ９オペレーティング・システム
で有用なＵＣＳ変換フォーマットを定義する目的で、ロブ・パイクのした設
計基準に従って、ケン・トンプソンによって１９９２年９月に考案されまし
た。トンプソンのデザインは、Ｘ／Ｏｐｅｎジョイント国際化グループ
ＸＯＪＩＧ（[FSS_UTF]参照）を通して検討され、名前がＦＳＳ−ＵＴＦ
（方言としてＦＳＳ／ＵＴＦ）やＵＴＦ−２となり、最終的にＵＴＦ−８に
なりました。
2. Notational conventions
2. 表記
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"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"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.
ＵＣＳ文字がU+HHHH表記で指定され、ここでHHHHはＩＳＯ／ＩＥＣ１０６４６
文字番号を表す４個から６個の１６進数文字列です。
3. UTF-8 definition
3. ＵＴＦ−８定義
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]
ＵＴＦ−８はユニコード標準[UNICODE]によって定義されます。記述と方式が
同じくＩＳＯ／ＩＥＣ１０６４６−１[ISO.10646]の付録Ｄで見いだすことが
できます。
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.
ＵＴＦ−８で、U+0000..U+10FFFF範囲の文字（ＵＴＦ−１６のアクセス可能
範囲の文字）が１から４オクテットを使ってコード化されます。単一オクテッ
ト文字は最上位ビットが０で、残りの７ビットが文字番号に使われます。
ｎ＞１のｎオクテットの文字で、最初のオクテットは最上位ｎビットが１で、
その後に０の１ビットがあります。オクテットの残りのビットはコード化さ
れた文字の番号のビットを含んでいます。後のオクテットは最上位ビットが
１、次が０、で残りの６ビットがコード化された文字の番号のビットを含ん
でいます。
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:
文字をＵＴＦ−８にコード化する処理は次のように進みます：
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. 表の２番目の項目に従って８オクテットの上位ビットを準備してくださ
い。
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. 文字番号の２進数表現のビットで、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.
ＵＴＦ−８の定義はU+D800とU+DFFFの間の文字番号のコード化を禁止し、そ
してこれは（代理対として）ＵＴＦ−１６のコーディング形式で使用するた
めに予約され、そして直接文字を表しません。ＵＴＦ−１６データをＵＴＦ−
８へコード化する時、最初にＵＴＦ−１６データを解読し文字番号を得る必
要があり、それから上記のようにコード化します。これはＣＥＳＵ−８
[CESU-8]と対照的です、ＣＥＳＵ−８はインターネット上での使用を意味し
ないＵＴＦ−８に似たコーディングです。ＣＥＳＵ−８はＵＴＦ−８と同様
に運用しますが、文字番号の代わりにＵＴＦ−１６コード値（１６ビット）
をコード化します。これは０ｘＦＦＦＦ以上の文字番号で異なる結果を生じ
ます；ＣＥＳＵ−８コーディングは正当なＵＴＦ−８ではありません。
Decoding a UTF-8 character proceeds as follows:
ＵＴＦ−８文字の解読は次のように進みます：。
1. Initialize a binary number with all bits set to 0. Up to 21 bits
may be needed.
1. ２進数をビットをすべて０に設定して初期化します。最大２１ビットが
必要かもしれません。
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. 列のオクテット数と上記の表の第２項目から、どのビットが文字番号を
コード化してるか決定します（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.
3. 列から２進数にビットを配ります、最初に列の最後のオクテットの下位
から、xビットがなくなるまで前にすすみます。２進数は文字番号に一致
します。
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.
解読アルゴリズムの実装は、無効な列の解読に対して保護されなければなり
ません(MUST)。例えば、検査をしない実装は長すぎるＵＴＦ−８列C0 80を
U+0000にコード化するか、代理対ED A1 8C ED BE B4をU+233B4にコード化す
るかもしれません。無効な列の解読はセキュリティの問題があるか、あるい
は他の問題を起こすかもしれません。下記のセキュリティの考察（１０章）
を見てください。
4. Syntax of UTF-8 Byte Sequences
4. ＵＴＦ−８バイト列の構文
For the convenience of implementors using ABNF, a definition of UTF-8
in ABNF syntax is given here.
ＡＢＮＦを使用する実装者の便利さのために、ＡＢＮＦ構文でのＵＴＦ−８
の定義がここで与えられます。
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].
ＵＴＦ−８文字列がＵＣＳ文字の順序を表すオクテットの連続です。オクテッ
ト連続は、それが次の構文に一致する場合に限り、正当なＵＴＦ−８で、そ
してこれはＵＴＦ−８のためのコーディング規則から得られて、そして
[RFC2234]のＡＢＮＦで表現されます。
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-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
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.
メモ−ＵＴＦ−８の正式な定義は[UNICODE]です。この文法はユニコードが記
述するのと同じものを記述すると信じられますが、正式であるとは主張しま
せん。実装者は、このＡＢＮＦより、正式な情報源に頼るように促されます。
5. Versions of the standards
5. 標準の版数
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.
ＩＳＯ／ＩＥＣ１０６４６が改正と追加の部分の公開によって時折更新され
ます；同様に、ユニコード標準の新しい版が時折公開されます。それぞれの
新しい版が古い版を時代遅れにし置き換えますが、実装や重要なデータは直
ちには更新されません。
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]).
一般に、変更は新しい文字を加えることになり、そしてこれは古いデータで
の特定の問題を発生しません。１９９６年に、ＩＳＯ／ＩＥＣ１０６４６と
ユニコード２.０の１９９３の版への改正５で、韓国ハングルブロックが動か
され、ハングルを含む以前のデータが無効になりました。ユニコード２.０は
ユニコード１.１から同様の違いを持っています。このような互換性がない変
更を許す理由は、主要な実装とデータで大量のハングルがなかったからでし
た。事件は「韓国の混乱」と名前を付けられました、そして適切な委員会は
決して再びこのような互換性がない変更をしないと誓いました（ユニコード
協会方針[1]参照）。
New versions, and in particular any incompatible changes, have
consequences regarding MIME charset labels, to be discussed in MIME
registration (Section 8).
新しい版数、特に互換性がない変更は、ＭＩＭＥ文字集合ラベルに関して、
ＭＩＭＥ登録で論じられる結果を持ちます（８章）。
6. Byte order mark (BOM)
6. バイト順マーク（ＢＯＭ）
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.
ＵＣＳ文字U+FEFF「ゼロ幅改行なし空白」は非公式に「バイト順マーク」
（省略で「ＢＯＭ」）として知られています。この文字はテキスト中で本物
の「ゼロ幅改行なし空白」として用いらることができますが、ＢＯＭの名前
は文字の２つ目の可能な使用方法を暗示します：ＵＣＳ文字列の前に「署名」
としてU+FEFF文字を設定する。このような連続データの受信者は最初文字を、
データ列がＵＣＳ文字から成り、どのＵＣＳコーディングが使われるかを認
識し、そしてコーディングが複数オクテットのコーディング単位からなる場
合、オクテットの連続データ化の順序を認識する方法の、手掛りとして用い
るかもしれません。ＵＴＦ−８が単一オクテットコーディング単位なので、
最後の機能は無用で、そしてＢＯＭは常にオクテット列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がゼロ幅の改行なし空白の意味
で解釈されなくてはならならず(MUST)、署名と解釈されてはならない(MUST
NOT)と理解することは重要です。署名と解釈される時、最初のU+FEFF文字が
テキストが処理される前に削除されるかもしれないと、ユニコード標準は示
唆しています。このような削除はある場合に必要です（例えば、２つの文字
列を連結する時、さもなければ連結で生じる文字列は連結位置で思いがけな
い「ゼロ幅改行なし空白」を含むかもしれないからです）が、データ列の全
ての文字の存在に依存するる外部の異なるレイヤの処理に影響を与えるかも
しれません（ディジタル署名あるいは文字のカウントなど）。従って良い理
由なしで署名と解釈された最初のU+FEFFを削除するの避け、（表示する場合
など）適切な場合は削除の代わりに無視し、必要な場合だけ削除することが
勧められます(RECOMMENDED)。
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はゼロ幅の改行なし空白と解釈されるかもし
れず(MAY)、そして常に署名とは限りません。この不確定を減らす試みで、
ユニコード３.２は署名機能以外はU+FEFFと正確に同じ意味と使い方の新し
い文字「単語結合」を追加し、そして単語結合の表現では強く排他的にこれ
の使用を勧めるます。結局は、この推薦も従うことで、最初のU+FEFFが、意
図的な「ゼロ幅改行なし空白」ではなく、署名であることをほとんど確かに
するでしょう。
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を使用するの
を制限するかもしれません(MAY)。このような制限の利点（不確定の縮小）と
欠点（署名機能の損失）の間の均衡をとる関係で、いくつかの場合を区別す
ることは有用です：
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 プロトコルが常にＵＴＦ−８を義務化し署名機能が無用である場合、プロ
トコルがテキストのプロトコル要素で署名としてU+FEFFの使用を禁じるべ
きです(SHOULD)。
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の使用を禁じるべきです(SHOULD)。
これは、プロトコル要素が生成時から伝送時まで実装の制御下でしっかり
管理される時に真実であるでしょう。
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).
o プロトコルが文字コーディング識別メカニズムを供給しないか、禁止令が
施行不可能であろう時か、プロトコル実装が常に正確にメカニズムを使う
と思われない時に、テキストのプロトコル要素でU+FEFFを署名として使用
するのを禁止するべきではありません(SHOULD NOT)。後の２つの場合は、
ＭＩＭＥエンティティのようなより大きいプロトコル要素で、特にプロト
コル実装がこのようなエンティティをファイルシステムから得る場合や、
ペイロードにコーディング識別メカニズムを持たないプロトコル（ＦＴＰ
など）から得る場合や、文字コーディングの適切な識別を保証しない他の
プロトコル（ＨＴＴＰなど）から得る場合に、起こる可能性が高いです。
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は「ゼロ幅改行無し空白」と解釈されなく
てはなりません(MUST)。プロトコルがあるプロトコル要素の署名として
U+FEFFの使用を禁じない時、実装がその要素で署名を処理して適切に対応す
る用意ができるべきです(SHOULD)：文字コーディングを識別するために署名
を使い、適切に署名を削除か無視します。
7. Examples
7. 例
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「A<NOT IDENTICAL TO><ALPHA>.」はＵ
ＴＦ−８で以下のようにコードかされます。
--+--------+-----+--
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」、「韓国語」の意味）
はＵＴＦ−８で以下のようにコード化されます。
--------+--------+--------
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（日本語の「nihongo」、「日本語」の意味）
はＵＴＦ−８で以下のようにコード化されます。
--------+--------+--------
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:
文字U+233B4（中国語文字で、「木の切り株」の意味）はＵＴＦ−８のＢＯＭ
を先頭につけて、ＵＴＦ−８で以下のようにコード化されます。
--------+-----------
EF BB BF F0 A3 8E B4
--------+-----------
8. MIME registration
8. ＭＩＭＥ登録
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」です。
この文字列はメディアタイプが、上に概説されたコーディング計画を使って
いるオクテット列でコード化されて、少なくとも１９９３の版（韓国のブロッ
ク）の改正５までのすべての改正を含めむ、ＩＳＯ／ＩＥＣ１０６４６の種
類の文字から成り立っているテキストを含んでいると判別します。ＵＴＦ−
８は「テキスト」最上位レベルタイプの下のＭＩＭＥ内容タイプでの使用に
適しています。
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:
ラベル「UTF-8」が、参照するＩＳＯ／ＩＥＣ１０６４６のバージョン識別を
含んでいないことは注目すべきです。これは意図的で、原理は次の通りです：
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.
ＭＩＭＥ文字集合ラベルがワイヤ上で受信したバイト列を解釈するために必
要な情報を与えるよう意図され、それ以上ではありません（[RFC2045]２.２
章参照）。文字集合標準が互換性がなく変化しない限り、バージョン番号が
目的を満たしません、なぜなら新しい新たに割り当てられた文字を受信する
かもしれないことを知ることで得るものはありませんから。タグ自身は新し
い文字について何も教えず、いずれにしろ受信します。
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.
「韓国の混乱」（ＩＳＯ／ＩＥＣ１０６４６の改正５）は、上に記述される
ように、、原則としてバージョンに依存しないＭＩＭＥ文字集合ラベルの適
切さを否定する互換性がない変更です。けれども互換性問題はユニコード１.１
（あるいは等価なＩＳＯ／ＩＥＣ１０６４６の改正５以前）に従ってコード
化された韓国語のハングル文字を含む状態でだけ現われ、このようなデータ
はおそらくなく、互換性がない変更が受容できるとみなされたまさしくその
理由はこれです。
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.
実際、ラベルが改正５の後にすべての版を参照すると理解され、そして互換
性がない変更が実際に起こらないなら、バージョンに依存しないラベルが正
当化されます。互換性がない変更がＩＳＯ／ＩＥＣ１０６４６の後のバージョ
ンで生じたなら、ここで定義されたＭＩＭＥ文字集合ラベルが、ＩＥＴＦが
特別な決定を下さない限り、前のバージョンの指定のままとされるでしょう。
9. IANA Considerations
9. ＩＡＮＡの考慮
The entry for UTF-8 in the IANA charset registry has been updated to
point to this memo.
ＩＡＮＡ文字集合登記所の中のUTF-8へのエントリーはこの文書を指し示すた
めに更新されました。
10. Security Considerations
10. セキュリティの考察
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.
ＵＴＦ−８の実装者がセキュリティの面で正しくないＵＴＦ−８の処理方法
を考える必要があります。ある状況で攻撃者がＵＴＦ−８構文で認められな
いオクテット列を送ることによって軽率なＵＴＦ−８パーサを利用すること
が可能であるであろうことは想像可能です。
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.
この攻撃の特に微妙な形式は、入力のＵＴＦ−８でコード化された形式に対
してセキュリティ上の検査を実行するが、しかしある特定の正しくないオク
テット列を文字に翻訳するパーサーに対して実行することができます。例え
ば、パーサーが単一オクテット列の00にコード化したヌルを禁止するが、誤っ
て正しくない２オクテット列C0 80を許して、そしてヌル文字として翻訳する
かもしれません。もう１つの例はオクテット列2F 2E 2E 2F("/../")を禁止す
るパーサーが、誤ったオクテット列2F C0 AE 2E 2Fを認める事です。この後
の方法は実際に２００１年に広範囲にウェブサーバを攻撃たウイルスで使わ
れました；それで、セキュリティの脅威は非常に真実です。
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.
他のセキュリティ問題が、ＵＴＦ−８にコーディング時に起きます：ＵＴＦ−
８のＩＳＯ／ＩＥＣ１０６４６の記述はU+7FFFFFFFまでの文字番号をコード
化して、最高６バイトの列をもたらすことを許します。もし文字番号の範囲
が明示的にU+10FFFFに限定されていないなら、あるいはもしバッファサイズ
が５バイトや６バイト列の可能性を考慮しないなら、それ故にバッファオー
バーフローの危険があります。
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].
セキュリティがＵＴＦ−８を含むいくつかのコード化の特徴によって影響を
与えられるかもしれません：（ユーザが認識できる限り）「同じもの」はい
くつかの別の文字列で表すことができます。例えば、鋭いアクセントのｅが
組合せ済みのU+00E9 E ACUTE文字で、あるいは正規的に等しい列U+0065
U+0301 (E + COMBINING ACUTE)で表現できます。ＵＴＦ−８がそれぞれの文
字列にひとつのバイト列を提供しても、「同じもの」に多数の文字列が存在
するので、文字比較やインデックス付けや並び替えや正規表現比較や選択で、
セキュリティの問題があります。例えば、証明書の識別子の文字列比較と、
アクセス制御リストの項目です。この問題はユニコード正規化形式に基づい
て解決する事が出来ます、[UAX15]を見てください。
11. Acknowledgements
11. 謝辞
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.
下記の方々はこの文章の作成の論議に参加しました：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、
Misha Wolf.
12. Changes from RFC 2279
12. ＲＦＣ２２７９からの変更
o Restricted the range of characters to 0000-10FFFF (the UTF-16
accessible range).
o 文字範囲を0000-10FFFF （ＵＴＦ−１６のアクセス可能な範囲）に制限し
ました。
o Made Unicode the source of the normative definition of UTF-8,
keeping ISO/IEC 10646 as the reference for characters.
o ＵＴＦ−８の標準定義の元をユニコードにし、ＩＳＯ／ＩＥＣ１０６４６
を文字の参考としました。
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 用語を直しました。現在ＵＴＦ−８は文字番号のコーディングの形式を記
述します。ＵＣＳ−２とＵＣＳ−４がほとんど姿を消しました。
o Turned the note warning against decoding of invalid sequences into
a normative MUST NOT.
o 無効な列を解読することの禁止を警告しているノートを標準のMUST NOTに
変えました。
o Added a new section about the UTF-8 BOM, with advice for
protocols.
o ＵＴＦ−８のＢＯＭについて、プロトコルのためにアドバイスの新しい章
を加えました。
o Removed suggested UNICODE-1-1-UTF-8 MIME charset registration.
o 提案されたユニコードUNICODE-1-1-UTF-8というＭＩＭＥ文字集合登録を
削除しました。
o Added an ABNF syntax for valid UTF-8 octet sequences
o 正当なＵＴＦ−８オクテット列のためにＡＢＮＦ構文を加えました。
o Expanded Security Considerations section, in particular impact of
Unicode normalization
o ユニコード正常化の特定の影響で、セキュリティの考慮の章を拡大しまし
た。
13. Normative References
13. 参照する参考文献
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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".
[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>.
14. Informative References
14. 有益な参考文献
[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/>.
[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>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
[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>.
[US-ASCII] American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
15. URIs
15. ＵＲＩ
[1] <http://www.unicode.org/unicode/standard/policies.html>
16. Intellectual Property Statement
16. 知的所有権宣言
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.
この文書に記述された実装や技術に関して主張される知的財産や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する調査をしたとは述べません。ＩＥＴＦ標準手続きと標準関連文書で
の権利に関しての手順の情報はＢＣＰ１１を見てください。出版に利用する
権利の利用可能性とライセンスの保証の利用可能性か、あるいはこの仕様書
の実装者や利用者のこの様な所有権の一般的ライセンスや許可を得る試みの
結果はＩＥＴＦ事務局で得られます。
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.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかＩＥＴＦ専務に情報を伝えてください。
17. Author's Address
17. 著者のアドレス
Francois Yergeau
Alis Technologies
100, boul. Alexis-Nihon, bureau 600
Montreal, QC H4M 2P2
Canada
Phone: +1 514 747 2547
Fax: +1 514 747 2561
EMail: fyergeau@alis.com
18. Full Copyright Statement
18. 著作権表示全文
Copyright (C) The Internet Society (2003). 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 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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。