RFC1641 日本語訳

Network Working Group                                       D. Goldsmith
Request for Comments: 1641                                      M. Davis
Category: Experimental                                    Taligent, Inc.
                                                               July 1994

コメントを求めるワーキンググループD.ゴールドスミス要求をネットワークでつないでください: 1641年のM.デイヴィスカテゴリ: 実験的なTaligent Inc.1994年7月

                        Using Unicode with MIME

MIMEがあるユニコードを使用します。

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Distribution of this memo is unlimited.

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

Abstract

要約

   The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993(E)
   jointly define a 16 bit character set (hereafter referred to as
   Unicode) which encompasses most of the world's writing systems.
   However, Internet mail (STD 11, RFC 822) currently supports only 7-
   bit US ASCII as a character set. MIME (RFC 1521 and RFC 1522) extends
   Internet mail to support different media types and character sets,
   and thus could support Unicode in mail messages. MIME neither defines
   Unicode as a permitted character set nor specifies how it would be
   encoded, although it does provide for the registration of additional
   character sets over time.

1993(E)は共同で世界の書記体系の大部分を包含する16ビットの文字集合(今後ユニコードと呼ばれる)を定義します。ユニコードStandard、バージョン1.1、およびISO/IEC10646-1: しかしながら、インターネット・メール(STD11、RFC822)は、現在、文字集合として唯一の7ビットが米国ASCIIであるとサポートします。 MIME(RFC1521とRFC1522)は、異なったメディアがタイプと文字集合であるとサポートするためにインターネット・メールを広げていて、その結果、メール・メッセージのユニコードをサポートするかもしれません。 MIMEは、受入れられた文字集合とユニコードを定義しないで、またそれがどうコード化されるだろうかを指定しません、時間がたつにつれて、追加文字セットの登録に備えますが。

   This document specifies the usage of Unicode within MIME.

このドキュメントはMIMEの中でユニコードの用法を指定します。

Motivation

動機

   Since Unicode is starting to see widespread commercial adoption,
   users will want a way to transmit information in this character set
   in mail messages and other Internet media. Since MIME was expressly
   designed to allow such extensions and is on the standards track for
   the Internet, it is the most appropriate means for encoding Unicode.
   RFC 1521 and RFC 1522 do not define Unicode as an allowed character
   set, but allow registration of additional character sets.

ユニコードが広範囲の商業採用を見始めているので、ユーザはメール・メッセージと他のインターネットメディアでこの文字集合における情報を伝える方法が欲しくなるでしょう。 MIMEはそのような拡大を許すように明白に設計されて、インターネットへの標準化過程の上にあるので、それはユニコードをコード化するための最も適切な手段です。 RFC1521とRFC1522は許容文字集合とユニコードを定義しませんが、追加文字セットの登録を許してください。

   In addition to allowing use of Unicode within MIME bodies, another
   goal is to specify a way of using Unicode that allows text which
   consists largely, but not entirely, of US-ASCII characters to be
   represented in a way that can be read by mail clients who do not
   understand Unicode. This is in keeping with the philosophy of MIME.
   Such an encoding is described in another document, "UTF-7: A Mail
   Safe Transformation Format of Unicode" [UTF-7].

MIME本体の中でユニコードの使用を許すことに加えて、別の目標は主に成るテキストを許容するユニコードを使用しますが、完全に使用するというわけではない米国-ASCII文字のユニコードを理解していないメールクライアントが読むことができる方法で表されるべき方法を指定することです。 これはMIMEの哲学に従っています。 そのようなコード化が別のドキュメントで説明される、「UTF-7:」 「ユニコードのメールの安全な変換形式。」[UTF-7]

Goldsmith & Davis                                               [Page 1]

RFC 1641                Using Unicode with MIME                July 1994

1994年7月にMIMEがあるユニコードを使用するゴールドスミスとデイヴィス[1ページ]RFC1641

Overview

