tm 7.100 Manual（日本語版）
***************************

This file documents tm, a MIME package for GNU Emacs.

GNU Emacs で MIME を楽しむための package である `tm' について説明します。

tm って何？
***********

tm は GNU Emacs で MIME を楽しむための package です。tm を使うと、

   *  tm-view による MIME message の閲覧・再生
   *  tm-edit による MIME message の作成
   *  mh-e, GNUS, Gnus, RMAIL, VM での MIME 機能の強化

というようなことが行なえます。

個別の項目については以下を御参照下さい：

   * tm-MUA for Gnus (see (gnus-mime-ja))
   * tm-MUA for GNUS (see (tm-gnus-ja))
   * tm-MUA for mh-e (see (tm-mh-e-ja))
   * tm-MUA for VM (see (tm-vm-en))
   * mime/viewer-mode (see (tm-view-ja))
   * mime/editor-mode (see (tm-edit-ja))

用語
====

tm で使われている用語について解説します。

7bit
----

ここでは 0 から 127 の整数を指す。

0 から 127 の整数の列で表現できるような data を "7bit の data" と呼ぶ。

また、0 から 31 および 127 で表現される制御文字と 32 で表現される空白と
33 から 126 で表現される図形文字からなる文字列のことを "7bit の文字列"と呼
ぶ（これは ISO 2022 (see ISO 2022) の「7 単位系」と同様）。

伝統的な Internet の MTA (see MTA) は 7bit の data を転送できるので、
7bit の data は Quoted-Printable (see Quoted-Printable) や Base64
(see Base64) といった変換を行わなくてもそのまま転送できる。

しかし、7bit であればどんな data でも良いとはいえない。なぜなら、１行の長
さがあまりに長いと、MTA はその message を転送することができないからである。
ちなみに、RFC 821 (see RFC 821) は１行は改行文字を除いて 998 byte 以内
であることを求めている。よって、これ以上の行が含まれる可能性のある data,
例えば、Postscript の data などは Quoted-Printable 等でencodeする必用があ
る。

8bit
----

ここでは 0 から 255 の整数を指す。

0 から 255 の整数の列で表現できるような data を "8bit の data" と呼ぶ。

また、0 から 31, 127 および 128 から 159 で表現される制御文字と 32 で表現
される空白と 33 から 126 と 160 から 255 で表現される図形文字からなる文字
列のことを "8bit の文字列" と呼ぶ（これは ISO 2022 (see ISO 2022) の
「8 単位系」と同様）。

iso-8859-1 (see iso-8859-1) や euc-kr (see euc-kr) といった符号化
文字集合は 8bit の文字列である。

伝統的な Internet の MTA (see MTA) は 7bit (see 7bit) の data しか
転送できないので、そうした MTA を経由する場合、Quoted-Printable (see
Quoted-Printable) や Base64 (see Base64) といった変換を行わなくては
ならない。

しかし、最近では 8bit の文字列をそのまま通すことができる MTA も登場してき
たので、そのまま送ることができる場合も増えてきた。

しかし、8bit であればどんな data でも良いとはいえない。なぜなら、１行の長
さがあまりに長いと、MTA はその message を転送することができないからである。
ちなみに、RFC 821 (see RFC 821) は１行は改行文字を除いて 998 byte 以内
であることを求めている。よって、これ以上の行が含まれる可能性のある data,
例えば、Postscript の data などは Quoted-Printable 等でencodeする必用があ
る。

また、こうした理由から、１行が 999 byte 以上の行が存在する可能性のある
data は *binary* (see binary) と呼ぶことにする。

ちなみに、7bit で表現できる data は 8bit でも表現できる。よって、"8bit" と
言った場合、１行が 998 byte 以下の任意の data を指すことがある。

94 文字集合
-----------

33 から 126 の範囲の 1 byte からなる 図形文字集合(see Graphic character set)
。ASCII (see ASCII) や JIS X0201-Latin はその一種。

96 文字集合
-----------

32 から 127 の範囲の 1 byte からなる 図形文字集合(see Graphic character set)
。ISO 8859 シリーズはその一種。

94×94 文字集合
---------------

33 から 126 の範囲の 2 byte からなる 図形文字集合(see Graphic character set)
。JIS X0208 (see JIS X0208) や GB 2312 (see GB 2312)
はその一種。

ASCII
-----

アメリカ連邦で使われる文字を符号化した 94 文字集合(see 94-character set)
。A-Z, a-z の Latin 文字と数字、幾つかの記号からなる。ISO 646
(see ISO 646) の一つ。

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

Base64
------

RFC 2045 (see RFC 2045) で定義されている MIME (see MIME) における
binary data (see binary) の network での変換法の１つ。

『64 進数』という意味で、3 byte の data を 0 から 63 の数を表す ASCII
(see ASCII) 4 文字に変換する方法。（もし、4 文字にならなければ
*pad* と呼ばれる詰め物をして長さを調整する）

この 65 種類の文字は ASCII と EBCDIC の共通部分から選ばれており、
Internet 以外の network を経由する場合でも安全に転送できるように設計されて
いる。

binary
------

任意の byte 列を *binary* と呼ぶ。

8bit (see 8bit) と異なるのは data に行の構造を仮定しないことである。

また、行の構造があっても、999 byte 以上からなる行がある場合も binary と呼
ぶことにする。

ちなみに、7bit (see 7bit) や 8bit で表現できる data は binary でも表現
できる。よって、*binary data* と言った場合、任意の data を指すことがある。

cn-gb, gb2312
-------------

中国大陸でられている簡体字で表記される中国語を表現するための MIME
charset (see MIME charset) の１つ。

ISO 2022 (see ISO 2022) に基いて ASCII (see ASCII) に GB 2312
(see GB 2312) を 8bit (see 8bit) で符号拡張 (see Code extension)
している。

RFC 1922 (see RFC 1922) で定義されている。

cn-big5, big5
-------------

台湾や香港で用いられている主に繁体字で表記される中国語を表現するための
MIME charset (see MIME charset) の１つ。

ISO 2022 (see ISO 2022) に基かない 8bit (see 8bit) の符号化文字集
合(see Coded character set)で de-fact standard である。RFC 1922
(see RFC 1922) で定義されている。

cf.  [BIG5] Institute for Information Industry, "Chinese Coded
     Character Set in Computer", March 1984.

CNS 11643 (see CNS 11643) と対応関係がある。

CNS 11643-1992
--------------

台湾や香港で用いられている主に繁体字で表記される中国語を表現するための図形
文字集合(see Graphic character set)。台湾の標準。現在、94×94 (see
94x94 character set) の面が第１面から第７面まである。

ISO 2022 (see ISO 2022) での終端文字は

`plane 1'
     04/07 (`G')

`plane 2'
     04/08 (`H')

`plane 3'
     04/09 (`I')

`plane 4'
     04/10 (`J')

`plane 5'
     04/11 (`K')

`plane 6'
     04/12 (`L')

`plane 7'
     04/13 (`M')

である。

[CNS 11643-1992] "Standard Interchange Code for Generally-Used
     Chinese Characters", CNS 11643:1992.

Coded character set（符号化文字集合）, Character code（文字符号）
-----------------------------------------------------------------

文字と byte 列と１対１に対応付ける曖昧でない規則の集合。

Code extension（符号拡張）
--------------------------

与えられた図形文字集合(see Graphic character set)に含まれていない文字
の符号化のために用いる手法。ISO 2022 (see ISO 2022) はその１つ。

Content-Disposition field
-------------------------

Content の表示の仕方や file 名を表現するための field.  MIME (see
MIME)の拡張の１つ。

[RFC 1806] E R. Troost and S. Dorner, "Communicating Presentation
     Information in Internet Messages: The Content-Disposition Header",
     June 1995, Experimental.

Content-Type field
------------------

media type (see media type) や MIME charset (see MIME charset) な
どの body に関する情報を表現するための field.  RFC 2045 (see RFC 2045)
で定義されている。

*[Memo]*

     歴史的には RFC 1049 で Content-Type field が提案されている。但し、こ
     こでは type と subtype の区別はない。しかし、文法的には MIME parser
     は RFC 1049 に基づく message を未知の content-type を持った message
     としてparse できるだろう。

Content-Type field は

     "Content-Type" ":" *type* "/"
     *subtype* *( ";" *parameter* )

と定義される。

例えば、

          Content-Type: image/jpeg

や

          Content-Type: text/plain; charset=iso-2022-jp

などのように書かれる。

*[Memo]*

     content-type のない part は

               Content-Type: text/plain; charset=us-ascii

     として解釈される。(cf. us-ascii)

Emacs
-----

ここでは `Emacs' で FSF が配布している GNU Emacs を指し、`emacs' でGNU
Emacs の変種の総称とする。

encoded-word
------------

header における非 ASCII (see ASCII) 文字の表現。*RFC 2047* で定義され
ている。

[RFC 2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions)
     Part Three: Message Header Extensions for Non-ASCII Text", November
     1996, Standards Track (obsolete RFC 1521,1522,1590).

encapsulation
-------------

Internet mail (see RFC 822) を他の記事にまるごと入れる方法。

例えば、記事を転送したりするのに用いる。

(cf. message/rfc822)

Entity
------

ある message もしくは multipart (see multipart) message の１つの
partの header と body を併せたもの。

*[Memo]*

     ここでは part と呼ぶこともある。

euc-kr
------

韓国語を表現するための MIME charset (see MIME charset) の１つ。

ISO 2022 (see ISO 2022) に基いて ASCII (see ASCII) にKS C5601
(see KS C5601) を 8bit (see 8bit) で符号拡張 (see Code extension)
している。

RFC 1557 (see RFC 1557) で定義されている。

cf.  [euc-kr] Korea Industrial Standards Association, "Hangul Unix
     Environment", KS C 5861:1992.

FTP
---

Internet で file を転送するための protocol の１つ。RFC 959 で定義されてい
る。

[FTP: RFC 959] Postel, J. and J. Reynolds, "File Transfer
     Protocol", October 1985, STD 9.

GB 2312-1980
------------

中国大陸で用いられている簡体字で表記される中国語を表すための 94×94 文字集
合(see 94x94-character set)。中国の国家標準。ISO 2022 (see ISO 2022)
での終端 byte は 04/01 (`A').

これは GB における基本集である。

[GB 2312]『信息交換用漢字編碼字符集 -- 基本集』, "Code of Chinese
     Graphic Character Set for Information Interchange - Primary Set",
     GB 2312:1980.

GB 8565.2-1988
--------------

中国語のための補助図形文字集合(see Graphic character set)。中国の国家
標準。GB 2312 (see GB 2312) の空き部分に補充するように定義されたらしい。

[GB 8565.2] "Information Processing - Coded Character Sets for Text
     Communication - Part 2: Graphic Characters used with Primary Set",
     GB 8565.2:1988.

Graphic character set（図形文字集合）
-------------------------------------

図形文字からなる 符号化文字集合(see Coded character set)。

hz-gb2312
---------

中国大陸で用いられている簡体字で表記される中国語を表現するための MIME
charset (see MIME charset) の１つ。

ASCII (see ASCII) に GB 2312 (see GB 2312) を 7bit で符号拡張
(see Code extension)したものを ASCII printable になるように工夫してい
る。

RFC 1842, 1843 で定義されている。

[RFC 1842] Y. Wei, Y. Zhang, J. Li, J. Ding and Y. Jiang, "ASCII
     Printable Characters-Based Chinese Character Encoding for Internet
     Messages", August 1995, Informational.

[RFC 1843] F. Lee, "HZ - A Data Format for Exchanging Files of
     Arbitrarily Mixed Chinese and ASCII characters", August 1995,
     Informational.

ISO 2022
--------

符号化文字集合の構造と符号拡張(see Code extension)法を定めた国際標準。

これを用いて複数の図形文字集合(see Graphic character set)を組合せて
7bit (see 7bit) ないし 8bit (see 8bit) の 符号化文字集合(see
Coded character set) を作ることができる。

[ISO 2022] International Organization for Standardization (ISO),
     "Information Processing: ISO 7-bit and 8-bit coded character sets:
     Code extension techniques", ISO/IEC 2022:1994.

iso-2022-cn
-----------

中国語を表現するための MIME charset (see MIME charset) の１つ。

ISO 2022 (see ISO 2022) に基いて ASCII (see ASCII) に GB 2312
(see GB 2312), CNS 11643 plain 1, plain 2 (see CNS 11643) を
7bit (see 7bit) で符号拡張 (see Code extension)している。

RFC 1922 (see RFC 1922) で定義されている。

iso-2022-cn-ext
---------------

中国語を表現するための MIME charset (see MIME charset) の１つ。

ISO 2022 (see ISO 2022) に基いて ASCII (see ASCII) に GB 2312
(see GB 2312), CNS 11643 plain 1 .. 7 (see CNS 11643),
ISO-IR-165 (see ISO-IR-165) 等を 7bit (see 7bit) で符号拡張
(see Code extension)している。

RFC 1922 (see RFC 1922) で定義されている。

*[Memo]*
     MULE 2.3 および、現在の XEmacs/mule では正しく扱うことはできない。

     Emacs/mule では利用可能である。

iso-2022-jp
-----------

日本語を表現するための MIME charset (see MIME charset) の一つ。

古い ISO 2022 (see ISO 2022) に基いて ASCII (see ASCII), JIS
X0201-Latin, JIS X0208-1978 (see JIS C6226), JIS X0208-1983 (see
JIS X0208) を切り替える 7bit (see 7bit) 文字符号。

RFC 1468 で定義されている。

*[Memo]*
     JIS X0208-1997? では ISO 2022 (see ISO 2022) と独立に定義される予
     定。

[iso-2022-jp: RFC 1468] Murai J., M. Crispin, and E. van der Poel,
     "Japanese Character Encoding for Internet Messages", June 1993.

iso-2022-jp-2
-------------

iso-2022-jp (see iso-2022-jp) を拡張した MIME charset (see MIME charset)
の一つ。

RFC 1554 で定義されている。

[iso-2022-jp-2: RFC 1554] Ohta M. and Handa K., "ISO-2022-JP-2:
     Multilingual Extension of ISO-2022-JP", December 1993,
     Informational.

iso-2022-kr
-----------

韓国語を表現するための MIME charset (see MIME charset) の１つ。

ISO 2022 (see ISO 2022) に基いて ASCII (see ASCII) に KS C5601
(see KS C5601) を 7bit (see 7bit) で符号拡張 (see Code extension)
している。

RFC 1557 (see RFC 1557) で定義されている。

ISO 646
-------

各国で共通に使える最小限度の図形文字集合(see Graphic character set)を
定めたもの。94 文字集合 (see 94-character set)の１つ。ISO 646 IRV（国
際基準版）を元に幾つかの文字は各国で違う文字を割当ることを許していて、幾つ
かの変種が存在する。ASCII (see ASCII) や JIS X0201-Latin はその一種。

[ISO 646] International Organization for Standardization (ISO),
     "Information technology: ISO 7-bit coded character set for
     information interchange", ISO/IEC 646:1991.

ISO 8859-1
----------

西欧諸語で用いられる拡張 Latin 文字や記号からなる 96 文字集合(see
96-character set)。

[ISO 8859-1] International Organization for Standardization (ISO),
     "Information Processing -- 8-bit Single-Byte Coded Graphic
     Character Sets -- Part 1: Latin Alphabet No.1", ISO 8859-1:1987.

iso-8859-1
----------

西欧諸語などを表現するための MIME charset (see MIME charset) の１つ。

ISO 2022 (see ISO 2022) に基いて、ASCII (see ASCII) に ISO
8859-1 (see ISO 8859-1) を 8bit (see 8bit) で符号拡張 (see
Code extension)している。

RFC 2046 (see RFC 2046) で定義されている。

ISO 8859-2
----------

東欧諸語で用いられる拡張 Latin 文字や記号からなる 96 文字集合(see
96-character set)。

[ISO 8859-2] International Organization for Standardization (ISO),
     "Information Processing -- 8-bit Single-Byte Coded Graphic
     Character Sets -- Part 2: Latin alphabet No.2", ISO 8859-2:1987.

iso-8859-2
----------

東欧諸語を表現するための MIME charset (see MIME charset) の１つ。

ISO 2022 (see ISO 2022) に基いて、ASCII (see ASCII) に ISO
8859-2 (see ISO 8859-2) を 8bit (see 8bit) で符号拡張 (see
Code extension)している。

RFC 2046 (see RFC 2046) で定義されている。

ISO 8859-3
----------

[ISO 8859-3] International Organization for Standardization (ISO),
     "Information Processing -- 8-bit Single-Byte Coded Graphic
     Character Sets -- Part 3: Latin alphabet No.3", ISO 8859-3:1988.

ISO 8859-4
----------

[ISO 8859-4] International Organization for Standardization (ISO),
     "Information Processing -- 8-bit Single-Byte Coded Graphic
     Character Sets -- Part 4: Latin alphabet No.4", ISO 8859-4:1988.

ISO 8859-5
----------

キリル文字や記号からなる 96 文字集合(see 96-character set)。

[ISO 8859-5] International Organization for Standardization (ISO),
     "Information Processing -- 8-bit Single-Byte Coded Graphic
     Character Sets -- Part 5: Latin/Cyrillic alphabet", ISO
     8859-5:1988.

iso-8859-5
----------

キリル文字を表現するための MIME charset (see MIME charset) の１つ。

ISO 2022 (see ISO 2022) に基いて、ASCII (see ASCII) に ISO
8859-5 (see ISO 8859-5) を 8bit (see 8bit) で符号拡張 (see
Code extension)している。

RFC 2046 (see RFC 2046) で定義されている。

ISO 8859-6
----------

[ISO 8859-6] International Organization for Standardization (ISO),
     "Information Processing -- 8-bit Single-Byte Coded Graphic
     Character Sets -- Part 6: Latin/Arabic alphabet", ISO 8859-6:1987.

ISO 8859-7
----------

ギリシア文字や記号からなる 96 文字集合(see 96-character set)。

[ISO 8859-7] International Organization for Standardization (ISO),
     "Information Processing -- 8-bit Single-Byte Coded Graphic
     Character Sets -- Part 7: Latin/Greek alphabet", ISO 8859-7:1987.

iso-8859-7
----------

ギリシア語を表現するための MIME charset (see MIME charset) の１つ。

ISO 2022 (see ISO 2022) に基いて、ASCII (see ASCII) に ISO
8859-7 (see ISO 8859-7) を 8bit (see 8bit) で符号拡張 (see
Code extension)している。

RFC 1947 で定義されている。

[iso-8859-7: RFC 1947] D. Spinellis, "Greek Character Encoding for
     Electronic Mail Messages", May 1996, Informational.

ISO 8859-8
----------

[ISO 8859-8] International Organization for Standardization (ISO),
     "Information Processing -- 8-bit Single-Byte Coded Graphic
     Character Sets -- Part 8: Latin/Hebrew alphabet", ISO 8859-8:1988.

ISO 8859-9
----------

[ISO 8859-9] International Organization for Standardization (ISO),
     "Information Processing -- 8-bit Single-Byte Coded Graphic
     Character Sets -- Part 9: Latin alphabet No.5", ISO 8859-9:1990.

ISO-IR-165, CCITT Extended GB
-----------------------------

CCITT が登録した、中国大陸で用いられている簡体字で表記される中国語を表現す
るための94×94 文字集合(see 94x94-character set)。

GB 2312 (see GB 2312) と GB 8565 表２ (see GB 8565.2) に 150 文字
ほどを追加したものらしい。

ISO 2022 (see ISO 2022) での終端 byte は 04/05 (`E') である。

JIS X0201
---------

ISO 646 (see ISO 646) の変種の１つである Latin 文字集合と 1 byte のカ
タカナ文字集合と、これらからなる 7bit および 8bit 符号化文字集合(see
Coded character set) を定義している。

元は *JIS C6220-1976* と言ったが *JIS X0201* に番号が変更された。

[JIS X0201-1976]日本規格協会 (Japanese Standards Association),『情報
     交換用符号』, "Code for Information Interchange", JIS X 0201-1976:.

また、1997 年に改定版が出る予定。

[JIS X0201-1997?]  日本規格協会 (Japanese Standards Association),『７
     ビット及び８ビットの情報交換用符号化文字集合』, "7-bit and 8-bit
     coded character sets for information interchange", JIS X 0201:1997?
     draft.

JIS C6226-1978
--------------

日本語を表すために作られた94×94 文字集合(see 94x94-character set)。日
本の国家標準。JIS X0208-1978 ともいう。

(cf. JIS X0208)

JIS X0208
---------

日本語を表すために作られた94×94 文字集合(see 94x94-character set)。日
本の国家標準。1978 年版、1983 年版、1990 年版があるが、Internet では1983
年版がもっとも良く使われている。

JIS X0208 は記号、数字、ローマ字、ひらがな、カタカナ、ギリシャ文字、キリル
文字、罫線素、第１水準、第２水準の漢字が含まれる。但し、1983 年版の一部の
記号と罫線素は 1978 年版にはない。また、一部の漢字の字形が 1983 年版では変
更され、また、第１水準と第２水準が入れ替わっていたりする。このため、1978
年版と 1983 年版は異なる文字集合として扱われる。

1990 年の改定では 1983 年版に対する追加が行われた。このため、1990 年版を指
示する場合は前に更新シーケンス (ESC 02/06 4/0) を用いる。

[JIS X0208-1978]日本規格協会 (Japanese Standards Association),『情報
     交換用漢字符号系』, "Code of the Japanese graphic character set for
     information interchange", JIS C6226:1978.

[JIS X0208-1983,1990]日本規格協会 (Japanese Standards Association),
     『情報交換用漢字符号系』, "Code of the Japanese graphic character
     set for information interchange", JIS X0208:1983,1990.

また、1997 年に改定版が出版される予定。（字形の変更は行われないので文字集
合としては 1990 年版と同一である）

[JIS X0208-1997?]  日本規格協会 (Japanese Standards Association),『７
     ビット及び８ビットの２バイト情報交換用符号化漢字集合』, "7-bit and
     8-bit double byte coded Kanji sets for information interchange",
     JIS X 0208:1997? draft.

JIS X0212-1990
--------------

JIS X0208 (see JIS X0208) になかった文字を集めた94×94 文字集合
(see 94x94-character set)。「補助漢字」とも呼ばれる。日本の国家標準。
ISO 2022 (see ISO 2022) での終端 byte は 04/04 (`D').

koi8-r
------

ロシヤ語等で用いられるキリル文字を表現するための MIME charset (see
MIME charset) の１つ。

ISO 2022 (see ISO 2022) に基かない 8bit (see 8bit) の符号化文字集
合(see Coded character set)で de-fact standard である。

RFC 1489 で定義されている。

[RFC 1489] A. Chernov, "Registration of a Cyrillic Character Set",
     July 1993.

KS C5601-1987
-------------

韓国語を表すための 94×94 文字集合(see 94x94-character set)。韓国の国
家標準。ISO 2022 (see ISO 2022) での終端 byte は 04/03 (`C').

[KS C5601] Korea Industrial Standards Association, "Code for
     Information Interchange (Hangul and Hanja)", KS C 5601:1987.

media type
----------

MIME (see MIME) における entity (see entity) の種類。*type*と
*subtype* からなる。RFC 2046 (see RFC 2046) で定義されている。

type は標準では

   * *text*
   * *image*
   * *audio*
   * *video*
   * *application*
   * *multipart* (see multipart)
   * *message*

が定義され、それぞれには application/octet-stream, audio/basic,
image/jpeg, multipart/mixed (see multipart/mixed), text/plain (see
text/plain), video/mpeg などのさまざまな subtype が定義されている。

*[注意]*

     ここでは、text/plain などの type/subtype の組をしばしば
     *content-type/subtype* と書く。

media type は、RFC 2046 で定義されているものに加えて、登録することもできる。
現在、登録されているものは MEDIA TYPES
(ftp://ftp.isi.edu/in-notes/iana/assignments/media-types) で参照できる。

また、type もしくは subtype に、前に `x-' を付けた *x-token* を用いること
により、登録されていないものを私的に用いることもできる。しかし、当然のこと
ながら、こうした私的な content-type は諒解を得た者の間でしか解釈できないの
で利用には注意すること。

(cf. Content-Type field)

message
-------

ここでは RFC 822 (see RFC 822) で定義される mail と RFC 1036 (see
RFC 1036) で定義される news 記事の総称として用いる。

message/rfc822
--------------

伝統的な RFC 934 (see RFC 934) に代わり、RFC 822 (see RFC 822) で
定義される mail を表す MIME の形式。RFC 2046 (see RFC 2046) で定義され
ている。

method
------

tm で特定の種類の data を再生したとき実際にその処理を行なう program.
Emacs Lisp で書かれた *internal method* と C や script 言語などで書かれた
*external method* がある。

(cf. method (tm-view-ja))

MIME
----

*Multipurpose Internet Mail Extensions* の略で、Internet の mail
や news で us-ascii plain text (see us-ascii) 以外の文字を使うための
RFC 822 (see RFC 822) に対する拡張。

RFC 2045 は冒頭で次のように述べている：

STD 11, RFC 822 は、US-ASCII message header に関して非常に詳細に規定した
message 表現 protocol を定義している。しかし、それは単に flat なUS-ASCII
text のみに留まり、message の内容や message body に関する規定はなされてい
ない。Multipurpose Internet Mail Extensions, あるいは MIMEと総称される、こ
の一連の文書は、以下の事を可能とするために message の形式を再定義した：

  1. 文書 message body における US-ASCII 以外の文字集合
  2. 非文書 message body
  3. 複数の部分からなる message body
  4. US-ASCII 以外の文字集合からなる文書 header 情報

RFC 2045 (see RFC 2045), RFC 2046 (see RFC 2046), RFC 2047
(see encoded-word), RFC 2048 (see RFC 2048), RFC 2049 (see RFC 2049)
で定義されている。

MIME charset
------------

Content-Type field (see Content-Type field) や encoded-word (see
encoded-word) の charset parameter で用いられる登録された符号化文字集合
(see Coded character set)。

RFC 2045 (see RFC 2045) で定義されている。

iso-2022-jp (see iso-2022-jp) や euc-kr (see euc-kr) はその１つ。
（ここでは、MIME charset は図形文字集合 (see Graphic character set)と
区別して小文字で書いている）

MTA
---

*Message Transfer Agent* の略で、sendmail などの mail 配送
program と news server の総称。

(cf. MUA)

MUA
---

*Message User Agent* の略で、mail reader と news reader の総称。

(cf. MTA)

MULE
----

半田 剣一氏らが作った、多言語された GNU Emacs (see Emacs).

[MULE] Nishikimi M., Handa K. and Tomura S., "Mule: MULtilingual
     Enhancement to GNU Emacs", Proc. of INET'93, August, 1993.

現在、MULE の機能を Emacs に merge する作業が行われており、alpha 版
(ftp://etlport.etl.go.jp/pub/mule/mule-19.33-delta.taz)が存在する。

その他、XEmacs に merge したものも存在する。

このため、現在では多言語 Emacs は、元々の MULE を含めて３種類あることにな
る。

そこで、ここでは、多言語 Emacs の総称を *mule*, 元々
の MULE を *MULE*, mule 機能を merge した Emacs を
*Emacs/mule*, mule 機能を merge した XEmacs を
*XEmacs/mule* と呼ぶことにする。

Multipart
---------

１つの message (see message) に複数の entity (see entity) を入れる
ための MIME (see MIME) における media type (see media type) の１つ、
もしくは、複数の entity からなる message を指す。

現在、定義されている *multipart* としては、RFC 2046 (see RFC 2046) で
定義された

   * multipart/mixed (see multipart/mixed)
   * multipart/alternative (see multipart/alternative)
   * multipart/digest (see multipart/digest)
   * multipart/parallel (see multipart/parallel)

のほか RFC 1847 (see Security multipart) で定義された

   * multipart/signed (see multipart/signed)
   * multipart/encrypted (see multipart/encrypted)

などがある。

multipart/alternative
---------------------

multipart (see multipart) の１つで、同じ情報を異った形式で入れ、選択肢
とする場合に用いる。

(cf. RFC 2046)

multipart/digest
----------------

multipart (see multipart) の１つで、含まれる entity (see entity)
のdefault のmedia type (see media type) が multipart/mixed (see
multipart/mixed) などの場合 text/plain (see text/plain) であるのに対
し、*multipart/digest*では message/rfc822 (see message/rfc822) が用い
られる点が異なる。

これは伝統的な RFC 1153 (see RFC 1153) に基づく encapsulation (see
encapsulation) に代わるものである。

(cf. RFC 2046)

multipart/encrypted
-------------------

RFC 1847 で定義された Security multipart (see Security multipart) の１
つで、暗号化された message を表現するのに用いる。

(cf. PGP/MIME)

multipart/mixed
---------------

multipart (see multipart) の主要な subtype で、複数の part を順序付け
て並べる場合に用いる。

(cf. RFC 2046)

multipart/parallel
------------------

multipart (see multipart) の１つで、複数の part を順序付けずに含める場
合に用いる。

(cf. RFC 2046)

multipart/signed
----------------

RFC 1847 で定義された Security multipart (see Security multipart) の１
つで、電子署名を表現するのに用いる。

(cf. PGP/MIME)

PGP
---

Phil Zimmermann 氏が作成した公開鍵暗号処理系の１つ。message (see
message) の暗号化や電子署名を行うことができる。Pretty Good Privacy の略。

伝統的な PGP では encapsulation (see encapsulation) に RFC 934
(see RFC 934)に準じた方法を用いる。これは MIME (see MIME) と矛盾す
るので PGP/MIME (see PGP/MIME) が提案されている。一方、MIME において
PGPのencapsulation を用いる方法 (cf. PGP-kazu)も利用されてきた。し
かし、今後は PGP/MIME に統一していく方が望ましい。

[PGP: RFC 1991] D. Atkins, W. Stallings and P. Zimmermann, "PGP
     Message Exchange Formats", August 1996, Informational.

PGP-kazu
--------

山本 和彦 氏が提案した MIME (see MIME) で PGP (see PGP) を利用する
ための方法をここでは *PGP-kazu* と呼ぶことにする。

PGP-kazu は *application/pgp* という content-type (see content-type)
を定義する。

application/pgp の part では PGP の encapsulation (see
encapsulation)が用いられる。PGP の encapsulation (cf. RFC 934)と
MIME の encapsulation は矛盾するので、PGP の encapsulation を解かない限り、
中に含まれた MIME message を読むことができなくなる。即ち、PGP-kazu に対応
していない MIME に対応した MUA (see MUA) はその part が読めなくなる。
その代わり、MIME に対応していない PGP 対応の MUA (see MUA) でも
message を読むことができる。

PGP-kazu では MUA は PGP のと MIME のという２つの encapsulation を知らなけ
ればならない。また、application/pgp part を parse するためには、まず、
pgp の処理を行わなければならないので、parse 処理が複雑になる。

また、Internet では今後 PGP/MIME (see PGP/MIME) の方向で標準化していこ
うということで合意が取れている。よって、今後は PGP-kazu は用いないのが望ま
しい。

PGP/MIME
--------

Michael Elkins 氏が提案した MIME (see MIME) で PGP (see PGP) を利
用するための方法。

RFC 1847 (see Security multipart) に基き、MIME の multipart による
encapsulation (see encapsulation) を行う。このため、MIME の自然な拡張
になっている。しかし、伝統的な PGPとの互換性が失われている。

PGP/MIME では PGP-kazu (see PGP-kazu) と異なり、MIME の
encapsulationのみを用いる。また、このため、PGP の処理を行う前に message の
parse を行うことができる。

Internet では今後 PGP/MIME (see PGP/MIME) の方向で標準化していこうとい
うことで合意が取れている。よって、今後は PGP を用いる場合は PGP/MIMEを用い
るのが望ましい。

[PGP/MIME: RFC 2015] M. Elkins, "MIME Security with Pretty Good
     Privacy (PGP)", October 1996, Standards Track.

Quoted-Printable
----------------

RFC 2045 (see RFC 2045) で定義されている MIME (see MIME) における
binary data (see binary data) の network での変換法の１つ。

`=' や制御文字や 128 以上の文字などは `=AF' のように `=' の後に続く 16進数
で表現する。このため、ASCII (see ASCII) 文字中心の data ではBase64
(see Base64) に比べると可読性が高くなる可能性がある。

しかしながら、EBCDIC には存在しない文字を利用する場合、EBCDIC を利用してい
る network では安全に転送することができず、Base64 に比べて安全性は低い。

RFC 821
-------

*SMTP* と呼ばれる Internet mail の配送法の標準を定め
ている RFC.

[SMTP: RFC 821] J. Postel, "Simple Mail Transfer Protocol", August
     1982, STD 10.

RFC 822
-------

Internet mail の主に *message header* に関する形式に関する標準を定めている
RFC.

*[Memo]*

     news message もこれに準じているので、*Internet mail* と書くよりも、
     *Internet message* と書いた方が良いかもしれない。

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

RFC 934
-------

Internet mail (see RFC 822) の *encapsulation* (see
encapsulation) の方法を定めた RFC.

MIME (see MIME) と矛盾するので、現在では message/rfc822 (see
message/rfc822) を用いるべきである。

[RFC 934] Marshall T. Rose and Einar A. Stefferud, "Proposed
     Standard for Message Encapsulation", January 1985.

RFC 1036
--------

USENET での message の形式を定めた RFC.  RFC 822 (see RFC 822) の
subset になっている。Internet の標準ではないが、USENET 以外の netnews でも
これに準じているものが多い。

[USENET: RFC 1036] M. Horton and R. Adams, "Standard for
     Interchange of USENET Messages", December 1987, (obsolete RFC 850).

RFC 1153
--------

複数の Internet mail (see RFC 822) を *encapsulation* (see
encapsulation) するための方法を定めた RFC.

MIME (see MIME) と矛盾するので、現在では message/rfc822 (see
message/rfc822) を用いた multipart (see multipart) を用いるべきであ
る。

(cf. multipart/digest)

[RFC 1153] F. Wancho, "Digest Message Format", April 1990.

RFC 1557
--------

euc-kr (see euc-kr) と iso-2022-kr (see iso-2022-kr) という韓国語
のための MIME charset (see MIME charset) を定義している RFC.

[RFC 1557] U. Choi, K. Chon and H. Park, "Korean Character Encoding
     for Internet Messages", December 1993, Informational.

RFC 1922
--------

iso-2022-cn (see iso-2022-cn), iso-2022-cn-ext (see
iso-2022-cn-ext), cn-gb (see cn-gb), cn-big5 (see cn-big5) といっ
た中国語のための MIME charset (see MIME charset) を定義しているRFC.

これに加えて、*charset-edition* と *charset-extension* という
Content-Type field (see Content-Type field) の parameter を定義してい
る。

[RFC 1922] Zhu, HF., Hu, DY., Wang, ZG., Kao, TC., Chang, WCH. and
     Crispin, M., "Chinese Character Encoding for Internet Messages",
     March 1996, Informational.

RFC 2045
--------

[RFC 2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail
     Extensions (MIME) Part One: Format of Internet Message Bodies",
     November 1996, Standards Track (obsolete RFC 1521, 1522, 1590).

RFC 2046
--------

[RFC 2046] N. Freed and N. Borenstein, "Multipurpose Internet Mail
     Extensions (MIME) Part Two: Media Types", November 1996, Standards
     Track (obsolete RFC 1521, 1522, 1590).

RFC 2048
--------

[RFC 2048] N. Freed, J. Klensin and J. Postel, "Multipurpose
     Internet Mail Extensions (MIME) Part Four: Registration
     Procedures", November 1996, Standards Track (obsolete RFC 1521,
     1522, 1590).

RFC 2049
--------

[RFC 2049] N. Freed and N. Borenstein, "Multipurpose Internet Mail
     Extensions (MIME) Part Five: Conformance Criteria and Examples",
     November 1996, Standards Track (obsolete RFC 1521, 1522, 1590).

plain text
----------

書体や組版に関する情報を持たない文字符号(see Coded character set)のみ
で表現される text 情報。(cf. text/plain)

Security multipart
------------------

MIME (see MIME) で暗号や電子書名を用いるための形式。

*multipart/signed* (see multipart/signed) と
*multipart/encrypted* (see multipart/encrypted) という
multipart を用いる。

MOSS や PGP/MIME (see PGP/MIME) はこれに基いている。

[Security multipart: RFC 1847] James Galvin, Gale Murphy, Steve
     Crocker and Ned Freed, "Security Multiparts for MIME:
     Multipart/Signed and Multipart/Encrypted", October 1995, Standards
     Track.

text/enriched
-------------

RFC 1521 で定義された *text/richtext* に代わって、書体や組版に関する情報を
持った textを表現するための media type (see media type).

[text/enriched: RFC 1896] P. Resnick and A. Walker, "The
     text/enriched MIME Content-type", February 1996, (obsolete RFC
     1563).

text/plain
----------

RFC 2046 (see RFC 2046) で定義された、plain text (see plain text)
を表現するための media type (see media type).

非 MIME message などの content-type が定義されない entity (see entity)
は MIME charset (see MIME charset) が us-ascii (see us-ascii) である
*text/plain* の entity であると見做されることになっている。

tm-kernel, tm
-------------

Emacs で MIME (see MIME) を利用するための user interface を提供する
library 群。`tools for MIME' の略。

*[どうでも良いこと(^-^;]*

        *  tm は "tiny-mime" の略じゃないらしいぞ (^-^;

        *  tm は作者のイニシャルじゃないらしいぞ (^-^;

        *  "Tools for MIME" の略というのはこじつけらしいぞ (^-^;

tm-MUA
------

tm (see tm-kernel) を用いた MUA (see MUA) もしくは MUA に対する
extender.

*tm 大盛り package* には

   * mh-e (see (mh-e)) 用の*tm-mh-e* (see (tm-mh-e-en))
   * GNUS 用の *tm-gnus* (see (tm-gnus-ja))
   * Gnus 用の *gnus-mime* (see (gnus-mime-ja))
   * VM 用の *tm-vm* (see (tm-vm-en))
   * RMAIL 用の *tm-rmail*

が含まれている。

独立した MUA としては cmail (see (cmail)) が tm を利用可能である。

us-ascii
--------

アメリカ連邦などで使われる英語などを表現するための MIME charset (see
MIME charset) の１つ。

ASCII (see ASCII) のみからなり ISO 2022 (see ISO 2022) による符号
拡張 (see Code extension)は許されない。

Internet mail における標準の符号化文字集合(see Coded character set)で
あり、明示的に MIME charset が示されない場合は原則として
*us-ascii* が使われる。

また、RFC 822 (see RFC 822) における *ASCII* は us-ascii を指すものと
解釈すべきである。

設定
****

この package には `mime-setup.el' と`tm-setup.el' という簡易設定 file が附
属しています。

`mime-setup.el' では `tm-edit.el' を使った MIME message の作成も含めた
MIME 全般の設定を行ない、`tm-setup.el' では tm-MUA に関するMIME message の
閲覧の設定のみを行ないます。

標準的な設定
============

tm の一般的な設定を行いたい場合は、*mime-setup* という標準設定file を使っ
てください。例えば、`~/.emacs' 等で、

     (load "mime-setup")

とするだけで OK です。

`mime-setup.el' は `tm-setup.el' を呼んでいるので、`tm-setup.el' を load
する必要はありません。（過去のGnus FAQ の記述は間違っています！）

signature.el
------------

tm には *signature* という signature の自動切替えtool が附属しており、
`mime-setup.el' はこの設定も行ないます。message header の field に合わせて
signature の自動切替を行ないたい場合は `~/.emacs' に以下のようなものを入れ
て下さい。（詳しくは signature.el の説明書を参照して下さい）

     (setq signature-file-alist
           '((("Newsgroups" . "jokes")       . "~/.signature-jokes")
             (("Newsgroups" . ("zxr" "nzr")) . "~/.signature-sun")
             (("To" . ("ishimaru" "z-suzuki")) . "~/.signature-sun")
             (("To" . "tea")                 . "~/.signature-jokes")
             (("To" . ("sim" "oku" "takuo")) . "~/.signature-formal")
             ))

 -- Variable: mime-setup-use-signature

     この変数が `nil' 以外の時、`signature.el' を使います。既定値は`t' で
     す。

 -- Variable: mime-setup-signature-key-alist

     各 major-mode において signature 挿入命令を設定すべき key を指定しま
     す。既定値は

          	((mail-mode . "\C-c\C-w"))

     です。

     これを変更したい場合は、関数 set-alist などを使ってこの変数を書き換え
     て下さい。

          (set-alist 'mime-setup-signature-key-alist
          	   'news-reply-mode "\C-c\C-w")

 -- Variable: mime-setup-default-signature-key

     ある major-mode において signature 挿入命令を設定すべき key が見つか
     らない場合、この変数に設定された key が用いられます。既定値は、
     `"\C-c\C-s"' です。

GNUS の場合の注意
-----------------

`signature.el' を使う場合、`mime-setup.el' は変数 `gnus-signature-file' を
`nil' に設定します。よって、送信時に自動的に `signature' が付く機能は抑制
されます。このようなことをしているのは以下の理由からです。

GNUS が signature を付けるのは `tm-edit.el' によって MIME message が作成さ
れた後です。よって、GNUS が付けた signature は MIME message として正しく処
理されていません。例えば multipart message の場合、MIME message の外の非
MIME part に付きます。よって、MIME 対応 MUAで見た場合、signature は表示さ
れないかも知れません。

もう一つの注意は標準設定では signature を挿入する key は `C-c C-w'ではなく
mh-e (see (mh-e)) と同じ `C-c C-s' に割り当てられていることです。これ
は

     (set-alist 'mime-setup-signature-key-alist 'news-reply-mode "\C-c\C-w")

によって GNUS の標準に戻すことができます。

tm-edit を使わない設定
======================

*tm-setup* は tm-MUA (see tm-MUA) の設定のみを行なう module で
す。この設定 file では tm-edit (see (tm-edit-ja)) を使った MIME
message の作成に関する設定は行われず、MIME message の閲覧に関する設定のみ
が行われます。MIME message を読みたいが自分では作成しないとか、tm-edit以外
の MIME composer を使いたい場合には mime-setup.el の代わりにこの設定file
を使ってください。

例えば、`~/.emacs' 等に

     (load "tm-setup")

を入れれば OK です。

*[Memo]*

     `mime-setup.el' を load している場合、これを陽に load する必要はあり
     ません。

VM を使う場合の設定
===================

*vm* を使う場合は `~/.vm' に

     (require 'tm-vm)

を入れて下さい。

*[注意]*

     *BBDB* を使う場合は `(bbdb-insinuate-vm)' の *後* に
     `(require 'tm-vm)' を入れてください。

設定 file を使わない場合
========================

`mime-setup.el' や `tm-setup.el' を参考にして下さい。

*[Memo]*

     現在の tm では tm-edit の使用を仮定した幾つかの便利な機能が存在し、こ
     れらの機能は `mime-setup.el' を使わないと利用できません。もし、
     tm-edit を使う独自の設定を行う場合は、

          (provide 'mime-setup)

     という宣言を行ってください。

bug 報告の仕方
**************

tm のバグを見つけたら、以下の address に mail を送ってください：

   *  日本語 <bug-tm-ja@chamonix.jaist.ac.jp>
   *  英語 <bug-tm-en@chamonix.jaist.ac.jp>

但し、あまりにも古い版に関する報告は歓迎されません。古い版の bug は、新し
い版では治っているかもしれません。まず、最新版で確認してみましょう。

それから、適切な報告をしましょう。単に「うまく動かない」と言われてもどうい
う状況なのかはさっぱり判りません。最低限、OS, emacs, tm, 使っているMUA の
種類および版、設定を書く必要があります。また、error が起っている場合は
backtrace を送ることも重要です。(cf. Bugs (emacs))

また、bug は大抵複数の人が遭遇するものです（そうでなければ、bug ではない可
能性があります）。だから、作者に直接 mail を送ると作者は同じ mailを何通も
書く羽目になります。だから、必ず bug 報告は上記の address に送ってください。

tm ML では tm のバグ情報の交換や最新版の配布、tm の改良に関する議論を行なっ
ています。tm ML に参加したい方は

   *  日本語 <tm-ja-admin@chamonix.jaist.ac.jp>
   *  英語 <tm-en-admin@chamonix.jaist.ac.jp>

まで mail を送って下さい。登録は手動ですので、できれば、自然言語で書いて下
さい。(^_^)

謝辞
****

私が tm-view を最初に作った時に、厳しい注文と有益な助言を下さり、その設計
に多大な与えられた升谷保博さんに感謝します。

`tm-ew-d.el' と `mel-b.el' の前身に当たる`mime.el' を書き、その配布と改造
をお許し下さった榎並嗣智さんに感謝します。

また、LaTeX 用の内部 method と message/partial 用の自動結合 method を提供
して下さった岡部寿男さん、tar archive 用の内部 method を提供して下さった上
野博さんに感謝します。

tm-edit の前身となった `mime.el' を書き、その配布と改造をお許し下さった、
梅田政信さんに感謝します。tm-edit の user interface の基本的な設計は梅田さ
んの手によるもので、とても良い設計であったと思います。

tm の幾つかの module の maintainer を引き受けて下さった小林修平さん、彼は
また、RFC に対する適合性に対して鋭い指摘を多々行うことで tm の動作の規格に
対する忠実度を上げるのに非常な貢献を行いました。

また、tm-vm の maintainer を引き受けて下さった Oscar Figueiredo さんに感謝
します。精力的に tm-vm を改良し、また、立派な説明書を書いて下さいました。

最後に、beta test に協力して下さった日本語版、英語版双方の tm mailing
list の member に感謝します。また、patch を送って下さった全ての方に感謝し
ます。

概念索引
********