UTF-8, a transformation format of ISO 10646
UTF-8、ISO 10646の変換フォーマット

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 (C) The Internet Society (2003). All Rights Reserved.

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には完全なUSASCII範囲を保存することの特徴があります。そして、互換性にファイルシステム（USASCIIの価値に頼るが、他の値までトランスペアレントであるパーサーと他のソフトウェア）を提供します。
このメモは、RFC 2279を旧式とし、置き代わります。

Table of Contents
　目次

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］によって定義されます。そして、それはさらに付加文字特性とメーカーにとっての大きな興味の他のアプリケーション詳細を定めます。 現在まで、ユニコードと改正における変更と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.

ISO/IEC 10646とユニコードは、彼らの一般のレパートリーのいくつかの符号化形を定めます： UTF-8、UCS-2、UTF-16、UCS-4とUTF-32。 符号化の形態では、各々の文字は、単位をコード化している一つ以上として見受けられます。 UTF-8以外は形をコード化しているすべての標準UCSはエンコーダユニットを1オクテットより大きくします。そして、彼らを8または7ビット文字さえ装う多くの現在のアプリケーションとプロトコルにおいて利用するのが難しくします。

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オクテット・エンコーダユニットがあります。 それにはオクテットのすべてのビットを使いますが、完全なUSASCII［USASCII］範囲を保存することの品質があります： USASCII文字は通常のUSASCII価値がある1オクテットにコード化されます、そして、そのような価値をもつ少しのオクテットもUSASCII文字と他の何も支持することができるだけでありません。

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は様々な数のオクテットとしてUCS文字をコード化します、そこで、オクテットの数と各々の価値はISO/IEC 10646（文字番号、一名コード位置、コードポイントまたはユニコード・スカラー値）で文字に割り当てられる整数値に依存します。 この符号化の形態には、以下の特徴（値の表示は16進法です）があります：

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月に考案されました。 トンプソンのデザインはX/Openジョイント国際化グループXOJIG（見ます［FSS_UTF］）によって標準化を通してstewardedされました。そして、途中で名前FS-UTF（変形FS/UTF）、UTF-2と最後にUTF-8を運びました。

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.

UCS文字はHHHHは、ISO / IEC 10646の文字番号を表す4から6進数の数字からなる文字列です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は、ユニコード標準［ユニコード］によって定義されます。 説明と手法は、10646-1［ISO.10646］で、ISO/IECのアネックス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オクテットのシーケンスを使ってコード化されます。 1の「シーケンス」の唯一のオクテットは高次ビットを0をつけられます。そして、残りの7ビットが文字番号をコード化するのに用いられます。 一連のnオクテット（n > 1）において、最初のオクテットはn高次ビットを1をつけられます。そして、0をつけられるビットが続きます。 そのオクテットの残りのビットは、コード化される文字の数から、ビットを含みます。 以下のオクテットはすべて、1をつけられる高次ビットと0をつけられる以下のビットを持っています。そして、コード化される文字からビットを含むために各々で6ビットを残します。

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は、少しの文字番号をコード化することが利用できるビットを示します。

Encoding a character to UTF-8 proceeds as follows:

UTF-8に文字をコード化することは、以下の通りに進行します：

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の定義はU+D800とU+DFFFの間で文字番号をコード化することを禁止します。そして、それはUTF-16をコード化している形（代わりの組として）の用途に、確保されて、文字を直接表しません。 UTF-16からデータをUTF-8にコード化するとき、文字番号を得るために最初にUTF-16データを解読することが必要です。そして、それはそれから先に述べたようにUTF-8にコード化されます。 これはCESU-8［CESU-8］と対照をなします。そして、それはインターネット上で使用のために意味されないUTF-8のような符号化です。 CESU-8はUTF-8に同様に動くが、文字番号（コードポイント）の代わりに、UTF-16コード価格（16ビット量）をコード化します。 これは、0xFFFFを上回って文字番号のために異なる結果に至ります; それらの文字のCESU-8符号化は、有効なUTF-8でありません。

Decoding a UTF-8 character proceeds as follows:

UTF-8文字を解読することは、以下の通りに進行します：

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.

上記の復号アルゴリズムの実装では、デコード無効配列に対して保護しなければなりません。 例えば、単純な実装では、長過ぎるUTF-8シーケンスC080をU +0000、またはサロゲートペアED A1 8C ED BE B4はU233B4にデコードすることができます。 無効なシーケンスを解読することはセキュリティ結果があるかもしれないか、他の問題を引き起こすかもしれません。 セキュリティ考慮点（第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です。そして、それはUTF-8をコード化することに対する規則に由来して、ABNFを中で表されます［RFC2234］

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は、改正と更なる部分の出版によって、時々更新されます; 同様に、ユニコード標準の新しいバージョンは、時間とともに発表されます。 各々の新しいバージョンは前のものを廃れさせて、代わります、しかし、実現例とよりかなりデータはすぐに更新されません。

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とユニコード2.0の1993の版の改正5は韓国のハングル・ブロックを動かして、膨張させました。そして、それによってどんな前のデータを含んでいるハングル文字でも新しいバージョンの下で無効にしました。 ユニコード2.0には、ユニコード1.1との同じ違いがあります。 そのような非互換の変化を許すことを正当化する理由は、データを含んでいるハングルの大きな機能とかなりの量がなかったということでした。
事件は「韓国の混乱」と呼ばれました、そして、関連した委員会は絶対に二度とそのような非互換の変化（ユニコード・コンソーシアム方針［1］を見ます）をもたらさないと誓いました。