概要

   Several ways of using Unicode are possible. This document specifies
   both guidelines for use of Unicode within MIME, and a specific usage.
   The usage specified in this document is a straightforward use of
   Unicode as specified in "The Unicode Standard, Version 1.1".

ユニコードを使用するいくつかの方法が可能です。 このドキュメントはMIMEの中のユニコードの使用のためのガイドラインと特定の用法の両方を指定します。 本書では指定された用法は「標準のユニコードバージョン1.1インチ」の指定されるとしてのユニコードの簡単な使用です。

   This encoding is intended for situations where sender and recipient
   do not want to do a lot of processing, when the text does not consist
   primarily of characters from the US-ASCII character set, or when
   sender and receiver are known in advance to support Unicode.

このコード化は送付者と受取人が多くの処理をしたがっていない状況のために意図します、テキストが米国-ASCII文字の組からの主としてキャラクタから成らないか、またはあらかじめ送付者と受信機がユニコードをサポートするのが知られていると。

   Another encoding is intended for situations where the text consists
   primarily of US-ASCII, with occasional characters from other parts of
   Unicode. This encoding allows the US-ASCII portion to be read by all
   recipients without having to support Unicode. This encoding is
   specified in another document, "UTF-7: A Mail Safe Transformation
   Format of Unicode" [UTF-7].

別のコード化はテキストが主として米国-ASCIIから成る状況のために意図します、ユニコードの他の部分からの時々のキャラクタと共に。 このコード化は、米国-ASCII部分がユニコードをサポートする必要はなくてすべての受取人によって読まれるのを許容します。 このコード化が別のドキュメントで指定される、「UTF-7:」 「ユニコードのメールの安全な変換形式。」[UTF-7]

   Finally, in keeping with the principles set forth in RFC 1521, text
   which can be represented using the US-ASCII or ISO-8859-x character
   sets should be so represented where possible, for maximum
   interoperability.

最終的に、原則がRFC1521に詳しく説明されている状態で保つ際に、米国-ASCIIかISO-8859-x文字集合を使用することで表すことができるテキストはそのように可能であるところに表されるべきです、最大限のインターオペラビリティのために。

Definitions

定義

   The definition of character set Unicode:

文字集合ユニコードの定義:

      The 16 bit character set Unicode is defined by "The Unicode
      Standard, Version 1.1". This character set is identical with the
      character repertoire and coding of the international standard
      ISO/IEC 10646-1:1993(E); Coded Representation Form=UCS-2;
      Subset=300; Implementation Level=3.

16ビットの文字集合ユニコードは「標準のユニコードバージョン1.1インチ」によって定義されます。 この文字集合は世界規格ISO/IEC10646-1のキャラクタレパートリーとコード化と同じです: 1993(E) コード値フォームはUCS-2と等しいです。 部分集合=300。 実装レベル=3。

      Note. Unicode 1.1 further specifies the use and interaction of
      these character codes beyond the ISO standard. However, any valid
      10646 BMP (Basic Multilingual Plane) sequence is a valid Unicode
      sequence, and vice versa; Unicode supplies interpretations of
      sequences on which the ISO standard is silent as to
      interpretation.

注意します。 ユニコード1.1はさらにISO規格を超えてこれらのキャラクタコードの使用と相互作用を指定します。 しかしながら、どんな有効な10646BMP(基本多言語水準)系列も有効なユニコード系列です、そして、逆もまた同様です。 ユニコードはISO規格が解釈に関して静かである系列の解釈を供給します。

      This character set is encoded as sequences of octets, two per 16-
      bit character, with the most significant octet first. Text with an
      odd number of octets is ill-formed.

この文字集合は八重奏の系列としてコード化されて、16あたり2は最初に、最も重要な八重奏でキャラクタに噛み付きました。 八重奏の奇数があるテキストは不適格です。

      Rationale. ISO/IEC 10646-1:1993(E) specifies that when characters
      in the UCS-2 form are serialized as octets, that the most
      significant octet appear first.  This is also in keeping with

