Network Working Group
Request for Comments: 2046
Obsoletes: 1521, 1522, 1590
Updated by: 2646, 3798, 5147, 6657, 8098
Category: Standards Track
Multipurpose Internet Mail Extensions
(MIME) Part Two:
Media Types
[多目的インターネットメール拡張]
(MIME) パート2:
メディアタイプ
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
摘要
STD 11, RFC 822 defines a message representation protocol specifying considerable detail about US-ASCII message headers, but which leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for
STD 11、RFC 822は、US-ASCIIメッセージヘッダについてのかなりの詳細であるがどれがメッセージ中身または本文を置いていくかを指定しているメッセージ表現プロトコルを平らなUS-ASCIIテキストと定義します。多目的のインターネットメール拡張またはMIMEと集合的に呼ばれる文書のこのセットは、可能にするメッセージ形式を再定義します。
-
textual message bodies in character sets other than US-ASCII,
US-ASCII以外のキャラクタセットの中の原文の本文
-
an extensible set of different formats for non-textual message bodies,
非原文の本文のための違うフォーマットの拡張可能なセット
-
multi-part message bodies, and
マルチパート本文、および
-
textual header information in character sets other than US-ASCII.
US-ASCII以外のキャラクタセットの中の原文のヘッダー情報。
These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.
これらの文書は、RFC 934、STD 11において文書化されたより早い仕事に基づき、RFC 1049けれどもそれらを拡張し、改訂します。RFC 822が本文についてほとんどそう言わなかったので、これらの文書は主としてRFC 822(というよりも改正)に同列です。
The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. This second document defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.
このセットにおける初期の文書、RFC 2045は、MIMEメッセージの構造を説明するために使われた様々なヘッダーを指定します。 この2番目の文書はMIMEメディアタイピングシステムの一般の構造を定義し、メディアタイプの初期のセットを定義します。 インターネットメールヘッダーフィールドで非[non-US]-ASCIIテキストデータを許すために、3番目の文書、RFC 2047はRFC 822への拡張を説明します。 4番目の文書、RFC 2048はMIMEに関連した施設のための様々なIANA登録手続を指定します。MIMEメッセージフォーマット、肯定応答、および文献目録のいくつかの説明に役立つ実例を提供することと同様に、5番目の、そして最終的な文書、RFC 2049はMIME対応標準を説明します。
These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions.
これらの文書は、RFC 1521と1522、自身のどれがRFC 1341のリビジョンであったかのリビジョンと1342です。RFC 2049の中の付録は違いを説明し、前のバージョンから変わります。
Table of Contents
目次
2. トップレベルメディアタイプの定義
3. 初期のトップレベルメディアタイプの概要
4. 離散メディアタイプの値
4.1 Text メディアタイプ
4.1.1 改行の表現
4.1.2 Charset パラメータ
4.1.3 Plain サブタイプ
4.1.4 未認識のサブタイプ
4.2 Image メディアタイプ
4.3 Audio メディアタイプ
4.4 Video メディアタイプ
4.5 Application メディアタイプ
4.5.1 Octet-Stream サブタイプ
4.5.2 PostScript サブタイプ
4.5.3 他の Application サブタイプ
5. Composite メディアタイプの値
5.1 Multipart メディアタイプ
5.1.1 共通構文
5.1.2 ネストされた Messages と Multiparts の取り扱い
5.1.3 Mixed サブタイプ
5.1.4 Alternative サブタイプ
5.1.5 Digest サブタイプ
5.1.6 Parallel サブタイプ
5.1.7 他の Multipart サブタイプ
5.2 Message メディアタイプ
5.2.1 RFC822 サブタイプ
5.2.2 Partial サブタイプ
5.2.2.1 メッセージフラグメンテーションと再アセンブリ
5.2.2.2 フラグメンテーションと再アセンブリの例
5.2.3 External-Body サブタイプ
5.2.3.1 一般 External-Body パラメータ
5.2.3.2 「ftp」と「tftp」アクセスタイプ
5.2.3.3 「anon-ftp」アクセスタイプ
5.2.3.4 「local-file」アクセスタイプ
5.2.3.5 「mail-server」アクセスタイプ
5.2.3.6 External-Body セキュリティ問題
5.2.3.7 例と更なる説明
5.2.4 他の Message サブタイプ
6. 実験的メディアタイプ値
7. 要約
8. セキュリティ対策
9. 奥付
A. 収集された文法
1. Introduction
はじめに
The first document in this set, RFC 2045, defines a number of header fields, including Content-Type. The Content-Type field is used to specify the nature of the data in the body of a MIME entity, by giving media type and subtype identifiers, and by providing auxiliary information that may be required for certain media types. After the type and subtype names, the remainder of the header field is simply a set of parameters, specified in an attribute/value notation. The ordering of parameters is not significant.
内部形式を含めて、このセットにおける最初の文書、RFC 2045は多くのヘッダーフィールドと定義します。 Content-Typeフィールドは、メディアタイプとサブタイプ識別子を与えることによって、そして一定のメディアタイプのために必要とされているかもしれない補助の情報を提供することによってMIME実体のボディの中のデータの性質を指定するために使われます。タイプとサブタイプの名の後で、属性/値の表記法の中で指定されて、ヘッダーフィールドの剰余はパラメータの単にセットです。パラメータの記述は有意でありません。
In general, the top-level media type is used to declare the general type of data, while the subtype specifies a specific format for that type of data. Thus, a media type of "image/xyz" is enough to tell a user agent that the data is an image, even if the user agent has no knowledge of the specific image format "xyz". Such information can be used, for example, to decide whether or not to show a user the raw data from an unrecognized subtype -- such an action might be reasonable for unrecognized subtypes of "text", but not for unrecognized subtypes of "image" or "audio". For this reason, registered subtypes of "text", "image", "audio", and "video" should not contain embedded information that is really of a different type. Such compound formats should be represented using the "multipart" or "application" types.
一般に、トップレベルのメディアタイプは、データの一般のタイプを宣言するために使われる一方、サブタイプはそのタイプのデータのために特定のフォーマットを指定します。従って、「image/xyz」のメディアタイプは、ユーザエージェントに、ユーザエージェントが特定のイメージ形式「xyz」に関する知識を全然持っていなくても、データがイメージであると言うのに十分です。そのような情報は、例えば、認められないサブタイプからユーザに生データを示すかどうかを決めるために使われることができます--そのような行動は「テキスト」の認められないサブタイプのために妥当であるかもしれないけれども、「イメージ」または「オーディオ」の認められないサブタイプのために妥当であることができません。この理由のために、「テキスト」、「イメージ」、「オーディオ」、および「ビデオ」の登録されたサブタイプは、本当に、違うタイプをもっている埋め込まれた情報を含むべきでありません。 そのような複合データ形式は、「multipart」または「application」タイプを使って、表されているべきです。
Parameters are modifiers of the media subtype, and as such do not fundamentally affect the nature of the content. The set of meaningful parameters depends on the media type and subtype. Most parameters are associated with a single specific subtype. However, a given top-level media type may define parameters which are applicable to any subtype of that type. Parameters may be required by their defining media type or subtype or they may be optional. MIME implementations must also ignore any parameters whose names they do not recognize.
パラメータはメディアサブタイプの修飾子であり、そのようなものとして、根本的に内容の性質に影響しません。有意味のパラメータのセットはメディアタイプとサブタイプに依存します。ほとんどのパラメータはシングルで特定のサブタイプと関連づけられます。しかし、与えられたトップレベルのメディアタイプは、そのタイプのどのようなサブタイプにでも適用可能なパラメータを定義するかもしれません。パラメータは、彼らがメディアタイプまたはサブタイプを定義することによって必要とされているかもしれないか、それらはオプションであるかもしれません。MIMEの実装は、また、彼らが名前と認めていないどのようなパラメータでも無視しなければなりません。
MIME's Content-Type header field and media type mechanism has been carefully designed to be extensible, and it is expected that the set of media type/subtype pairs and their associated parameters will grow significantly over time. Several other MIME facilities, such as transfer encodings and "message/external-body" access types, are likely to have new values defined over time. In order to ensure that the set of such values is developed in an orderly, well-specified, and public manner, MIME sets up a registration process which uses the Internet Assigned Numbers Authority (IANA) as a central registry for MIME's various areas of extensibility. The registration process for these areas is described in a companion document, RFC 2048.
MIMEのContent-Typeヘッダーフィールドとメディアタイプメカニズムは、拡張可能なために慎重に設計されていて、メディアタイプ/サブタイプのペアとそれらの関連づけられたパラメータのセットが時間とともにかなり覆うであろうということは予期されています。転送エンコーディングと「メッセージ/外部ボディ」アクセスタイプなどのいくつかの他のMIME施設は、時間とともに定義された新しい値を持ちそうです。そのような値のセットが整然とし、よく指定されて、公開の方法で発展させられると保証するために、MIMEは、拡張性のMIMEの様々なエリアのために中央のレジストリーとして数権限(IANA)を割り当てられたインターネットを使う登録手続を設定します。これらのエリアのための登録手続は友人文書、RFC 2048の中で説明されます。
The initial seven standard top-level media type are defined and described in the remainder of this document.
7つの標準のトップレベルのメディアタイプはこの文書の中で定義されて、説明されます。
2. Definition of a Top-Level Media Type
トップレベルメディアタイプの定義
The definition of a top-level media type consists of:
トップレベルのメディアタイプの定義は次から成ります：
-
a name and a description of the type, including criteria for whether a particular type would qualify under that type,
特定タイプがそのタイプの下で資格を与えるであろうかどうかのために標準を含むタイプの名前と説明
-
the names and definitions of parameters, if any, which are defined for all subtypes of that type (including whether such parameters are required or optional),
パラメータ、もしあればどれが、そのタイプ(そのようなパラメータが必要とされているか、オプションであるかどうかにかかわらず含み)のすべてのサブタイプのために定義されるかの名前と定義
-
how a user agent and/or gateway should handle unknown subtypes of this type,
どんなに、ユーザエージェント、および／またはゲートウェイはこのタイプの未知のサブタイプを処理するべきであるのでしょうか。
-
general considerations on gatewaying entities of this top-level type, if any, and
もしあればこのトップレベルのタイプの実体をgatewayingすることにおける一般の考慮、および
-
any restrictions on content-transfer-encodings for entities of this top-level type.
このトップレベルのタイプの実体のためのcontent-transfer-encodingsにおけるどのような制限でも。
3. Overview Of The Initial Top-Level Media Types
初期のトップレベルメディアタイプの概要
The five discrete top-level media types are:
5種類の離散的なトップレベルのメディアタイプは以下の通りです：
-
text -- textual information. The subtype "plain" in particular indicates plain text containing no formatting commands or directives of any sort. Plain text is intended to be displayed "as-is". No special software is required to get the full meaning of the text, aside from support for the indicated character set. Other subtypes are to be used for enriched text in forms where application software may enhance the appearance of the text, but such software must not be required in order to get the general idea of the content. Possible subtypes of "text" thus include any word processor format that can be read without resorting to software that understands the format. In particular, formats that employ embeddded binary formatting information are not considered directly readable. A very simple and portable subtype, "richtext", was defined in RFC 1341, with a further revision in RFC 1896 under the name "enriched".
テキスト。特にサブタイプ「平易です」はどのようなソートの書式作成コマンドまたは指示語も全然含んでいない普通テキストを示します。 普通テキストは、表示された「現状のまま」であることを意図しています。 どの特殊なソフトウェアも、示された文字セットへの支持は別としてテキストの完全な意味を理解するために必要とされていません。 アプリケーションソフトウェアがテキストの外観を強化するかもしれない所で、他のサブタイプは、形式における豊かにされたテキストのために使われることになっているけれども、そのようなソフトウェアは、コンテンツの概念を理解するために必要とされていてはなりません。従って、「テキスト」の可能なサブタイプは、フォーマットを理解しているソフトウェアにたよらないで読まれることができるどのようなワードプロセッサフォーマットでも含みます。特に、embedddedされた2進のフォーマッティング情報を使用するフォーマットは直接読取り可能であると考えられません。 非常に単純で、ポータブルなサブタイプ、「richtext」は、名前の、「豊かにされます」下のRFC 1896中のさらなるリビジョンによってRFC 1341中で定義されました。
-
image -- image data. "Image" requires a display device (such as a graphical display, a graphics printer, or a FAX machine) to view the information. An initial subtype is defined for the widely-used image format JPEG. . subtypes are defined for two widely-used image formats, jpeg and gif.
イメージデータ。情報を見るために、「イメージ」は表示装置(グラフィカルなディスプレイ、グラフィックスプリンタ、またはファックス・マシンなどの)を必要としています。 初期のサブタイプは広く使われたイメージ形式JPEGのために定義されます。サブタイプは2つの広く使われたイメージ形式、jpeg、およびgifのために定義されます。
-
audio -- audio data. "Audio" requires an audio output device (such as a speaker or a telephone) to "display" the contents. An initial subtype "basic" is defined in this document.
音声データ。内容を「表示する」ために、「オーディオ」は音声出力デバイス(スピーカーまたは電話機などの)を必要としています。初期のサブタイプ「基本です」はこの文書の中で定義されます。
-
video -- video data. "Video" requires the capability to display moving images, typically including specialized hardware and software. An initial subtype "mpeg" is defined in this document.
ビデオデータ。「ビデオ」は、一般に専門的なハードウェアとソフトウェアを含めて、動画を表示する機能を必要としています。初期のサブタイプ「mpeg」はこの文書の中で定義されます。
-
application -- some other kind of data, typically either uninterpreted binary data or information to be processed by an application. The subtype "octet-stream" is to be used in the case of uninterpreted binary data, in which case the simplest recommended action is to offer to write the information into a file for the user. The "PostScript" subtype is also defined for the transport of PostScript material. Other expected uses for "application" include spreadsheets, data for mail-based scheduling systems, and languages for "active" (computational) messaging, and word processing formats that are not directly readable. Note that security considerations may exist for some types of application data, most notably "application/PostScript" and any form of active messaging. These issues are discussed later in this document.
他の種類のデータ(一般に、アプリケーションによって処理される解釈されていない2進データまたは情報のどちらか)。サブタイプ「8ビットバイトストリーム」は、解釈されていない2進データの場合に使われることになっています(そのケースの中で、最も簡単な推奨された行動は、ユーザのためにファイルの中に情報を書き込むことを申し出ることです)。「PostScript」サブタイプはPostScript素材のトランスポートのためにまた定義されます。「アプリケーション」のための他の予期されている用途は、スプレッドシート、メールベースのスケジューリングシステムのためのデータ、および直接読取り可能でない「アクティブな」(計算です)メッセージで送り、ワードプロセッシングのフォーマットのための言語を含みます。セキュリティ考慮がいくつかのタイプのアプリケーションデータ、最も特に「アプリケーション/PostScript」、およびアクティブにメッセージで送ることのすべての形式のために存在するかもしれないことに注意してください。これらの問題はこの文書の中で後で議論されます。
The two composite top-level media types are:
2種類の複合のトップレベルのメディアタイプは以下の通りです：
-
multipart -- data consisting of multiple entities of independent data types. Four subtypes are initially defined, including the basic "mixed" subtype specifying a generic mixed set of parts, "alternative" for representing the same data in multiple formats, "parallel" for parts intended to be viewed simultaneously, and "digest" for multipart entities in which each part has a default type of "message/rfc822".
独立なデータ型の複数の実体から成るデータ。4つのサブタイプが、複数における同じデータが、同時に見られることを意図している部分のための「parallel(並列)」と各部分が「message/rfc822」のデフォルトタイプを持っている複数パート実体のための「digest(ダイジェスト)」をフォーマットするのを説明するために部分「alternative(ほかにとりうる方法)」の総称の混合セットを指定している基本の、「mixed(混ぜられます)」サブタイプを含めて、最初定義されます。
-
message -- an encapsulated message. A body of media type "message" is itself all or a portion of some kind of message object. Such objects may or may not in turn contain other entities. The "rfc822" subtype is used when the encapsulated content is itself an RFC 822 message. The "partial" subtype is defined for partial RFC 822 messages, to permit the fragmented transmission of bodies that are thought to be too large to be passed through transport facilities in one piece. Another subtype, "external-body", is defined for specifying large bodies by reference to an external data source.
カプセル化したメッセージ。メディアタイプ「メッセージ」のボディは自身すべてまたはある種類のメッセージオブジェクトの一部です。そのようなオブジェクトは次々他の実体を含むはずがないか、かもしれません。カプセル化した内容が自身RFC 822メッセージである時に、「rfc822」サブタイプは使われます。「部分的な」サブタイプは、部分的なRFC 822メッセージが、1つの断片の中のトランスポート機関を通過するには大型すぎると考えられるボディの粉々にされたトランスミッションを許すように定義されます。別のサブタイプ、「external-body」は、外部のデータ送信装置へのリファレンスによって大型のボディを指定するために定義されます。
It should be noted that the list of media type values given here may be augmented in time, via the mechanisms described above, and that the set of subtypes is expected to grow substantially.
ここに与えられたメディアタイプ値のリストが上で説明されたメカニズム経由で時間内に増大するかもしれず、サブタイプのセットが、大幅に成長することを期待されていることは注目されるべきです。
4. Discrete Media Type Values
離散メディアタイプの値
Five of the seven initial media type values refer to discrete bodies. The content of these types must be handled by non-MIME mechanisms; they are opaque to MIME processors.
7つの初期のメディアタイプ値のうちの5つは離散的なボディを参照します。これらのタイプの内容は非MIMEメカニズムによって処理されなければなりません。それらはMIMEプロセッサに不透明です。
4.1. Text Media Type
Text メディアタイプ
The "text" media type is intended for sending material which is principally textual in form. A "charset" parameter may be used to indicate the character set of the body text for "text" subtypes, notably including the subtype "text/plain", which is a generic subtype for plain text. Plain text does not provide for or allow formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup. Plain text is seen simply as a linear sequence of characters, possibly interrupted by line breaks or page breaks. Plain text may allow the stacking of several characters in the same position in the text.
Plain text in scripts like Arabic and Hebrew may also include facilitites that allow the arbitrary mixing of text segments with opposite writing directions.
「テキスト」メディアタイプは、主として形式において原文通りの素材を送ることのために意図されています。「charset」パラメータは、特にサブタイプ「テキスト/平原」を含めて、「テキスト」サブタイプのために本文の文字セットを示すために使われるかもしれません(それは普通テキストのための総称のサブタイプです)。普通テキストは備えなく、書式作成コマンド、文字修飾仕様、処理指示、翻訳指示語、または内容マークアップを許しません。普通テキストは単にことによると改行またはページの区切りによって中断されているキャラクタの線形のシーケンスと考えられます。普通テキストはテキストの中で同じポジションの中の何人かの登場人物のスタッキングを許すかもしれません。
アラビア語とヘブライ語のようなスクリプトの中の普通テキストは、また、逆の書き込み方向によってテキストセグメントの任意の混合を許すfacilititesを含むかもしれません。
Beyond plain text, there are many formats for representing what might be known as "rich text". An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, it is reasonable to show subtypes of "text" to the user, while it is not reasonable to do so with most nontextual data. Such formatted textual data should be represented using subtypes of "text".
普通テキストを越えて、「豊かなテキスト(rich text)」として知られているかもしれないものを表すための多くのフォーマットがあります。多くのそのような表現の興味深い特徴は、それらが、それらを解釈するソフトウェアなしでさえある程度読取り可能であることです。そして、読取り不能の形式において説明されたイメージ、オーディオ、またはテキストのような読取り不能のデータから最も高いレベルでそれらを区別することは有益です。 適切な翻訳ソフトウェアの不在において、ほとんどの非原文のデータによってそうすることが妥当でない間、ユーザに「テキスト」のサブタイプを示すことは妥当です。 そのようなフォーマットされた原文のデータは、「テキスト」のサブタイプを使って、表されているべきです。
4.1.1. Representation of Line Breaks
改行の表現
The canonical form of any MIME "text" subtype MUST always represent a line break as a CRLF sequence. Similarly, any occurrence of CRLF in MIME "text" MUST represent a line break. Use of CR and LF outside of line break sequences is also forbidden.
どのようなMIME「テキスト」サブタイプの基準形式でもCRLFシーケンスとしていつも改行を見せなければなりません。同様に、MIME「テキスト」中のCRLFのどのような発生でも改行を表さなければなりません。改行シーケンスの外のCRとLFの使用はまた禁じられます。
This rule applies regardless of format or character set or sets involved.
関係しているフォーマットまたは文字セットまたはセットを問わずこの規則はあてはまります。
NOTE: The proper interpretation of line breaks when a body is displayed depends on the media type. In particular, while it is appropriate to treat a line break as a transition to a new line when displaying a "text/plain" body, this treatment is actually incorrect for other subtypes of "text" like "text/enriched" [RFC-1896]. Similarly, whether or not line breaks should be added during display operations is also a function of the media type. It should not be necessary to add any line breaks to display "text/plain" correctly, whereas proper display of "text/enriched" requires the appropriate addition of line breaks.
注意事項: ボディが表示される時の改行の適切な翻訳はメディアタイプに依存します。 「text/plain」ボディを表示する時に、改行を変化とみなすことが復帰改行に適切な特に間、この取り扱いは、実際、「text/enriched」[RFC-1896]のような「テキスト」の他のサブタイプのために不正確です。同様に、改行が表示命令の間に追加されるべきであるかどうかはまたメディアタイプの機能です。 「text/plain」を正しく表示するためにどのような改行でも追加することは必要であるべきでないのに対して、「text/enriched」の適切なディスプレイは改行の適切な加算を必要としています。
NOTE: Some protocols defines a maximum line length. E.g. SMTP [RFC-821] allows a maximum of 998 octets before the next CRLF sequence. To be transported by such protocols, data which includes too long segments without CRLF sequences must be encoded with a suitable content-transfer-encoding.
注意事項: いくつかのプロトコルは最大の行長を定義します。例えば [RFC-821]が次のCRLFシーケンスの前で最大998の8ビットバイトに与えるSMTP。そのようなプロトコルによって輸送されるために、CRLFシーケンスなしであまりにも長いセグメントを含むデータは適当なコンテンツ転送エンコーディングによって符号化されなければなりません。
4.1.2. Charset Parameter
Charset パラメータ
A critical parameter that may be specified in the Content-Type field for "text/plain" data is the character set. This is specified with a "charset" parameter, as in:
「text/plain」データのためにContent-Typeフィールドで指定されるかもしれない臨界パラメータは文字セットです。中のように、これは「charset」パラメータによって指定されます：
Content-type: text/plain; charset=iso-8859-1
Unlike some other parameter values, the values of the charset parameter are NOT case sensitive. The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII.
他のパラメータ値と違って、charsetパラメータの値は大文字小文字を区別しません。charsetパラメータの不在において仮定されなければならないデフォルト文字セットはUS-ASCIIです。
The specification for any future subtypes of "text" must specify whether or not they will also utilize a "charset" parameter, and may possibly restrict its values as well. For other subtypes of "text" than "text/plain", the semantics of the "charset" parameter should be defined to be identical to those specified here for "text/plain", i.e., the body consists entirely of characters in the given charset. In particular, definers of future "text" subtypes should pay close attention to the implications of multioctet character sets for their subtype definitions.
「テキスト」のどのような未来のサブタイプのための仕様でも、それらがまた「charset」パラメータを利用するであろうし、その上何とかしてその値を限定することができるかどうかを指定しなければなりません。「text/plain」以外の「テキスト」の他のサブタイプのために、「charset」パラメータの意味論は、「text/plain」のためにここで指定されたそれらに同一のために定義されるべきであり、すなわち、ボディはすべて与えられたcharsetにおけるキャラクタから成ります。特に、未来の「テキスト」サブタイプの説明者は彼らのサブタイプ定義のためにマルチ8ビットバイトキャラクタセットの含意に細心の注意を払うべきです。
The charset parameter for subtypes of "text" gives a name of a character set, as "character set" is defined in RFC 2045. The rules regarding line breaks detailed in the previous section must also be observed -- a character set whose definition does not conform to these rules cannot be used in a MIME "text" subtype.
「文字セット」がRFC 2045の中で定義される時に、「テキスト」のサブタイプのためのcharsetパラメータは文字セットの名前を与えます。前のセクションの中で詳細であった改行についての規則はまた遵守されなければなりません--定義がこれらの規則に対応しない文字セットはMIME「テキスト」サブタイプの中で使われることができません。
An initial list of predefined character set names can be found at the end of this section. Additional character sets may be registered with IANA.
あらかじめ決められた文字セット名の初期のリストはこのセクションの終わりに見つかることができます。追加文字セットはIANAに登録されるかもしれません。
Other media types than subtypes of "text" might choose to employ the charset parameter as defined here, but with the CRLF/line break restriction removed. Therefore, all character sets that conform to the general definition of "character set" in RFC 2045 can be registered for MIME use.
「テキスト」のサブタイプ以外の他のメディアタイプは、ここでけれどもCRLF/改行制限を削除する定義されることとしてcharsetパラメータを利用することに決めるかもしれません。従って、RFC 2045の中の「文字セット」の一般の定義に対応するすべての文字セットはMIME使用に登録されることができます。
Note that if the specified character set includes 8-bit characters and such characters are used in the body, a Content-Transfer-Encoding header field and a corresponding encoding on the data are required in order to transmit the body via some mail transfer protocols, such as SMTP [RFC-821].
言及してください that 指定された文字セットが8ビットキャラクタを含み、ボディにおいてそのようなキャラクタが使われて、SMTP[RFC-821]などのいくつかの郵便振替プロトコルを経たボディを転送するために、コンテンツ転送符号化ヘッダーフィールドおよびデータでの一致符号化が必要です。
The default character set, US-ASCII, has been the subject of some confusion and ambiguity in the past. Not only were there some ambiguities in the definition, there have been wide variations in practice. In order to eliminate such ambiguity and variations in the future, it is strongly recommended that new user agents explicitly specify a character set as a media type parameter in the Content-Type header field. "US-ASCII" does not indicate an arbitrary 7-bit character set, but specifies that all octets in the body must be interpreted as characters according to the US-ASCII character set. National and application-oriented versions of ISO 646 [ISO-646] are usually NOT identical to US-ASCII, and in that case their use in Internet mail is explicitly discouraged. The omission of the ISO 646 character set from this document is deliberate in this regard. The character set name of "US-ASCII" explicitly refers to the character set defined in ANSI X3.4-1986 [US- ASCII]. The new international reference version (IRV) of the 1991 edition of ISO 646 is identical to US-ASCII. The character set name "ASCII" is reserved and must not be used for any purpose.
デフォルト文字セット、US-ASCIIは過去にいくらかの混乱とあいまい性の主体でした。定義の中にいくつかのあいまい性があったかがなければ、幅広い変化が実際の場でありませんでした。そのようなあいまい性と未来の変化を取り除くために、新しいユーザエージェントが、メディアとしての文字セットがContent-Typeヘッダーフィールドでパラメータをタイプすると明示的に指定することは強く勧められます。 「US-ASCII」は任意の7ビットの文字セットを示さないけれども、ボディの中のすべての8ビットバイトがUS-ASCII文字セットに従ってキャラクタとして解釈されなければならないと指定します。[ISO-646]が通常、US-ASCIIとその場合の、インターネットメールの中のそれらの使用に同一のNOTが、明示的に落胆したことであることであるISO646の全国的で、アプリケーション指向のバージョン。この文書からのISO646文字セットの省略はこの点に慎重です。「US-ASCII」の文字セット名は明示的に[US- ASCII]をANSI X3.4-1986の中で定義された文字セットに差し向けます。ISO646の1991年の版の新しい国際的なリファレンスバージョン(IRV)はUS-ASCIIに同一です。文字セット名「ASCII」は確保されて、どのような目的のためにも使われてはなりません。
NOTE: RFC 821 explicitly specifies "ASCII", and references an earlier version of the American Standard. Insofar as one of the purposes of specifying a media type and character set is to permit the receiver to unambiguously determine how the sender intended the coded message to be interpreted, assuming anything other than "strict ASCII" as the default would risk unintentional and incompatible changes to the semantics of messages now being transmitted. This also implies that messages containing characters coded according to other versions of ISO 646 than US-ASCII and the 1991 IRV, or using code-switching procedures (e.g., those of ISO 2022), as well as 8bit or multiple octet character encodings MUST use an appropriate character set specification to be consistent with MIME.
注意事項: RFC 821は明示的に「ASCII」を指定し、アメリカンスタンダードの先のバージョンを参照します。レシーバが、どのように送信側が、デフォルトが現在転送されているメッセージの意味論への故意でなく、互換性がない変化を危険にさらすであろう時に「厳密なASCII」以外の何かを仮定して、解釈されるコード化されたメッセージを意図していたかを明らかに決定することを許すことは、メディアタイプと文字セットを指定する目的の1つ限りです。これはまた、8ビットと同様に、US-ASCIIと1991年のIRV以外のISO646の他のバージョンまたはコード切り換え手続(例えばISO2022のそれら)を使うことに従って、キャラクタを含んでいるメッセージがコード化したか、複数の8ビットバイトキャラクタエンコーディングが、MIMEと一致しているために適切な文字セット仕様を使わなければならないことを暗示しています。
The complete US-ASCII character set is listed in ANSI X3.4- 1986. Note that the control characters including DEL (0-31, 127) have no defined meaning in apart from the combination CRLF (US-ASCII values 13 and 10) indicating a new line. Two of the characters have de facto meanings in wide use: FF (12) often means "start subsequent text on the beginning of a new page"; and TAB or HT (9) often (though not always) means "move the cursor to the next available column after the current position where the column number is a multiple of 8 (counting the first column as column 0)." Aside from these conventions, any use of the control characters or DEL in a body must either occur
完全US-ASCII文字セットはANSI X3.4- 1986の中でリストにされます。復帰改行を示しているコンビネーションCRLF(US-ASCII値13と10)は別としてDEL(0-31、 127)を含む制御文字が定義された意味を全然ためていないことに注意してください。キャラクタの2つは広い使用において事実上の意味を持っています： FF(12)はしばしば「新しいページの最初の開始のその後のテキスト」を意味しています； そして、「けた位置が、8(カラム0として最初のカラムをカウントします)の倍数である現在位置の後で、」TABまたはHT(9)、しばしば(いつもではないけれども)方法は「次の使用可能なカラムにカーソルを移動します」。これらの規定は別として、制御文字のどのような使用またはボディの中のDELでも起こらなければなりません。
-
because a subtype of text other than "plain" specifically assigns some additional meaning, or
「plain」を除いたテキストのサブタイプがある追加の意味を特に割り当てる または
-
within the context of a private agreement between the sender and recipient. Such private agreements are discouraged and should be replaced by the other capabilities of this document.
送信側と受領者の間の私用の協定のコンテキストの中。 そのような私用の協定はやめさせられて、この文書の他の能力によって置換されるべきです。
NOTE: An enormous proliferation of character sets exist beyond US-ASCII. A large number of partially or totally overlapping character sets is NOT a good thing. A SINGLE character set that can be used universally for representing all of the world's languages in Internet mail would be preferrable. Unfortunately, existing practice in several communities seems to point to the continued use of multiple character sets in the near future. A small number of standard character sets are, therefore, defined for Internet use in this document.
注意事項: キャラクタセットの巨大な増殖はUS-ASCIIを越えて存在しています。キャラクタセットと部分的であるか、すっかりオーバーラップする多くはよい物ではありません。インターネットメールの中で世界の言語のすべてを表すために一般的に使われることができるSINGLE文字セットはpreferrableでしょう。あいにく、いくつかのコミュニティの既存の実行は、近い将来複数のキャラクタセットの続いた使用を示すようです。少数の標準文字セットは従ってこの文書の中のインターネット使用のために定義されます。
The defined charset values are:
定義されたcharset値は以下の通りです：
-
US-ASCII -- as defined in ANSI X3.4-1986 [US-ASCII].
US-ASCII は ANSI X3.4-1986の中[US-ASCII]で定義されている。
-
ISO-8859-X -- where "X" is to be replaced, as necessary, for the parts of ISO-8859 [ISO-8859]. Note that the ISO 646 character sets have deliberately been omitted in favor of their 8859 replacements, which are the designated character sets for Internet mail. As of the publication of this document, the legitimate values for "X" are the digits 1 through 10.
ISO-8859-X は「X」がISO-8859[ISO-8859]の部分のために必要なので、置換されることになっている所。ISO646キャラクタセットが意図的にそれらの8859の置換のために忘れられていることに注意してください(それはインターネットメールのための明示されたキャラクタセットです)。この文書の出版現在、「X」のための合法な値は1から10までその数字です。
Characters in the range 128-159 has no assigned meaning in ISO-8859-X. Characters with values below 128 in ISO-8859-X have the same assigned meaning as they do in US-ASCII.
範囲128-159のキャラクタはISO-8859-Xにおいて割り当てられた意味を全然持っていません。ISO-8859-Xにおける128下の値を持つキャラクタは、それらがUS-ASCIIにおいてするのと同じ割り当てられた意味を持っています。
Part 6 of ISO 8859 (Latin/Arabic alphabet) and part 8 (Latin/Hebrew alphabet) includes both characters for which the normal writing direction is right to left and characters for which it is left to right, but do not define a canonical ordering method for representing bi-directional text. The charset values "ISO-8859-6" and "ISO-8859-8", however, specify that the visual method is used [RFC-1556].
ISO8859(ラテン語/アラビア語アルファベット)とパート8(ラテン語/ヘブライ語のアルファベット)のパート6は、正常な書き込み方向がまさに左にであるキャラクタとそれが右に任せられるキャラクタの両方を含むけれども、両方向のテキストを表すための正規の配列方法を定義しないでください。しかし、「ISO-8859-6」および「ISO-8859-8」というcharset値は、視覚の方法が、使われた[RFC-1556]であると指定します。
All of these character sets are used as pure 7bit or 8bit sets without any shift or escape functions. The meaning of shift and escape sequences in these character sets is not defined.
これらのキャラクタセットのすべてはどのようなシフトもなしで純粋の7ビットまたは8ビットのセットとして使われるか、機能を免れます。これらのキャラクタセットの中のシフトとエスケープシーケンスの意味は定義されません。
The character sets specified above are the ones that were relatively uncontroversial during the drafting of MIME. This document does not endorse the use of any particular character set other than US-ASCII, and recognizes that the future evolution of world character sets remains unclear.
上で指定された文字セットは、MIMEの立案の間相対的に議論にならなかったものです。この文書はUS-ASCII以外のどのような特定の文字セットの使用も承認しなく、世界キャラクタセットの未来の発展が不明瞭であり続けると認めています。
Note that the character set used, if anything other than US- ASCII, must always be explicitly specified in the Content-Type field.
US- ASCII以外の何かならば使われた文字セットがいつもContent-Typeフィールドで明示的に指定されなければならないことに注意してください。
No character set name other than those defined above may be used in Internet mail without the publication of a formal specification and its registration with IANA, or by private agreement, in which case the character set name must begin with "X-".
上で定義されたそれら以外のどの文字セット名もIANAとや私用の協定によって形式仕様とその登録の出版なしでインターネットメールの中で使われないかもしれません(そのケースの中で、文字セット名は「X-」から始まらなければなりません)。
Implementors are discouraged from defining new character sets unless absolutely necessary.
絶対に必要でない限り、作成者は、新しいキャラクタセットを定義することを思いとどまるべきです。
The "charset" parameter has been defined primarily for the purpose of textual data, and is described in this section for that reason. However, it is conceivable that non-textual data might also wish to specify a charset value for some purpose, in which case the same syntax and values should be used.
「charset」パラメータは原文のデータのために第一に定義されていて、その理由のためにこのセクションの中で説明されます。しかし、非原文のデータが、また、いくらかの目的のためにcharset値を指定することを望むかもしれないことは考えられます(そのケースの中で、同じシンタックスと値は使われるべきです)。
In general, composition software should always use the "lowest common denominator" character set possible. For example, if a body contains only US-ASCII characters, it SHOULD be marked as being in the US-ASCII character set, not ISO-8859-1, which, like all the ISO-8859 family of character sets, is a superset of US-ASCII. More generally, if a widely-used character set is a subset of another character set, and a body contains only characters in the widely-used subset, it should be labelled as being in that subset. This will increase the chances that the recipient will be able to view the resulting entity correctly.
一般に、合成ソフトウェアはいつも可能な「最小公分母」文字セットを使うべきです。例えば、ボディがUS-ASCII文字だけを含んでいるならば、それはISO-8859-1ではなくUS-ASCII文字セットの中にあることとしてマークされるべきです(それは、キャラクタセットのすべてのISO-8859ファミリーのように、US-ASCIIの上位集合です)。より一般に、広く使われた文字セットが別の文字セットのサブセットであり、ボディが広く使われたサブセットの中にキャラクタだけを含んでいるならば、それはそのサブセットの中にあることとしてラベルを付けて分類されるべきです。これは、受領者が、結果として生じている実体を正しく見ることができるであろうという可能性を増大させるでしょう。