RFC 2279 - UTF-8, a transformation format of ISO 10646 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc2279
タイトル : RFC 2279 - UTF-8、ISO 10646の変換フォーマット
翻訳編集 : 自動生成

[要約] RFC 2279は、ISO 10646の変換形式であるUTF-8についての要約を提供しています。その目的は、国際的なテキストエンコーディングの標準化と、異なる言語や文字セットのテキストを効率的に表現することです。

Network Working Group                                       F. Yergeau
Request for Comments: 2279                           Alis Technologies
Obsoletes: 2044                                           January 1998
Category: Standards Track

UTF-8, a transformation format of ISO 10646

UTF-8、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）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

Abstract

概要

ISO/IEC 10646-1 defines a multi-octet character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. Multi-octet characters, however, are not compatible with many current applications and protocols, and this has led to the development of a few so-called UCS transformation formats (UTF), each with different characteristics. UTF-8, the object of this memo, 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 updates and replaces RFC 2044, in particular addressing the question of versions of the relevant standards.

ISO / IEC 10646-1は、世界のほとんどの書記体系を含むユニバーサル文字セット（UCS）と呼ばれるマルチオクテット文字セットを定義しています。ただし、マルチオクテット文字は、現在の多くのアプリケーションおよびプロトコルと互換性がなく、これにより、それぞれが異なる特性を持ついくつかのいわゆるUCS変換フォーマット（UTF）の開発につながりました。このメモの目的であるUTF-8は、US-ASCIIの範囲全体を維持するという特徴があり、ファイルシステム、パーサー、およびUS-ASCII値に依存するが他の値に対して透過的な他のソフトウェアとの互換性を提供します。このメモはRFC 2044を更新して置き換え、特に関連する規格のバージョンの問題に対処します。

1. Introduction

1. はじめに

ISO/IEC 10646-1 [ISO-10646] defines a multi-octet character set called the Universal Character Set (UCS), which encompasses most of the world's writing systems. Two multi-octet encodings are defined, a four-octet per character encoding called UCS-4 and a two-octet per character encoding called UCS-2, able to address only the first 64K characters of the UCS (the Basic Multilingual Plane, BMP), outside of which there are currently no assignments.

ISO / IEC 10646-1 [ISO-10646]は、世界のほとんどの書記体系を含むユニバーサル文字セット（UCS）と呼ばれるマルチオクテット文字セットを定義しています。 2つのマルチオクテットエンコーディングが定義されています。UCS-4と呼ばれる1文字あたり4オクテットのエンコーディングと、UCS-2と呼ばれる1文字あたり2オクテットで、UCSの最初の64K文字のみをアドレス指定できます（Basic Multilingual Plane、BMP ）、その外には現在割り当てがありません。

It is noteworthy that 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 implementors, but does not have the UCS-4 encoding. Up to the present time, changes in Unicode and amendments to ISO/IEC 10646 have tracked each other, so that the character repertoires and code point assignments have remained in sync. The relevant standardization committees have committed to maintain this very useful synchronism.

同じ文字セットがUnicode標準[UNICODE]によって定義されていることは注目に値します。これは、追加の文字プロパティと、実装者にとって非常に重要なその他のアプリケーションの詳細をさらに定義しますが、UCS-4エンコーディングを持ちません。現在まで、Unicodeの変更とISO / IEC 10646の修正は相互に追跡されているため、文字のレパートリーとコードポイントの割り当ては同期されたままです。関連する標準化委員会は、この非常に有用な同期を維持することを約束しています。

The UCS-2 and UCS-4 encodings, however, are hard to use in many current applications and protocols that assume 8 or even 7 bit characters. Even newer systems able to deal with 16 bit characters cannot process UCS-4 data. This situation has led to the development of so-called UCS transformation formats (UTF), each with different characteristics.

ただし、UCS-2およびUCS-4エンコードは、8ビット文字または7ビット文字を想定する現在の多くのアプリケーションおよびプロトコルで使用するのが困難です。 16ビット文字を処理できる新しいシステムでも、UCS-4データを処理できません。この状況は、それぞれ異なる特性を持つ、いわゆるUCS変換フォーマット（UTF）の開発につながりました。

