9. 付録

9.1 用語

9.1.1 7bit

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

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

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

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

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

9.1.2 8bit

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

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

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

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

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

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

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

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

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

9.1.3 ASCII

アメリカ連邦で使われる文字を符号化した符号化文字集合 (@ref{符号化文字集 合})。A-Z, a-z の Latin 文字と数字、幾つかの記号からなる。ISO 646 の一つ で、現在は国際基準版 (IRV) になっている。

[ASCII]

“Coded Character Set – 7-Bit American Standard Code for Information Interchange”, ANSI X3.4:1986.

9.1.4 Base64

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

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

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

9.1.5 binary

任意の byte 列を binary と呼ぶ。

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

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

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

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

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

9.1.7 media-type

MIME (MIME) における entity (@ref{entity}) の種類。 primary-type と subtype からなる。RFC 2046 (RFC 2046) で定義されている。

primary-type は標準では

• text
• image
• audio
• video
• application
• multipart (@ref{multipart})
• message

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

[注意]

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

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

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

(cf. Content-Type 欄の情報)

9.1.8 message

ここでは mail と news 記事の総称として用いる。

9.1.9 MIME

Multipurpose Internet Mail Extensions の略で、Internet の mail や news で us-ascii plain text (us-ascii) 以外の文字を使うための RFC 822 (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 (RFC 2045), RFC 2046 (RFC 2046), RFC 2047 (Header の network 表現), RFC 2048 (RFC 2048), RFC 2049 (RFC 2049) で定義されている。

9.1.10 MIME charset

Content-Type (Content-Type 欄の情報) 欄や encoded-word (Header の network 表現) の charset parameter で用いられる登録された符号化文字集合(Coded character set（符号化文字集合）, Character code（文字符号）)。

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

iso-2022-jp や euc-kr はその１つ。

9.1.11 MTA

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

(cf. MUA)

9.1.12 MUA

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

(cf. MTA)

9.1.13 Quoted-Printable

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

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

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

9.1.14 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.

9.1.15 RFC 1036

USENET での message の形式を定めた RFC. RFC 822 (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).

9.1.16 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).

9.1.17 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).

9.1.18 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).

9.1.19 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).

9.1.20 plain text

書体や組版に関する情報を持たない文字符号(Coded character set（符号化文字集合）, Character code（文字符号）)のみ で表現される text 情報。(cf. @ref{text/plain})

9.1.21 us-ascii

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

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

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

また、RFC 822 (RFC 822) における ASCII は us-ascii である。

9.2 bug 報告の仕方

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

• 英語 <emacs-mime-en@m17n.org>
• 日本語 <emacs-mime-ja@m17n.org>

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

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

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

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

• 英語 <emacs-mime-en-ctl@m17n.org>
• 日本語 <emacs-mime-ja-ctl@m17n.org>

に空の mail を送って下さい。

9.3 CVS による開発

FLIM の file は CVS を使って管理されています。このため、以下の方法で最 新の FLIM を入手することができます：

(0) cvs login

    % cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/root login

    CVS password: [CR] # NULL string

(1) checkout

    % cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/root checkout
	checkout [-r TAG] flim

CVS を用いた開発に参加したい方は

• <cvs@cvs.m17n.org>

まで、アカウント名と ssh の公開鍵を送ってください。ssh 経由では、 cvsroot は :ext:cvs@cvs.m17n.org:/cvs/root となります。

9.4 歴史

FLIM の code の最古の部分は 榎並 嗣智 氏が書いた ‘mime.el’ に起源し ます。この小さな program は Nemacs で動作する iso-2022-jp の B-encoding 専用の encoded-word の復号化プログラムでした。

その後、守岡 知彦 は ‘mime.el’ を元に‘tiny-mime.el’ というプロ グラムを書きます。これは、Nemacs と Mule で動作する encoded-word の符号 化・復号化プログラムでした。‘tiny-mime.el’ は B-encoding だけでなく Q-encoding もsupport し、また、MULE で扱うことができるさまざまな MIME charset (MIME charset) を同時に使うことができました。この時、 Nemacs と Mule の双方を support するために用いられたテクニックは後に emu package にまとめられます。

この頃、守岡 知彦 は ‘tiny-mime.el’ をさまざまな MUA で使うための設 定集も配布していましたが、それらは後に‘tiny-mime.el’ とともに１つの package にまとめられ、tm という名前で配布されます。

守岡 知彦 はやがて、MIME message を閲覧するためのプログラムである ‘tm-body.el’ を書きます。これは、すぐに‘tm-view.el’ という名前 に変わりましたが、やがて、これが‘tiny-mime.el’ に代わって、tm の中 核となります。

‘tm-view.el’ は当然、Content-Transfer-Encoding を扱う必要があります。 この目的のために、MEL が整備されはじめました。Base64 に関しては ‘tiny-mime.el’ の code が移され、また、新たにQuoted-Printable の code が追加されました。これらが‘mel-b.el’ と ‘mel-q.el’ になり ました。

また、後に、守岡 知彦 によって uuencode 用の ‘mel-u.el’ が追加され、 その後に、小林 修平 氏によって x-gzip64 用の‘mel-g.el’ が追加されま した。

tm では後に、守岡 知彦 によって ‘tiny-mime.el’ の再実装が行われ、こ の過程で、STD 11 の parser が書かれました。これは、現在の ‘std11.el’ に当たります。また、この過程で ‘tiny-mime.el’ は復 号化を行う ‘tm-ew-d.el’ と符号化を行う ‘tm-ew-e.el’ に分けられ ました。この両者が現在の ‘eword-decode.el’ と ‘eword-encode.el’ の先祖に当たります。

後に、守岡 知彦 らによって tm の全面書き換え作業が行われ、この過程で、tm は APEL, MEL, SEMI, EMH, RMAIL-MIME, Gnus-MIME などに分けられました。こ のうちの MEL が FLIM の直接の先祖に当たります。

後に、APEL から ‘std11.el’ が移され、また、‘mailcap.el’, ‘eword-decode.el’ および ‘eword-encode.el’ が SEMI から移され、 package の名前が FLIM となります。

この直前から田中 哲 氏がより RFC に忠実な実装を書き始め、これは、現在、 FLIM の枝である “FLIM-FLAM” となっています。

This document was generated by Yasutaka SHINDOH on May 11, 2011 using texi2html 1.82.