原理。 ISO/IEC10646-1: 八重奏、その最も重要な八重奏が最初に現れるようにUCS-2フォームでのキャラクタが連載されるとき、1993(E)はそれを指定します。 キープにはこれはあります。

Goldsmith & Davis                                               [Page 2]

RFC 1641                Using Unicode with MIME                July 1994

1994年7月にMIMEがあるユニコードを使用するゴールドスミスとデイヴィス[2ページ]RFC1641

      common network practice of choosing a canonical format for
      transmission.

トランスミッションのための正準な形式を選ぶ一般的なネットワーク習慣。

General Specification of Unicode Character Sets Within MIME

MIMEの中のユニコード文字コードに関する一般仕様

   The Unicode Standard is currently at version 1.1. Although new
   versions should be compatible with old implementations if an
   implementation is compliant with the standard, some implementations
   may choose to check the version of the character set that is being
   used. In order to allow some implementations to check the version
   number and allow others to ignore it, all registrations of Unicode
   variants and versions for MIME usage should have MIME charset names
   which conform to one of the two following patterns:

現在、バージョン1.1にはユニコードStandardがあります。 実装が規格で対応であるなら、新しいバージョンは古い実装と互換性があるべきですが、いくつかの実装が、使用されている文字集合のバージョンをチェックするのを選ぶかもしれません。 いくつかの実装が、バージョン番号をチェックして、他のものがそれを無視するのを許容するのを許容するために、MIME用法のためのユニコード異形とバージョンのすべての登録証明書には、2つの次のパターンの1つに従うMIME charset名があるべきです:

      UNICODE-major-minor
      UNICODE-major-minor-variant

ユニコードの主要な未成年者のユニコードの主要な小さい方の異形

   Where major and minor are strings of decimal digits (0 through 9)
   specifying the major and minor version number of the Unicode standard
   to which the text in question conforms. In the interests of
   interoperability, the lowest version number compatible with the text
   should be used. The lowest acceptable version number is UNICODE-1-1,
   corresponding to "The Unicode Standard, Version 1.1". The optional
   trailing string "variant" describes the particular transformation
   format of Unicode that the registration describes; its content is up
   to the particular registration. If there is no trailing variant
   string, the charset name refers to the basic two octet form of
   Unicode as described in "The Unicode Standard".

主要であって、小さい方であるところでは、問題のテキストが従うユニコード規格の主要で小さい方のバージョン番号を指定する10進数字(0〜9)のストリングがそうです。相互運用性のために、テキストとのコンパチブル最も下位のバージョン番号は使用されるべきです。 最も下位の許容できるバージョン番号は「標準のユニコードバージョン1.1インチ」に対応するユニコード1-1です。 任意の引きずっているストリング「異形」は登録が説明するユニコードの特定の変換形式について説明します。 内容は特定の登録まで達しています。 引きずっている異形ストリングが全くなければ、charset名は「ユニコード規格」で説明されるように基本的な2八重奏フォームのユニコードを参照します。

   Example. A hypothetical charset which referred to the UTF-8
   transformation format of Unicode/10646 (also known as UTF-2 or UTF-
   FSS) might be named UNICODE-1-1-UTF-8.

例。 ユニコード/10646(また、UTF-2かUTF- FSSとして、知られている)のUTF-8変換書式を示した仮定しているcharsetはユニコード1-1UTF-8と命名されるかもしれません。

Encoding Character Set Unicode Within MIME

MIMEの中で文字コードユニコードをコード化します。

   Character set Unicode uses 16 bit characters, and therefore would
   normally be used with the Binary or Base64 content transfer encodings
   of MIME. In header fields, it would normally be used with the B
   content transfer encoding. The MIME character set identifier is
   UNICODE-1-1.

文字集合ユニコードは、16ビットのキャラクタを使用して、したがって、通常、MIMEのBinaryかBase64内容転送encodingsと共に使用されるでしょう。 ヘッダーフィールドでは、通常、それはB内容転送コード化と共に使用されるでしょう。 MIME文字集合識別子はユニコード1-1です。

   Example. Here is a text portion of a MIME message containing the
   Japanese word "nihongo" (hexadecimal 65E5,672C,8A9E) written in Han
   characters.

