RFC2044 日本語訳

2044 UTF-8, a transformation format of Unicode and ISO 10646. F.Yergeau. October 1996. (Format: TXT=11932 bytes) (Obsoleted by RFC2279) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                       F. Yergeau
Request for Comments: 2044                           Alis Technologies
Category: Informational                                   October 1996

Yergeauがコメントのために要求するワーキンググループF.をネットワークでつないでください: 2044年のAlis技術カテゴリ: 情報の1996年10月

        UTF-8, a transformation format of Unicode and ISO 10646

UTF-8、ユニコードとISO10646の変化形式

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly
   define a 16 bit character set which encompasses most of the world's
   writing systems. 16-bit 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: US-ASCII
   characters are encoded in one octet having the usual US-ASCII value,
   and any octet with such a value can only be an US-ASCII character.
   This provides compatibility with file systems, parsers and other
   software that rely on US-ASCII values but are transparent to other
   values.

ユニコードStandard、バージョン1.1、およびISO/IEC10646-1:1993は共同で世界の書記体系の大部分を包含する16ビットの文字の組を定義します。しかしながら、16ビットのキャラクタは多くの現在のアプリケーションとプロトコルと互換性がありません、そして、これはいくつかのいわゆるUCS変化形式(UTF)の開発に通じました、それぞれ異なった特性で。 UTF-8(このメモの物)には、最大限の米国-ASCII範囲を保持する特性があります: 米国-ASCII文字は普通の米国-ASCII値を持っている1つの八重奏でコード化されます、そして、そのような値があるどんな八重奏も米国-ASCII文字であるにすぎないかもしれません。 これは米国-ASCII値を当てにしていますが、他の値に見え透いたファイルシステム、パーサ、および他のソフトウェアを互換性に提供します。

1.  Introduction

1. 序論

   The Unicode Standard, version 1.1 [UNICODE], and ISO/IEC 10646-1:1993
   [ISO-10646] jointly define a 16 bit character set, UCS-2, which
   encompasses most of the world's writing systems.  ISO 10646 further
   defines a 31-bit character set, UCS-4, with currently no assignments
   outside of the region corresponding to UCS-2 (the Basic Multilingual
   Plane, BMP).  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.

ISO10646はさらに31ビットの文字の組を定義します、UCS-4、現在のどんな課題もUCS-2(基本多言語水準、BMP)に対応する領域の外にある状態で、そうしません。ユニコードStandard、バージョン1.1[ユニコード]、およびISO/IEC10646-1:1993[ISO-10646]は共同で16ビットの文字の組、UCS-2を定義します。(UCS-2は世界の書記体系の大部分を包含します)。 しかしながら、UCS-2とUCS-4 encodingsは多くの現在のアプリケーションと8を仮定するプロトコルか7ビットのキャラクタでさえ使用しにくいです。 16ビットのキャラクタに対処できるさらに新しいシステムはUCS-4データを処理できません。 この状況はそれぞれ異なった特性でいわゆるUCS変化形式(UTF)の開発につながりました。

   UTF-1 has only historical interest, having been removed from ISO
   10646.  UTF-7 has the quality of encoding the full Unicode 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
   ([RFC1642]).  UTF-8, the object of this memo, uses all bits of an
   octet, but has the quality of preserving the full US-ASCII range:

UTF-1には、ISO10646から取り除いて、歴史的な関心しかありません。 UTF-7は、高位のビットが明確な状態で八重奏だけを使用することで完全なユニコードレパートリーをコード化する品質(7は米国-ASCII値に噛み付きました、[米国-ASCII])を持って、([RFC1642])をコード化しながら、メール金庫であるとこのようにして考えられます。 UTF-8(このメモの物)には、八重奏のすべてのビットを使用しますが、最大限の米国-ASCII範囲を保持する品質があります:

Yergeau                      Informational                      [Page 1]

RFC 2044                         UTF-8                      October 1996

Yergeau[1ページ]情報のRFC2044UTF-1996年10月8日

   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.

米国-ASCII文字は正常な米国ASCII価値を持っている1つの八重奏でコード化されます、そして、そのような値があるどんな八重奏も米国-ASCII文字、および他に何もを表すことができるだけです。

   UTF-16 is a scheme for transforming a subset of the UCS-4 repertoire
   into a pair 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レパートリーの部分集合を予約された範囲から1組のUCS-2値に変えることの計画です。 UTF-16は、UTF-8変化で予約された範囲からのUCS-2値を特に扱わなければならないので、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 10646.  This
   transformation format has the following characteristics (all values
   are in hexadecimal):

UTF-8は異なった数の八重奏としてUCS-2かUCS-4キャラクタをコード化します、八重奏の数、およびそれぞれの値がISO10646のキャラクタに割り当てられた整数値によるところで。 この変化形式には、以下の特性があります(16進にすべての値があります):

   -  Character values from 0000 0000 to 0000 007F (US-ASCII repertoire)
      correspond to octets 00 to 7F (7 bit US-ASCII values).