UTF-1 has only historical interest, having been removed from ISO/IEC 10646. UTF-7 has the quality of encoding the full BMP repertoire using only octets with the high-order bit clear (7 bit US-ASCII values, [US-ASCII]), and is thus deemed a mail-safe encoding ([RFC2152]). UTF-8, the object of this memo, uses all bits of an octet, but has the quality of preserving the full 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 an US-ASCII character, and nothing else.

UTF-1は歴史的な関心のみを持ち、ISO / IEC 10646から削除されました。UTF-7は、高位ビットがクリアなオクテットのみを使用して完全なBMPレパートリーをエンコードする品質を備えています（7ビットUS-ASCII値、[US- ASCII]）、したがって、メールセーフなエンコーディング（[RFC2152]）と見なされます。このメモのオブジェクトであるUTF-8は、オクテットのすべてのビットを使用しますが、US-ASCII範囲全体を保持する品質を備えています。US-ASCII文字は、通常のUS-ASCII値を持つ1つのオクテットと任意のオクテットにエンコードされます。そのような値を使用すると、US-ASCII文字のみを表すことができ、それ以外は何もできません。

UTF-16 is a scheme for transforming a subset of the UCS-4 repertoire into pairs of UCS-2 values from a reserved range. UTF-16 impacts UTF-8 in that UCS-2 values from the reserved range must be treated specially in the UTF-8 transformation.

UTF-16は、UCS-4レパートリーのサブセットを予約された範囲からのUCS-2値のペアに変換するためのスキームです。予約範囲のUCS-2値はUTF-8変換で特別に処理する必要があるという点で、UTF-16はUTF-8に影響を与えます。

UTF-8 encodes UCS-2 or UCS-4 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. This transformation format has the following characteristics (all values are in hexadecimal):

UTF-8は、UCS-2またはUCS-4文字をさまざまな数のオクテットとしてエンコードします。オクテットの数とそれぞれの値は、ISO / IEC 10646で文字に割り当てられた整数値によって異なります。この変換フォーマットには、以下の特性（すべての値は16進数です）：

- Character values from 0000 0000 to 0000 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.

- 0000 0000から0000 007F（US-ASCIIレパートリー）の文字値は、オクテット00から7F（7ビットUS-ASCII値）に対応します。直接的な結果として、プレーンなASCII文字列も有効なUTF-8文字列です。

- US-ASCII 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.

- US-ASCII値は、UTF-8でエンコードされた文字ストリームでは表示されません。これは、US-ASCII値に基づいて解析するが他の値に対して透過的であるファイルシステムまたは他のソフトウェア（Cライブラリのprintf()関数など）との互換性を提供します。

- Round-trip conversion is easy between UTF-8 and either of UCS-4, UCS-2.

- UTF-8とUCS-4、UCS-2のいずれかとの間の往復変換は簡単です。

- The first octet of a multi-octet sequence indicates the number of octets in the sequence.

- マルチオクテットシーケンスの最初のオクテットは、シーケンス内のオクテットの数を示します。

- The octet values FE and FF never appear.

- オクテット値FEおよびFFは表示されません。

- Character boundaries are easily found from anywhere in an octet stream.

- 文字境界はオクテットストリームのどこからでも簡単に見つけることができます。

- The lexicographic sorting order of UCS-4 strings is preserved. Of course this is of limited interest since the sort order is not culturally valid in either case.

- UCS-4文字列の辞書式ソート順は保持されます。もちろん、並べ替えの順序はどちらの場合でも文化的に有効ではないため、これはあまり重要ではありません。

- The Boyer-Moore fast search algorithm can be used with UTF-8 data.

- Boyer-Moore高速検索アルゴリズムは、UTF-8データで使用できます。

- 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.

- 単純なアルゴリズムによって、UTF-8文字列はかなり信頼できるものとして認識できます。つまり、他のエンコーディングの文字列が有効なUTF-8として表示される確率は低く、文字列の長さが長くなるにつれて減少します。

