9. 付録

9.1 用語

9.1.1 7bit
9.1.2 8bit
9.1.3 ASCII
9.1.4 Base64
9.1.5 binary
9.1.6 Coded character set（符号化文字集合）, Character code（文字符号）
9.1.7 media-type
9.1.8 message
9.1.9 MIME
9.1.10 MIME charset
9.1.11 MTA
9.1.12 MUA
9.1.13 Quoted-Printable
9.1.14 RFC 822
9.1.15 RFC 1036
9.1.16 RFC 2045
9.1.17 RFC 2046
9.1.18 RFC 2048
9.1.19 RFC 2049
9.1.20 plain text
9.1.21 us-ascii

9.1.1 7bit

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

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

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

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

しかし、7bit であればどんな data でも良いとはいえない。なぜなら、１行の 長さがあまりに長いと、MTA はその message を転送することができないからで ある。ちなみに、RFC 821 (@xref{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 (@xref{ISO 2022}) の「8 単位系」と同様）。

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

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

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

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

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

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

9.1.3 ASCII

アメリカ連邦で使われる文字を符号化した符号化文字集合 (@xref{符号化文字集 合})。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 (9.1.16 RFC 2045) で定義されている MIME (9.1.9 MIME) における binary data (9.1.5 binary) の network での変換法の１つ。

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

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

9.1.5 binary

任意の byte 列を binary と呼ぶ。

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

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

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

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

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

9.1.7 media-type

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

primary-type は標準では

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

が定義され、それぞれには application/octet-stream, audio/basic, image/jpeg, multipart/mixed (@xref{multipart/mixed}), text/plain (@xref{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. 4. Content-Type 欄の情報)

9.1.8 message

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

9.1.9 MIME

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

9.1.10 MIME charset

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

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

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

9.1.11 MTA

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

(cf. 9.1.12 MUA)

9.1.12 MUA

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

(cf. 9.1.11 MTA)

9.1.13 Quoted-Printable

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

`=' や制御文字や 128 以上の文字などは `=AF' のように `=' の後に続く 16 進数で表現する。このため、ASCII (9.1.3 ASCII) 文字中心の data では Base64 (9.1.4 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 (9.1.14 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

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

9.1.21 us-ascii

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

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

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

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

9.2 bug 報告の仕方

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

• 英語
• 日本語

但し、あまりにも古い版に関する報告は歓迎されません。古い版の 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 に参加したい方は

• 英語
• 日本語

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

9.3 CVS による開発

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

(0) cvs login

    % cvs -d :pserver:[email protected]:/cvs/root login

    CVS password: [CR] # NULL string

(1) checkout

    % cvs -d :pserver:[email protected]:/cvs/root checkout
        checkout [-r TAG] flim

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

まで、アカウント名と ssh の公開鍵を送ってください。ssh 経由では、 cvsroot は :ext:[email protected]:/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 (9.1.10 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" となっています。