例。 ここに、投稿という日本の単語"nihongo"(65 16進5,672E C、8A9E)ハンキャラクタを含んでいて、MIMEメッセージのテキスト部分があります。

   Content-Type: text/plain; charset=UNICODE-1-1
   Content-Transfer-Encoding: base64

コンテントタイプ: テキスト/平野。 内容がコード化を移した状態で、charsetはユニコード1-1と等しいです: base64

Goldsmith & Davis                                               [Page 3]

RFC 1641                Using Unicode with MIME                July 1994

1994年7月にMIMEがあるユニコードを使用するゴールドスミスとデイヴィス[3ページ]RFC1641

   ZeVnLIqe

ZeVnLIqe

   Example. Here is a text portion of a MIME message containing the
   Unicode sequence "A<NOT IDENTICAL TO><ALPHA>." (hexadecimal
   0041,2262,0391,002E)

例。 ここに、ユニコード系列「><アルファー>と同じ<NOT」を含んでいて、MIMEメッセージのテキスト部分があります。 (16進0041、2262、0391、002E)

   Content-Type: text/plain; charset=UNICODE-1-1
   Content-Transfer-Encoding: base64

コンテントタイプ: テキスト/平野。 内容がコード化を移した状態で、charsetはユニコード1-1と等しいです: base64

   AEEiYgORAC4=

AEEiYgORAC4=

Acknowledgements

承認

   Many thanks to the following people for their contributions,
   comments, and suggestions. If we have omitted anyone it was through
   oversight and not intentionally.

彼らの貢献、コメント、および提案のために以下の人々をありがとうございます。 私たちがだれでも省略したなら、それは故意にであったのではなく、見落としでありました。

         Glenn Adams
         Harald T. Alvestrand
         Nathaniel Borenstein
         Lee Collins
         Jim Conklin
         Dave Crocker
         Steve Dorner
         Dana S. Emery
         Ned Freed
         John H. Jenkins
         John C. Klensin
         Valdis Kletnieks
         Keith Moore
         Masataka Ohta
         Einar Stefferud

グレン・アダムス・ハラルド・T.Alvestrandナザニエル・Borenstein Lee Collins・ジム・コンクリン・デーヴ・Crockerスティーブ・デルナー・ダナ・S.EmeryネッドはジョンH.ジェンキンスジョンC.KlensinヴァルディスKletnieksキースムーアMasataka太田Einar Stefferudを解放しました。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

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

References

参照

[UNICODE 1.1] "The Unicode Standard, Version 1.1": Version 1.0, Volume 1
              (ISBN 0-201-56788-1), Version 1.0, Volume 2 (ISBN 0-201-
              60845-6), and "Unicode Technical Report #4, The Unicode
              Standard, Version 1.1" (available from The Unicode
              Consortium, and soon to be published by Addison-Wesley).

[ユニコード1.1]、「標準のユニコードバージョン1.1インチ:」 そして、バージョン1.0、Volume1(ISBN0-201-56788-1)、バージョン1.0、Volume2(ISBN0-201- 60845-6)、「ユニコード技術報告書#4、標準のユニコードバージョン1.1インチ、(ユニコード共同体から利用可能である、アディソン-ウエスリーによってすぐ発行される、)、」

[ISO 10646]   ISO/IEC 10646-1:1993(E) Information Technology--Universal
              Multiple-octet Coded Character Set (UCS).

[ISO10646] ISO/IEC10646-1: 1993(E)情報技術--普遍的な複数の八重奏は文字コード(UCS)をコード化しました。

Goldsmith & Davis                                               [Page 4]

RFC 1641                Using Unicode with MIME                July 1994

1994年7月にMIMEがあるユニコードを使用するゴールドスミスとデイヴィス[4ページ]RFC1641

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

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

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

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