- 文字値0000 0000〜0000 007F(米国-ASCIIレパートリー)が八重奏に00〜7F(7ビットの米国-ASCII値)対応しています。

   -  US-ASCII values do not appear otherwise in a UTF-8 encoded charac-
      ter 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 val-
      ues.

- 米国-ASCII値は現れません。そうでなければ、UTF-8では、コード化されたcharac- terは流れます。 これは米国-ASCII値に基づいて分析していますが、他のval- uesに見え透いたファイルシステムか他のソフトウェア(例えば、C図書館でのprintf()機能)を互換性に提供します。

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

- 往復変換はUCS-4、UCS-2またはユニコードのUTF-8とどちらかの間で簡単です。

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

- マルチ八重奏系列の最初の八重奏は系列の八重奏の数を示します。

   -  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 octet values FE and FF never appear.

- 八重奏値のFEとFFは決して現れません。

   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はUNIXシステムと互換性があるFile System Safe UCS Transformation Format[FSS-UTF]を指定する目的があるX/Open Joint Internationalization Group XOJIGのプロジェクトでした、単一のコード化における多言語テキストを支持して。 原作者は、ゲーリー・ミラーと、グレーガー・レイヨンフーブッドとジョンEntenmannでした。 その後、ケントンプソンとロブPikeは正式なUTF-8のために重要な仕事をしました。

Yergeau                      Informational                      [Page 2]

RFC 2044                         UTF-8                      October 1996

Yergeau[2ページ]情報のRFC2044UTF-1996年10月8日

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

また、ユニコードTechnical Report#4[UNI- CODE]で記述を見つけることができます。 UTF-8の中のUTF-16データのための条項を含む決定的な参照はISO/IEC10646-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の系列では、初期の八重奏で、高次なビットが1に設定して、続いたnは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範囲(十六進法。) 0000 0000-0000 UTF-8八重奏系列(2進の)の007Fの0xxxxxxx0000 0080-0000 07FF 110xxxxx 10xxxxxx0000 0800-0000FFFF 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

0001 0000-001 F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx0020 0000-03ff FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx0400 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.

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ビットが記入されるまで、文字値の下層階級ビットから始めて、最初に次に、系列の最後の八重奏、最終などへの次にそれらを入れて。

Yergeau                      Informational                      [Page 3]

RFC 2044                         UTF-8                      October 1996

Yergeau[3ページ]情報のRFC2044UTF-1996年10月8日

      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, UCS-2 val-
      ues between D800 and DFFF, being actually UCS-4 characters trans-
      formed through UTF-16, need special treatment: the UTF-16 trans-
      formation must be undone, yielding a UCS-4 character that is then
      transformed as above.

原則として2つの無評価された八重奏で単にそれぞれのUCS-2キャラクタを広げることによって、UCS-2(または、ユニコード)をUTF-8にコード化するためのアルゴリズムを上記に得ることができます。 しかしながら、実際にUTF-16を通して移-形成されたUCS-4キャラクタでありD800とDFFFの間のUCS-2 val- uesは特別な処理を必要とします: 移-構成がそうしなければならない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) どのビットが系列の八重奏の数と(xであるとマークされたビット)の上のテーブルに関する第2コラムから文字値をコード化するか決定してください。

   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) どんなxビットもそうでないことの最初に系列と進行の最後の八重奏から左までの下層階級左ビットの系列からUCS-4キャラクタまでのビットを分配してください。

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

直接UCS-2への解読できかける、長い間UTF-8系列が3つ未満の八重奏であるなら、(同等である、ユニコード)

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

[FSS_UTF]、[ユニコード]またはAnnex Rで[ISO-10646]において、より詳細なアルゴリズムと公式を見つけることができます。

3.  Examples

3. 例

   The Unicode sequence "A<NOT IDENTICAL TO><ALPHA>." (0041, 2262, 0391,
   002E) may be encoded as follows:

ユニコード系列「><アルファー>と同じ<NOT。」 (0041、2262、0391、002E) 以下の通りコード化されるかもしれません:

      41 E2 89 A2 CE 91 2E

41 2 89A2Ce91 2E E

   The Unicode sequence "Hi Mom <WHITE SMILING FACE>!" (0048, 0069,
   0020, 004D, 006F, 006D, 0020, 263A, 0021) may be encoded as follows:

ユニコード系列「こんにちは、おかあさんの<の白い笑っている表面>!」 (0048、0069、0020、004D、006F、006D、0020、263A、0021) 以下の通りコード化されるかもしれません:

      48 69 20 4D 6F 6D 20 E2 98 BA 21

48 69 20 4D6F6D20E2 98Ba21

   The Unicode sequence representing the Han characters for the Japanese
   word "nihongo" (65E5, 672C, 8A9E) may be encoded as follows:

"nihongo"という日本の言葉のためにハンキャラクタの代理をするユニコード系列(65E5、672C、8A9E)は以下の通りコード化されるかもしれません:

      E6 97 A5 E6 9C AC E8 AA 9E

C6 97A5E6 9交流E8EのAA9E

Yergeau                      Informational                      [Page 4]

