この規格ページの目次
4
X 5810-2 : 2008
算,メールを利用したスケジュール管理システムのデータ,“能動的”(計算的)メッセージングのた
めの言語,直接は読むことのできないワードプロセッサのフォーマットを含む。幾つかの型のアプリ
ケーションデータ,特に“application/PostScript”及びどんな形式であれ,能動的メッセージには,セキ
ュリティに関する考慮が存在するかもしれないので注意する。これらの論点に関してはこの規格の後
のほうで論じる。
二つの複合の最上位メディア型は次のとおりとする。
f) multipart 複数の独立なデータ型の実体からなるデータは,次の四つのメディア下位型が初期に定義
される。基本的な“mixed”メディア下位型は,はん(汎)用の混合の部分の組を指定する。“alternative”
は,同じデータを複数のフォーマットで表現する。“parallel”は,部分を同時に見ることを想定する。
“digest”は,それぞれの部分が“message/rfc822”というデフォルトの型をもつマルチパート実体である。
g) essage カプセル化されたメッセージ(“message”メディア型の本体)は,それ自体で,ある種類の
メッセージオブジェクトの全部又は一部とする。このようなオブジェクトは,更に,他の実体を含ん
でもよいし,含まなくてもよい。カプセル化されたメッセージ自体がRFC 822メッセージである場合,
“rfc822”メディア下位型が使われる。転送機能へ一つのメッセージとして渡すには大きすぎると考えら
れる場合,本体を細分化した転送を許容するため,部分的なRFC 822メッセージとして,“partial”メ
ディア下位型を定義する。もう一つの“external-body”メディア下位型は,外部のデータ源への参照によ
って,大きい本体を指定するために,定義する。
ここで与えられたメディア型の一覧は,上記の機構によって,時間の経過とともに拡張され,メディア
下位型の組は大いに増えていくことが予期されることを心に留めておいたほうがよい。
4 個別メディア型値
七つの初期のメディア型値のうちの五つは,個別の本体を参照する。これらの型の内容は,MIME処理
系では処理せず,非MIME機構で処理されなければならない。
4.1 textメディア型
“text”メディア型は,通常形式的にテキストのデータを送ることを想定する。特にプレーンテキストのた
めのはん(汎)用メディア下位型である“text/plain”メディア下位型を含め,“text”メディア型のメディア下
位型の本体テキストの文字集合を指示するために,“charset”パラメタを使ってよい。プレーンテキストは,
フォーマット命令,フォント属性指定,処理命令,解釈指示又は内容マーク付けを提供も許容もしない。
プレーンテキストは,行区切り又はページ区切りに割り込まれることはあるが,単純に並んでいる文字の
列に見える。プレーンテキストは,幾つかの文字をテキスト中の同じ位置に積み重ねることを,許してよ
い。アラビア語及びヘブライ語のようなスクリプト中でのプレーンテキストでは,逆筆記方向のテキスト
の区間の任意な混合を許す機能を含めてよい。
プレーンテキスト以上の,“リッチテキスト”として知られているようなものを表現するために,多くの
フォーマットがある。多くのそのような表現の興味深い特徴は,それらを解釈するソフトウェアがないと
きでさえ,ある程度は読めるということである。そして,画像,音声又は読めない形式で表現されたテキ
ストのような読めないデータと,リッチテキストなどのある程度は読めるデータとを,最上位で区分する
ことは有用である。
4.1.1 行区切りの表現
すべてのMIMEの“text”メディア下位型の正準形式は,いつでも行区切りをCRLF列として表さなけれ
――――― [JIS X 5810-2 pdf 6] ―――――
5
X 5810-2 : 2008
ばならない。同様に,MIMEの“text”メディア型中のCRLFの発生は,行区切りを表さなければならない。
CR及びLFを行区切り列以外に使うことも禁止される。
この規則は,フォーマット又は関係する文字集合にかかわらず適用する。
注記1 本体が表示されるときの,行区切りの正しい解釈は,メディア型に依存する。特に,“text/plain”
本体を表示するとき,行区切りを新しい行への移動として扱うことは適切だが,
“text/enriched”(RFC 1896を参照)のような“text”メディア型の他のメディア下位型に対して
は,この扱いは,実際に誤りである。同様に,表示操作中,行区切りを加えるのがよいかど
うかも,メディア型によって決まる。“text/plain”を正しく表示するときに行区切りを追加す
る必要はないが,“text/enriched”の正しい表示には適切な行区切りの追加が必要である。
注記2 幾つかのプロトコルは最大行長を定義する。例えば,SMTP [RFC 821]では,行末のCRLF列
を除く最大行長を998オクテットと定義している。このようなプロトコルによって転送され
るためには,CRLF列なしに長すぎる区間を含むデータは,適切なContent-Transfer-Encoding
で符号化されなければならない。
4.1.2 charsetパラメタ
“text/plain”データのためにContent-Typeフィールド中に指定されてよい重要なパラメタは,文字集合で
ある。これは“charset”パラメタで,次のように指定される。
Content-type: text/plain; charset=iso-8859-1
その他幾つかのパラメタ値とは違って,charsetパラメタの値は,大文字・小文字を区別しない。charset
パラメタがないときに仮定されなければならない,デフォルトの文字集合は,US-ASCIIとする。
“text”メディア型の将来のどんなメディア下位型の仕様も,“charset”パラメタも利用するかどうかを規定
しなければならず,更に,場合によってはその値を制限してもよい。“text/plain”以外の“text”メディア型の
メディア下位型では,“charset”パラメタのセマンティクスは,“text/plain”のためにここで指定されたものと
同一となるように定義したほうがよい。すなわち,本体は,すべて,与えられた文字集合内の文字からな
る。特に,将来の“text”メディア型のメディア下位型を定義する者は,メディア下位型の定義における複数
オクテット文字集合のかかわり合いについて,よく注意したほうがよい。
“text”メディア型のメディア下位型の文字集合パラメタは,JIS X 5810-1で定義される“文字集合”のと
おりに,文字集合の名前を与える。4.1.1で詳しく規定している行区切りに関する規則も,遵守しなければ
ならない。これらの規則に適合しない定義をもつ文字集合は,MIMEの“text”メディア型のメディア下位型
で使うことはできない。
あらかじめ定義された文字集合名の初期の一覧は,この箇条の最後にある。追加の文字集合はIANAに
よって登録してよい。
“text”メディア型のメディア下位型ではない,他のメディア型は,CRLF又は行区切りの制限を排除して,
ここで定義されたcharsetパラメタを使うことを選んでもよい。したがって,JIS X 5810-1の“文字集合”
の一般的な定義に適合する,すべての文字集合は,MIMEでの使用のために登録できる。
もし,指定された文字集合が8 bit文字を含み,このような文字が本体に使われたら,Content-Transfer-
Encodingヘッダフィールド及び対応するデータの符号化が,必要となることに注意する。これは,SMTP
[RFC 821]のような幾つかのメール転送プロトコルを通して本体を転送するためである。
デフォルトの文字集合US-ASCIIは,過去には幾つかの混乱とあいまい性とがあった。定義における幾
つかのあいまい性だけでなく,実践において広い多様性があった。このようなあいまい性及び多様性を将
来なくすため,新しい利用者エージェントは,“Content-Type”ヘッダフィールドのメディア型のパラメタと
――――― [JIS X 5810-2 pdf 7] ―――――
6
X 5810-2 : 2008
して,明示的に文字集合を指定することを強く推奨する。“US-ASCII”は,任意の7 bit文字集合を指すので
なく,本体中のすべてのオクテットは,US-ASCII文字集合に従った文字として解釈されなければならない。
ISO/IEC 646 [ISO/IEC 646]の,国内版及びアプリケーション指向版は,通常は,US-ASCIIと同一ではなく,
インターネットメールにおけるそれらの使用は,やめたほうがよいことは明らかである。この規格から
ISO/IEC 646文字集合を省くことは,慎重に考えられたことである。文字集合名“US-ASCII”は,ANSI
X3.4-1986 [US-ASCII]で定義される文字集合を,明示的に参照する。ISO/IEC 646の1991年版である新し
い国際参照版( IRV )は,US-ASCIIと同一である。文字集合名“ASCII”は予約済みであり,どんな目的にも
使ってはならない。
注記1 RFC 821は,明示的に“ASCII”を指定していて,米国規格の初期の版を参照している。メディ
ア型及び文字集合を指定する目的の一つが,送信者が解釈される符号化されたメッセージを
どのように意図したかを,受信者があいまい性なく決定することを許すことである限りは,
デフォルトとしての“厳密なASCII”以外のどんなものも仮定することは,今送信されてい
るメッセージのセマンティクスへの意図しない及び互換性のない変更の危険を起こすであろ
う。US-ASCII及び1991 IRV以外のISO/IEC 646の他の版に従って符号化された文字を含む
メッセージ,又は,例えばJIS X 0202の符号切換え手続は,8 bit又は複数オクテット文字符
号化と同様,MIMEと矛盾しない適切な文字集合指定を使わなければならないことも,示唆
する。
完全なUS-ASCII文字集合は,ANSI X3.4-1986に列挙されている。改行を識別する組合せCRLF(US-ASCII
値の13及び10)以外は,DELを含む制御文字( 0-31, 127 )に,定義された意味は何もないことに注意する。
次の二つの文字は,広く使われている事実上の意味がある。FF(12)は“続きのテキストは新しいページの
先頭から始める”ことをしばしば意味する。TAB又はHT(9)は,いつもではないけれども,“初めのカラム
をカラム0と数えて,現在のカラムより後の次の可能な8の倍数のカラム番号へカーソルを動かす”こと
を意味する。これらの規約とは別に,本体中での制御文字又はDELの使用は,次のどちらかで生じる。
a) “plain”以外のメディア下位型が,幾つかの追加の意味を具体的に割り当てる場合。
又は
b) 送信者と受信者との間の私的な合意の状況の場合。このような私的な合意は,やめたほうがよく,こ
の規格で規定する他の機能に置き換えたほうがよい。
注記2 US-ASCII以外にも多くの異なった文字集合が存在する。部分的又は全体的に重なる文字集合
がたくさんあることはよいことではない。インターネットメールで,世界中の言語のすべて
を表現できて万国共通に使える,単一の文字集合が好ましい。しかし,多くのコミュニティ
での実在の実践は,近い将来の間は複数の文字集合を使い続けることになるだろう。したが
って,この規格では少数の標準的な文字集合を定義する。
定義するcharset値を次に示す。
c) S-ASCII ANSI X3.4-1986 [US-ASCII]で定義される文字集合。
d) SO-8859-X “X”の部分は,ISO/IEC 8859規格群の各部の番号で置換することが必要である。ISO/IEC
646文字集合群を,意図的に,定義するcharset値から省いていることを注記しておく。これはインタ
ーネットメールでの指定は,ISO/IEC 646文字集合群ではなく,それらのISO/IEC 8859規格群の置換
のほうだからである。この規格の原規定のRFC 2046が公表された時点では,“X”の値として数字の1
から10が合法である。
128-159の範囲の文字は,ISO-8859-Xでは,指定された意味をもたない。ISO-8859-Xの128より小さい
――――― [JIS X 5810-2 pdf 8] ―――――
7
X 5810-2 : 2008
値の文字は,US-ASCIIと同じ指定された意味をもつ。
ISO/IEC 8859規格群の第6部(ラテンアルファベット及びアラビアアルファベット)及び第8部(ラテ
ンアルファベット及びヘブライアルファベット)は,左から右への普通の筆記方向の文字及び右から左へ
の反対の筆記方向の文字を両方含むが,双方向テキストを表現するための正準的な順序付け方法は定義し
ていない。しかし,“ISO-8859-6”及び“ISO-8859-8”のcharset値は,視覚的な方法が使われることを指定す
る [RFC 1556]。
これらすべての文字集合は,シフト機能又はエスケープ機能なしの,純粋な7 bit又は8 bit集合として
使う。これら文字集合のシフト及びエスケープシーケンスの意味は定義しない。
上記で規定された文字集合は,MIMEの原案作成中比較的議論を呼ばないものであった。この規格は,
US-ASCII以外の特定のどんな文字集合の使用も支持せず,国際的な文字集合の将来の進化が不明確なまま
であることを認識する。
US-ASCII以外の文字集合を使用する場合は必ずContent-Typeフィールドに明示的に指定されなければ
ならないことに注意する。
上記で定義されていないどんな文字集合名も,公式の仕様の出版及びIANAでの登録,又は,私的な合
意によるものでなければならない。私的な合意によって使う場合は,“X-”で始まらなければならない。
注記3 日本語環境におけるMIMEの使用
この規格では,初期charset値としてUS-ASCII及びISO-8859-X [“X”の部分はISO/IEC 8859
規格群の各部の番号]だけを定義している。それ以外の文字集合については,RFC 2278で規定
される登録手続を経たものは,IANA (Internet Assigned Numbers Authority)の登録簿に登録されて
いる。この登録簿は,次のアドレスから入手できる。
http://www.iana.org/assignments/character-sets
日本語を含むcharset値の主なものとして,次のような文字集合が登録されている。
a) hiftJIS[現在多くのパソコン上で日本語を表すために使われている文字コード(符号化方
式)である。]
b) UC-JP(UNIX上で日本語の文字を扱う場合に最も多く利用されている符号化方式の一つで
ある。)
c) so-2022-jp[インターネット上(特に電子メール)などで使われる日本の文字用の符号化方
式。JIS X 0202のエスケープシーケンスを利用して文字集合を切り替える7ビットのコード
であることを特徴とする。]
d) TF-8(Unicode又はISO/IEC 10646の符号化文字集合を符号化する方式の一つ。ASCIIの文
字は1オクテット,その他の文字は26オクテットで符号化する。ASCIIとの互換性は高い。
漢字は3オクテット以上で符号化される。)
実装者は,絶対的に必要な場合を除き,新しい文字集合を定義しないほうがよい。
“charset”パラメタは,主としてテキストデータのために定義されていて,そのために,この箇条に記述
されている。しかし,何らかの目的で,同じ構文及び値が使われるほうがよいときには,非テキストデー
タでもcharset値を指定したい場合が考えられる。
一般的にいって,文書作成ソフトウェアは,可能な限りいつも“一番小さい共通の”文字集合を使用す
るのがよい。例えば,本体がUS-ASCII文字だけを含む場合,すべてのISO/IEC 8859規格群と同様に
US-ASCIIのスーパセットであるISO-8859-1とするのではなく,US-ASCII文字集合として,マーク付けす
るのがよい。もっと一般的にいえば,広く使われている文字集合がもう一つの広く使われている文字集合
――――― [JIS X 5810-2 pdf 9] ―――――
8
X 5810-2 : 2008
のサブセットであった場合,本体が広く使われているサブセットの文字だけを含むならば,それはサブセ
ットが使われているとラベル付けするのがよい。これは,受信者が結果の実体を正しく見ることができる
機会を,増やすことになる。
4.1.3 plainメディア下位型
最も単純で最も重要な“text”メディア型のメディア下位型は“plain”である。これは,フォーマット命令又
はフォーマット指示を含まない,プレーンテキストを示す。プレーンテキストは,“そのまま”表示される
ことが意図される。すなわち,適正な表示のために,組み込まれたフォーマット命令,フォント属性指定,
処理命令,解釈指示又は内容マーク付けの解釈を必要としないほうがよい。インターネットメールのため
のデフォルトのメディア型“text/plain; charset=us-ascii”は,既存のインターネット実践を記述する。すなわ
ち,これはRFC 822で定義される本体の型である。
他の“text”メディア型のメディア下位型は,この規格では,定義されない。
4.1.4 認識されないメディア下位型
“text”メディア型の認識されないメディア下位型は,MIME実装がcharsetをどう処理するかを知ってい
る限りは,“plain”メディア下位型として扱うのがよい。認識できないメディア下位型であって,指定して
いるcharsetも認識できないものは,“application/octet-stream”として扱うのがよい。
4.2 imageメディア型
“image”メディア型は,本体が画像を含むことを指示する。メディア下位型は,特定の画像フォーマット
を,名前付けする。これらの名前は,大文字・小文字を区別しない。初期のメディア下位型は,JFIF符号
化[JPEG]を使ったJPEGフォーマットのための,“jpeg”とする。
“image”のメディア下位型の一覧は,排他的でもすべてでもなく,ここで与えられ,これ以上の型は,RFC
2048に記述されているとおりに,IANAで登録されて,増えていくことが期待される。
“image”の認識されないメディア下位型は,少なくとも“application/octet-stream”として扱うのがよい。実
装は,安全で頑健なはん(汎)用画像表示アプリケーションが利用可能ならば,オプションで“image”のメ
ディア下位型をアプリケーションに渡してもよい。
注記 このようにしてはん(汎)用画像表示アプリケーションは,アプリケーションでサポートする
最も危険なセキュリティ上の問題を受け継ぐ。
4.3 audioメディア型
“audio”メディア型は,本体が音声データを含むことを示す。計算機で使う理想的な音声のフォーマット
については,いまだに合意が得られていないが,相互運用可能な振る舞いを供給することのできるフォー
マットの強い必要性はある。
初期の“basic”メディア下位型は,絶対的に一番小さい共通の音声フォーマットを提供することによって,
この要求に答えるために規定された。より高品質及び/又はより狭帯域音声のためのより高度なフォーマ
ットは,今後の文書で定義されることが期待される。
“audio/basic”メディア下位型の内容は,標本化周波数8 000 Hzで,8 bitのISDNの μ則[PCM]によって
符号化された,単一チャネル音声とする。
“audio”の認識されないメディア下位型は,最低でも,“application/octet-stream”として扱うのがよい。実
装は,オプションで,明確には認識しない“audio”のメディア下位型を,頑健な一般用途音声再生アプリケ
ーションへ,そのようなアプリケーションが利用可能であれば,渡してよい。
4.4 videoメディア型
“video”メディア型は,本体が,時間につれて変動する画像を含むことを示す。用語“video”は,特定の技
――――― [JIS X 5810-2 pdf 10] ―――――
次のページ PDF 11
JIS X 5810-2:2008の国際規格 ICS 分類一覧
- 35 : 情報技術.事務機械 > 35.110 : 情報通信ネットワーキング
JIS X 5810-2:2008の関連規格と引用規格一覧
- 規格番号
- 規格名称
- JISX5810-1:2008
- 多目的インターネットメール拡張(MIME)―第1部:インターネットメッセージ本体のフォーマット
- JISX5810-3:2008
- 多目的インターネットメール拡張(MIME)―第3部:非ASCIIテキストへのメッセージヘッダ拡張
- JISX5810-5:2008
- 多目的インターネットメール拡張(MIME)―第5部:適合基準