[ISO-8859]    Information Processing -- 8-bit Single-Byte Coded Graphic
              Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-
              1:1987.  Part 2: Latin alphabet No.  2, ISO 8859-2, 1987.
              Part 3: Latin alphabet No. 3, ISO 8859-3, 1988.  Part 4:
              Latin alphabet No.  4, ISO 8859-4, 1988.  Part 5:
              Latin/Cyrillic alphabet, ISO 8859-5, 1988.  Part 6:
              Latin/Arabic alphabet, ISO 8859-6, 1987.  Part 7:
              Latin/Greek alphabet, ISO 8859-7, 1987.  Part 8:
              Latin/Hebrew alphabet, ISO 8859-8, 1988.  Part 9: Latin
              alphabet No. 5, ISO 8859-9, 1990.

[ISO-8859]情報処理--8ビットの単一のバイトコード化された図形文字セット--第1部: ローマ字No.1、ISO8859- 1:1987。 第2部: ローマ字No.2、ISO8859-2、1987。 パート3: ローマ字No.3、ISO8859-3、1988。 パート4: ローマ字No.4、ISO8859-4、1988。 パート5: ラテン/キリル文字、ISO8859-5、1988。 パート6: ラテン/アラビア文字、ISO8859-6、1987。 パート7: ラテン/ギリシャ語アルファベット、ISO8859-7、1987。 パート8: ラテン語の、または、ヘブライのアルファベット、ISO8859-8、1988。 パート9: ローマ字No.5、ISO8859-9、1990。

[RFC822]      Crocker, D., "Standard for the Format of ARPA Internet
              Text Messages", STD 11, RFC 822, UDEL, August 1982.

[RFC822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。

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

解放された[RFC-1521]Borenstein N.、およびN.、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1521、Bellcore、Innosoft、1993年9月。

[RFC-1522]    Moore, K., "Representation of Non-Ascii Text in Internet
              Message Headers" RFC 1522, University of Tennessee,
              September 1993.

[RFC-1522] ムーア、K.、「インターネットメッセージヘッダーの非アスキーテキストの表現」RFC1522、テネシー大学、1993年9月。

[UTF-8]       X/Open Company Ltd., "File System Safe UCS Transformation
              Format (FSS_UTF)", X/Open Preliminary Specification,
              Document Number: P316. This information also appears in
              Unicode Technical Report #4, and in a forthcoming annex to
              ISO/IEC 10646.

[UTF-8]X/Open会社株式会社、「ファイルのシステムの安全なUCS変換形式(FSS_UTF)」、X/Openの予備の仕様は数を記録します: P316。 また、この情報はユニコードTechnical Report#4、およびISO/IEC10646への今度の別館に現れます。

Goldsmith & Davis                                               [Page 5]

RFC 1641                Using Unicode with MIME                July 1994

1994年7月にMIMEがあるユニコードを使用するゴールドスミスとデイヴィス[5ページ]RFC1641

Authors' Addresses

作者のアドレス

   David Goldsmith
   Taligent, Inc.
   10201 N. DeAnza Blvd.
   Cupertino, CA 95014-2233

デヴィッドゴールドスミスTaligent Inc.10201N.DeAnza Blvd. カルパチーノ、カリフォルニア95014-2233

   Phone: 408-777-5225
   Fax: 408-777-5081
   EMail: david_goldsmith@taligent.com

以下に電話をしてください。 408-777-5225 Fax: 408-777-5081 メールしてください: david_goldsmith@taligent.com

   Mark Davis
   Taligent, Inc.
   10201 N. DeAnza Blvd.
   Cupertino, CA 95014-2233

マーク・デイビスTaligent Inc.10201N.DeAnza Blvd. カルパチーノ、カリフォルニア95014-2233

   Phone: 408-777-5116
   Fax: 408-777-5081
   EMail: mark_davis@taligent.com

以下に電話をしてください。 408-777-5116 Fax: 408-777-5081 メールしてください: mark_davis@taligent.com

Goldsmith & Davis                                               [Page 6]

ゴールドスミスとデイヴィス[6ページ]