UTF-8 was originally a project of the X/Open Joint Internationalization Group XOJIG with the objective to specify a File System Safe UCS Transformation Format [FSS-UTF] that is compatible with UNIX systems, supporting multilingual text in a single encoding. The original authors were Gary Miller, Greger Leijonhufvud and John Entenmann. Later, Ken Thompson and Rob Pike did significant work for the formal UTF-8.

UTF-8は、もともとX / Open Joint Internationalization Group XOJIGのプロジェクトで、UNIXシステムと互換性のあるファイルシステムセーフUCS変換フォーマット[FSS-UTF]を指定することを目的としており、単一のエンコーディングで多言語テキストをサポートしていました。原作者は、ゲイリーミラー、グレガーレイホンハフヴッド、ジョンエンテンマンでした。その後、ケン・トンプソンとロブ・パイクは正式なUTF-8のために重要な仕事をしました。

A description can also be found in Unicode Technical Report #4 and in the Unicode Standard, version 2.0 [UNICODE]. The definitive reference, including provisions for UTF-16 data within UTF-8, is Annex R of ISO/IEC 10646-1 [ISO-10646].

説明は、Unicode Technical Report＃4およびUnicode Standard、version 2.0 [UNICODE]にもあります。 UTF-8内のUTF-16データの規定を含む最も信頼できるリファレンスは、ISO / IEC 10646-1 [ISO-10646]のAnnex Rです。

2. UTF-8 definition

2. UTF-8定義

In UTF-8, characters are encoded using sequences of 1 to 6 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 value. 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 value 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では、文字は1〜6オクテットのシーケンスを使用してエンコードされます。 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 UCS-4 character value.

次の表は、これらのさまざまなオクテットタイプの形式をまとめたものです。文字xは、UCS-4文字値のビットのエンコードに使用できるビットを示します。

UCS-4 range (hex.) UTF-8 octet sequence (binary) 0000 0000-0000 007F 0xxxxxxx 0000 0080-0000 07FF 110xxxxx 10xxxxxx 0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx

UCS-4範囲（16進数）UTF-8オクテットシーケンス（バイナリ）0000 0000-0000 007F 0xxxxxxx 0000 0080-0000 07FF 110xxxxx 10xxxxxx 0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx

0001 0000-001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx

Encoding from UCS-4 to UTF-8 proceeds as follows:

UCS-4からUTF-8へのエンコードは次のように進行します。

1) Determine the number of octets required from the character value 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 UCS-4 character.

1）上記の表の文字値と最初の列から必要なオクテット数を決定します。テーブルの行は相互に排他的であることに注意することが重要です。つまり、特定のUCS-4文字をエンコードする有効な方法は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 value, starting from the lower-order bits of the character value and putting them first in the last octet of the sequence, then the next to last, etc. until all x bits are filled in.

3）文字値の下位ビットから始めて、シーケンスの最後のオクテットに最初に配置し、次にすべてのxまで最後の文字を配置するなど、文字値のビットからxとマークされたビットを埋めます。ビットが入力されます。

The algorithm for encoding UCS-2 (or Unicode) to UTF-8 can be obtained from the above, in principle, by simply extending each UCS-2 character with two zero-valued octets. However, pairs of UCS-2 values between D800 and DFFF (surrogate pairs in Unicode parlance), being actually UCS-4 characters transformed through UTF-16, need special treatment: the UTF-16 transformation must be undone, yielding a UCS-4 character that is then transformed as above.

UCS-2（またはUnicode）をUTF-8にエンコードするためのアルゴリズムは、原則として、それぞれのUCS-2文字を2つのゼロ値のオクテットで拡張することにより、上記から取得できます。ただし、D800とDFFFの間のUCS-2値のペア（Unicode用語ではサロゲートペア）は、実際にはUTF-16で変換されたUCS-4文字であるため、特別な処理が必要です。UTF-16変換は元に戻して、UCS-4を生成する必要があります上記のように変換される文字。

Decoding from UTF-8 to UCS-4 proceeds as follows:

UTF-8からUCS-4へのデコードは次のように進行します。

1) Initialize the 4 octets of the UCS-4 character with all bits set to 0.

1）すべてのビットを0に設定して、UCS-4文字の4オクテットを初期化します。