RFC 2044                         UTF-8                      October 1996

Yergeau[4ページ]情報のRFC2044UTF-1996年10月8日

MIME registrations

MIME登録証明書

   This memo is meant to serve as the basis for registration of a MIME
   character encoding (charset) as per [RFC1521].  The proposed charset
   parameter value is "UTF-8".  This string would label media types
   containing text consisting of characters from the repertoire of ISO
   10646-1 encoded to a sequence of octets using the encoding scheme
   outlined above.

このメモは[RFC1521]に従って(charset)をコード化するMIMEキャラクタの登録の基礎として機能することになっています。 提案されたcharsetパラメタ価値は「UTF-8インチ」です。 このストリングは上に概説されたコード化計画を使用することで八重奏の系列にコード化されたISO10646-1のレパートリーからキャラクタから成るテキストを含むメディアタイプにレッテルを貼るでしょう。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Acknowledgments

承認

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

以下はこのメモの草稿と議論に参加しました:

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

ジェームスE.Agenbroad AndriesブルーエルマーチンJ.D|rstデヴィッド・ゴールドスミス・エドウィン・F.ハート・ケントカールソン・マーカス・キューン・マイケル・キュング・アラン・LaBonteマレーサージェント・Keldシモンセン・アーノルド・ウィンクラー

Bibliography

図書目録

   [FSS_UTF]      X/Open CAE Specification C501 ISBN 1-85912-082-2 28cm.
                  22p. pbk. 172g.  4/95, X/Open Company Ltd., "File Sys-
                  tem 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 ISBN1-85912-082-2 28cm。 22p. pbk。 172g。 4/95、X/Open会社株式会社、「ファイルSys- tem Safe UCS Transformation Format(FSS_UTF)」、X/Open Preleminary Specification、Document Number P316。 また、ユニコードTechnical Report#4で、発行されています。

   [ISO-10646]    ISO/IEC 10646-1:1993. International Standard -- Infor-
                  mation technology -- Universal Multiple-Octet Coded
                  Character Set (UCS) -- Part 1: Architecture and Basic
                  Multilingual Plane.  UTF-8 is described in Annex R,
                  adopted but not yet published.  UTF-16 is described in
                  Annex Q, adopted but not yet published.

[ISO-10646]ISO/IEC10646-1:1993。 国際規格--Infor- mation技術--普遍的なMultiple-八重奏Coded文字コード(UCS)--第1部: 構造と基本多言語水準。 UTF-8はAnnex Rで説明されますが、採用されますが、まだ発行されていません。 UTF-16はAnnex Qで説明されますが、採用されますが、まだ発行されていません。

   [RFC1521]      Borenstein, N., and N. Freed, "MIME (Multipurpose
                  Internet Mail Extensions) Part One: Mechanisms for
                  Specifying and Describing the Format of Internet Mes-
                  sage Bodies", RFC 1521, Bellcore, Innosoft, September
                  1993.

解放された[RFC1521]Borenstein、N.、およびN.、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットMesの賢人のBodiesのSpecifyingとDescribing Formatのためのメカニズム」、RFC1521、Bellcore、Innosoft、1993年9月。

   [RFC1641]      Goldsmith, D., and M. Davis, "Using Unicode with
                  MIME", RFC 1641, Taligent inc., July 1994.

[RFC1641] ゴールドスミス、D.とM.デイヴィス、「MIMEがあるユニコードを使用します」、RFC1641、Taligent inc、7月1994日

Yergeau                      Informational                      [Page 5]

RFC 2044                         UTF-8                      October 1996

Yergeau[5ページ]情報のRFC2044UTF-1996年10月8日

   [RFC1642]      Goldsmith, D., and M. Davis, "UTF-7: A Mail-safe
                  Transformation Format of Unicode", RFC 1642,
                  Taligent, Inc., July 1994.

[RFC1642] ゴールドスミス、D.、およびM.デイヴィス、「UTF-7:」 「ユニコードのメール安全な変化形式」、RFC1642、Taligent Inc.、1994年7月。

   [UNICODE]      The Unicode Consortium, "The Unicode Standard --
                  Worldwide Character Encoding -- Version 1.0", Addison-
                  Wesley, Volume 1, 1991, Volume 2, 1992.  UTF-8 is
                  described in Unicode Technical Report #4.

[ユニコード] ユニコード共同体、「ユニコード規格--世界的なキャラクターコード化--バージョン1インチ、アディソン・ウエスリー、1、第1991巻、2、第1992巻。」 UTF-8はユニコードTechnical Report#4で説明されます。

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

[米国-ASCII]は文字コードをコード化しました--7ビットの情報交換用米国標準コード、ANSI X3.4-1986。

Author's Address

作者のアドレス

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

フランソアYergeau Alis Technologies100、boul。 アレックサス-日本スイート600モントリオールQC H4M 2P2カナダ

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

Tel: +1 (514) 747-2547Fax: +1 (514) 747-2561 メールしてください: fyergeau@alis.com

Yergeau                      Informational                      [Page 6]

Yergeau情報です。[6ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

Clock クロック

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る