New versions, and in particular any incompatible changes, have consequences regarding MIME charset labels, to be discussed in MIME registration (Section 8).

新しいバージョンと特にどんな非互換の変化にでもMIME charsetラベルに関して結果があります。そして、MIME登録（第8節）において議論されます。

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「ブレークが間隔をあけない0幅」は、略式に「バイト順序マーク」（省略した「BOM」）としても知られています。 この文字がテキストの範囲内の本物の「ブレークが間隔をあけない0幅」として使われることができます、しかし、BOMは文字の第2の可能性がある使用法でヒントを挙げます： 「サイン」として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文字列を連結するとき、さもなければ結果として生じるひもが接続で予想外の「ブレークが間隔をあけない0幅」を含むかもしれないので、指してください）が、流れですべての文字の存在に頼っている異なる層（例えばデジタル署名または文字のカウント）で、外部プロセスに影響を及ぼすかもしれません。 本当に必要な時だけ、それはしたがって、正当な理由のないサインと解釈される最初の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+2060「単語接合物」）をサイン機能以外のU+FEFFと同じ正確に意味論と使用と加えて、強くその専用を語に加わっている意味論を表すことに推薦します。 結局、この推薦に従うことは、それをどんな最初のU+FEFFでもサイン（意図された「ブレークが間隔をあけない0幅」でない）であることはほとんど確かにします。

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の使用法を制限するかもしれません。 そのような規制の利点（不確実性の縮小）と欠点（サイン機能の損失）の間の釣合いを保つことのために、2、3のケースを識別することは役に立ちます：

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でも「0幅で間隔をあけない空白」と解釈されなければなりません。 プロトコルが特定のプロトコル要素のサインとして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「『A』同一のTOでない『アルファ』」、以下の通りにUTF-8にコード化されます：

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にコード化されます：

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」（「日本語」を意味する））は、以下の通りにUTF-8にコード化されます：

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（『木の幹』を意味している漢字）（UTF-8 BOMとともに前に付加される）は、以下の通りにUTF-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.

このメモはUTF-8のMIME charsetパラメータの登録の根拠として用いられます。そして、に一致します［RFC2978］。 charsetパラメータ価値は、「UTF-8」です。 このストリングは媒体に1993の版（韓国のブロック）の改正5まで少なくともすべての改正を含むISO/IEC 10646のレパートリーから文字からなるテキストを含んでいるタイプとラベルをつけます。そして、上で概説される符号化計画を使っている一連のオクテットにコード化されます。

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は、「テキスト」トップレベルのタイプの下でMIME内容タイプの使用に適しています。 ラベル「UTF-8」がバージョン識別を含まないことは注目に値します。そして、一般的にISO/IEC 10646に言及します。 これは意図的です。そして、正当性は以下の通りです：

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 charsetラベルは、一連の文字（より多くの情報は（［RFC2045］、第2.2節を見てください）何もない）に電報で受け取られる一連のバイトを解釈するために必要なまさに情報を伝えるようになっています。 標準に設定される文字が両立し難く変わらない限り、人が人が知らない新しく割り当てられた文字が受け取られるかもしれないタグから学習によって何も得ないので、バージョン番号は目的にかないません。 タグそのものは新しい文字について何も教えません。そして、それはいずれにしろ受け取られそうです。

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 charsetラベルの適切さを否定します。 しかし、互換性問題はユニコード1.1（または同等に改正5の前のISO/IEC 10646）によるとコード化される韓国のハングル文字を含んでいるデータで現れることができるだけです、そして、そのようなデータがおそらく、利用できる心配（この非互換の変化が許容できると考えられたまさしくその理由であること）にありません。

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 charsetラベルは前のバージョンに合わせられてとどまります。

The entry for UTF-8 in the IANA charset registry has been updated to point to this memo.

IANA charsetレジストリの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（「/../」）、オクテット・シーケンスを禁止しますが、2E 2F、不法オクテット・シーケンス2F C0 AEを許すパーサーであるかもしれません。 この最後の功績が、実は、2001年にウェブサーバを襲っている広範囲にわたるウイルスで使われました; このように、セキュリティ脅威は、非常に本当です。

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説明はU+7FFFFFFFまで文字番号をコード化するのを許します。そして、最高6バイトのシーケンスを与えます。 文字番号の範囲が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は、precomposedされたU+00E9 E鋭い文字によって、または、宗規に従って等しいシーケンスU+0065 U+0301（深刻に組み合わさっているE +）によって見受けられることができます。 たとえUTF-8が文字連続ごとに一つのバイト・シーケンスを提供するとしても、あっているストリング、インデクシング、あっている厳しい、分類、定期的な表現と選択が複雑になるときはいつでも、「同じもの」のための複数の文字シーケンスの存在にはセキュリティ結果があるかもしれません。 例は、証明書で、そして、アクセス制御リスト入り口に現れている鑑定人の合っているストリングです。 この問題はユニコード正常化形に基づく解決に従います、見てください［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.

[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専務取締役に申し出てください。

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.

ここに含まれるこの文書と情報は現状有姿条件で提供されます、そして、インターネット学会とインターネット技術特別調査委員会はすべての保証（この中の情報の使用が少しの権利もまたは市場性または特定の目的のための適合性の少しの暗黙の保証も侵害しないどんな保証を含むがこれに限らずでも明示または黙示の）を否認します。

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディタ機能のための資金提供は、インターネット学会によって現在提供されます。