2) Determine which bits encode the character value 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 UCS-4 character, first the lower-order bits from the last octet of the sequence and proceeding to the left until no x bits are left.

3）シーケンスからのビットをUCS-4文字に分配します。最初にシーケンスの最後のオクテットから下位ビットを、xビットがなくなるまで左に進みます。

If the UTF-8 sequence is no more than three octets long, decoding can proceed directly to UCS-2.

UTF-8シーケンスの長さが3オクテット以下の場合、デコードは直接UCS-2に進むことができます。

NOTE -- actual implementations of the decoding algorithm above should protect against decoding invalid sequences. For instance, a naive implementation may (wrongly) decode the invalid UTF-8 sequence C0 80 into the character U+0000, which may have security consequences and/or cause other problems. See the Security Considerations section below.

注-上記のデコードアルゴリズムの実際の実装は、無効なシーケンスのデコードから保護する必要があります。たとえば、ナイーブな実装では、無効なUTF-8シーケンスC0 80を文字U + 0000に（誤って）デコードする場合があり、セキュリティ上の結果や他の問題を引き起こす可能性があります。以下の「セキュリティに関する考慮事項」セクションを参照してください。

A more detailed algorithm and formulae can be found in [FSS_UTF], [UNICODE] or Annex R to [ISO-10646].

より詳細なアルゴリズムと式は、[FSS_UTF]、[UNICODE]、または[ISO-10646]の付録Rにあります。

3. Versions of the standards

3. 標準のバージョン

ISO/IEC 10646 is updated from time to time by published amendments; similarly, different versions of the Unicode standard exist: 1.0, 1.1 and 2.0 as of this writing. Each new version obsoletes and replaces the previous one, but implementations, and more significantly data, are not updated instantly.

ISO / IEC 10646は公開された修正により随時更新されます。同様に、Unicode標準には異なるバージョンが存在します。これを書いている時点では、1.0、1.1、2.0です。新しい各バージョンは廃止され、以前のバージョンを置き換えますが、実装、さらに重要なデータは即座に更新されません。

In general, the changes amount to adding new characters, which does not pose particular problems with old data. Amendment 5 to ISO/IEC 10646, however, has moved and expanded the Korean Hangul block, thereby making any previous data containing Hangul characters invalid under the new version. Unicode 2.0 has the same difference from Unicode 1.1. The official justification for allowing such an incompatible change was that no implementations and no data containing Hangul existed, a statement that is likely to be true but remains unprovable. The incident has been dubbed the "Korean mess", and the relevant committees have pledged to never, ever again make such an incompatible change.

一般に、変更は新しい文字の追加に相当し、古いデータに特定の問題を引き起こしません。ただし、ISO / IEC 10646の修正5では韓国語のハングルブロックが移動および拡張されたため、新しいバージョンではハングル文字を含む以前のデータは無効になっています。 Unicode 2.0はUnicode 1.1と同じ違いがあります。このような互換性のない変更を許可する正当な理由は、ハングルを含む実装やデータが存在しないことでした。この事件は「韓国の混乱」と呼ばれ、関連する委員会はそのような互換性のない変更を決して二度としないことを誓約した。

New versions, and in particular any incompatible changes, have q conseuences regarding MIME character encoding labels, to be discussed in section 5.

新しいバージョン、特に互換性のない変更には、セクション5で説明するMIME文字エンコードラベルに関する注意事項があります。

4. Examples

4. 例

The UCS-2 sequence "A<NOT IDENTICAL TO><ALPHA>." (0041, 2262, 0391, 002E) may be encoded in UTF-8 as follows:

UCS-2シーケンス「A <NOT IDENTICAL TO> <ALPHA>」。（0041、2262、0391、002E）は、次のようにUTF-8でエンコードできます。

41 E2 89 A2 CE 91 2E

The UCS-2 sequence representing the Hangul characters for the Korean word "hangugo" (D55C, AD6D, C5B4) may be encoded as follows:

韓国語の単語「hangugo」のハングル文字を表すUCS-2シーケンス（D55C、AD6D、C5B4）は、次のようにエンコードされます。

ED 95 9C EA B5 AD EC 96 B4 The UCS-2 sequence representing the Han characters for the Japanese word "nihongo" (65E5, 672C, 8A9E) may be encoded as follows:

ED 95 9C EA B5 AD EC 96 B4日本語の単語「nihongo」（65E5、672C、8A9E）の漢字を表すUCS-2シーケンスは、次のようにエンコードできます。

E6 97 A5 E6 9C AC E8 AA 9E

私、右、私、私、楽器

5. MIME registration

5. MIME登録

This memo is meant to serve as the basis for registration of a MIME character set parameter (charset) [CHARSET-REG]. The proposed 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 (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.

このメモは、MIME文字セットパラメータ（charset）[CHARSET-REG]の登録の基礎となることを目的としています。提案されているcharsetパラメータ値は「UTF-8」です。この文字列は、ISO / IEC 10646のレパートリーからの文字からなるテキストを含むメディアタイプにラベルを付けます。これには、少なくとも修正5（韓国語ブロック）までのすべての修正が含まれ、上記のコード化スキームを使用してオクテットのシーケンスにエンコードされます。 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:

ラベル「UTF-8」には、一般にISO / IEC 10646を参照するバージョン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 RFC 2045, section 2.2, in [MIME]). As long as a character set standard does not change incompatibly, version numbers serve no purpose, because one gains nothing by learning from the tag that newly assigned characters may be received that one doesn't know about. The tag itself doesn't teach anything about the new characters, which are going to be received anyway.

MIME文字セットラベルは、回線上で受信した一連のバイトを一連の文字に解釈するために必要な情報のみを提供するように設計されており、それ以上のものはありません（RFC 2045、セクション2.2、[MIME]を参照）。文字セット標準が非互換に変更されない限り、バージョン番号は意味がありません。なぜなら、新しく割り当てられた文字が知られていないことを受け取っている可能性があるということをタグから知ることによって、何も得られないからです。タグ自体は、とにかく受け取る予定の新しいキャラクターについては何も教えていません。

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文字セットラベルの適切性と矛盾しています。ただし、互換性の問題は、Unicode 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の以降のバージョンで互換性のない変更が発生した場合、ここで定義されたMIME文字セットラベルは、IETFが特別に決定しない限り、以前のバージョンと調整されたままになります。

It is also proposed to register the charset parameter value "UNICODE-1-1-UTF-8", for the exclusive purpose of labelling text data containing Hangul syllables encoded to UTF-8 without taking into account Amendment 5 of ISO/IEC 10646 (i.e. using the pre-amendment 5 code point assignments). Any other UTF-8 data SHOULD NOT use this label, in particular data not containing any Hangul syllables, and it is felt important to strongly recommend against creating any new Hangul-containing data without taking Amendment 5 of ISO/IEC 10646 into account.

ISO / IEC 10646の修正5を考慮せずに、UTF-8にエンコードされたハングル音節を含むテキストデータにラベルを付けることのみを目的として、charsetパラメータ値「UNICODE-1-1-UTF-8」を登録することも提案されています。つまり、修正前の5つのコードポイント割り当てを使用します）。他のUTF-8データ、特にハングル音節を含まないデータは、このラベルを使用してはなりません。ISO/ IEC 10646の修正5を考慮せずに、新しいハングルを含むデータを作成しないことを強くお勧めします。

6. Security Considerations

6. セキュリティに関する考慮事項

Implementors 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 could 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 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.

この攻撃の特に微妙な形式は、入力のUTF-8エンコード形式に対してセキュリティクリティカルな有効性チェックを実行するが、特定の不正なオクテットシーケンスを文字として解釈するパーサーに対して実行できます。たとえば、パーサーは、単一オクテットシーケンス00としてエンコードされている場合、NUL文字を禁止しますが、不正な2オクテットシーケンスC0 80を許可し、それをNUL文字として解釈します。別の例として、オクテットシーケンス2F 2E 2E 2F（ "/../"）を禁止し、不正なオクテットシーケンス2F C0 AE 2E 2Fを許可するパーサーがあります。

Acknowledgments

謝辞

The following have participated in the drafting and discussion of this memo:

以下は、このメモの起草と議論に参加しています。

James E. Agenbroad Andries Brouwer Martin J. D|rst Ned Freed David Goldsmith Edwin F. Hart Kent Karlsson Markus Kuhn Michael Kung Alain LaBonte John Gardiner Myers Murray Sargent Keld Simonsen Arnold Winkler

James E. Agenbroad Andries Brouwer Martin J. D | first Ned Freed David Goldsmith Edwin F. Hart Kent Karlsson Markus Kuhn Michael Kung Alain LaBonte John Gardiner Myers Murray Sargent Keld Simonsen Arnold Winkler

Bibliography

参考文献

[CHARSET-REG] Freed, N., and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2278, January 1998.

[CHARSET-REG] Freed、N。、およびJ. Postel、「IANA Charset Registration Procedures」、BCP 19、RFC 2278、1998年1月。

[FSS_UTF] X/Open CAE Specification C501 ISBN 1-85912-082-2 28cm. 22p. pbk. 172g. 4/95, X/Open Company Ltd., "File System Safe UCS Transformation Format (FSS_UTF)", X/Open Preleminary Specification, Document Number P316. Also published in Unicode Technical Report #4.

[FSS_UTF] X / Open CAE仕様C501 ISBN 1-85912-082-2 28cm。 22p。 PBK。 172g。 4/95、X / Open Company Ltd。、「File System Safe UCS Transformation Format（FSS_UTF）」、X / Open Preleminary Specification、ドキュメント番号P316。 Unicode Technical Report＃4にも掲載されています。

[ISO-10646] ISO/IEC 10646-1:1993. International Standard -- Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. Five amendments and a technical corrigendum have been published up to now. UTF-8 is described in Annex R, published as Amendment 2. UTF-16 is described in Annex Q, published as Amendment 1. 17 other amendments are currently at various stages of standardization.

[ISO-10646] ISO / IEC 10646-1：1993。国際標準-情報技術-ユニバーサル複数オクテットコード化文字セット（UCS）-パート1：アーキテクチャと基本的な多言語プレーン。これまでに5つの改正と技術的な修正案が公開されています。 UTF-8は、修正2として公開された付録Rに記載されています。UTF-16は、修正1として公開された付録Qに記載されています。現在、他の17の修正が標準化のさまざまな段階にあります。

[MIME] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045. N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046. K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047. N. Freed, J. Klensin, J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048. N. Freed, N. Borenstein, " Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049. All November 1996.

[MIME] Freed、N。、およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC2045。N.Freed、N。Borenstein、「Multipurpose Internet Mail Extensions（MIME）パート2：メディアタイプ」、RFC2046。K.ムーア、「MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのメッセージヘッダー拡張」、RFC2047。N.フリード、J。クレンシン、J。ポステル、「Multipurpose Internet Mail Extensions（MIME）Part Four：Registration Procedures」、RFC2048。N.Freed、N。Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part 5：Conformance Criteria and Examples」、RFC2049。1996年11月すべて。

[RFC2152] Goldsmith, D., and M. Davis, "UTF-7: A Mail-safe Transformation Format of Unicode", RFC 1642, Taligent inc., May 1997. (Obsoletes RFC1642)

[RFC2152] Goldsmith、D。、およびM. Davis、「UTF-7：A mail-safe Transformation Format of Unicode」、RFC 1642、Taligent Inc.、1997年5月。（RFC1642の廃止）

[UNICODE] The Unicode Consortium, "The Unicode Standard -- Version 2.0", Addison-Wesley, 1996.

[UNICODE] Unicodeコンソーシアム、「The Unicode Standard-Version 2.0」、Addison-Wesley、1996。

[US-ASCII] Coded Character Set--7-bit American Standard Code for Information Interchange, ANSI X3.4-1986.

[US-ASCII]コード化文字セット-情報交換のための7ビットのアメリカ標準コード、ANSI X3.4-1986。

Author's Address

著者のアドレス

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

Francois Yergeau Alis Technologies 100、ブール。 Alexis-Nihon Suite 600 Montreal QC H4M 2P2 Canada

   Phone: +1 (514) 747-2547
   Fax:   +1 (514) 747-2561
   EMail: fyergeau@alis.com

Full Copyright Statement

完全な著作権表示

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。