このファイルは Emacs MIME インターフェースの機能を文書化したものです。

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc.

     Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with the Front-Cover texts being ``A GNU Manual'', and with the Back-Cover Texts as in (a) below.  A copy of the license is included in the section entitled ``GNU Free Documentation License'' in the Emacs manual.

     この文書を、フリーソフトウェア財団発行の GNU フリー文書利用許諾契約書第 1.2 版またはそれ以降の版が定める条件の下で複製、配布、あるいは変更することを許可します。変更不可部分は指定しません。“A GNU Manual”は表表紙テキスト、以下の (a) は裏表紙テキストです。この利用許諾契約書の複写は “Emacs manual”の「GNU フリー文書利用許諾契約書」という章に含まれています。

     (a) The FSF's Back-Cover Text is: ``You have freedom to copy and modify this GNU Manual, like GNU software.  Copies published by the Free Software Foundation raise funds for GNU development.''

     (a) FSF の裏表紙テキスト:「あなたにはこの GNU Manual を GNU ソフトウェアのように複製したり変更する自由があります。複製はフリーソフトウェア財団によって出版されました。(フリーソフトウェア財団は) GNU の開発のために必要な資金を集めています。」

     This document is part of a collection distributed under the GNU Free Documentation License.  If you want to distribute this document separately from the collection, you can do so by adding a copy of the license to the document, as described in section 6 of the license.

     この文書は「GNU フリー文書利用許諾契約書」に基づいて配布された収集著作物の一部です。もしあなたがこの文書を収集著作物から分離して配布したいときは、契約書の第 6 章に記述されているように、文書に契約書の複写を付加することによって、行なうことができます。

Emacs MIME
**********

このマニュアルは MIME メッセージの作成と表示に使われるライブラリーを文書化したものです。

このマニュアルは MIME のエンコード/デコード処理の振る舞いを変更したい利用者、Emacs MIME ライブラリーがどのように動作するかをもっと詳しく知りたい利用者、および MIME の要素を操作する関数や命令を書きたい人たちを対象にしています。

MIME は Multipurpose Internet Mail Extensions の省略表記です。この標準は多数の RFC に文書化されていて、主なものは次の通りです: RFC2045 (インターネット・メッセージの本文の書式), RFC2046 (メディアタイプ), RFC2047 (非-ASCII テキストのためのメッセージヘッダーの拡張), RFC2048 (登録手続), RFC2049 (適合基準と事例)。MIME に準拠したソフトウェアを書こうと思っている人は誰でも、少なくとも RFC2045 と RFC2047 は読んでおくことを強く勧めます。

デコードと表示
*******

この章は、上位階層での MIME メッセージのデコードと表示を扱います。

その主な目的は、最初に MIME の記事を解析してから、その解析の結果として返される「ハンドル」のリストに基づいて、他のプログラムが処理を行なうことができるようにすることです。

解体
==

mm-dissect-buffer は MIME 記事の解体を担当する関数です。マルチパートのメッセージが与えられると、メッセージを再帰的に掘り下げて構造をたどり、そのメッセージの構造を描写する MIME ハンドルの木構造を返します。

非-MIME
======

Gnus はいくつかの MIME ではない添付ファイルも理解します。それらは postscript, uuencode, binhex, yenc, shar, forward, gnatsweb, pgp, diff のようなものです。それぞれの機能は、mm-uu-configure-list に項目を追加することによって無効にすることができます。例です。

     (require 'mm-uu)
     (add-to-list 'mm-uu-configure-list '(pgp-signed . disabled))

postscript
     ポストスクリプトのファイル。

uu
     Uuencode されたファイル。

binhex
     Binhex でエンコードされたファイル。

yenc
     Yenc でエンコードされたファイル。

shar
     Shar で作られたアーカイブ・ファイル。

forward
     MIME を使わずに転送されたメッセージ。

gnatsweb
     Gnatsweb の添付ファイル。

pgp-signed
     PGP で署名された平文 (clear text, ひらぶん)。

pgp-encrypted
     PGP で暗号化された平文 (clear text, ひらぶん)。

pgp-key
     PGP の公開鍵。

emacs-sources
     Emacs のソースコード。この項目は mm-uu-emacs-sources-regexp に合致するグループでのみ動作します。

diff
     パッチ。これは、コミットされたファイルの差分が自動的に送られるグループを対象にしたものです。mm-uu-diff-groups-regexp に合致するグループでのみ動作します。

verbatim-marks
     Slrn ふうの verbatim (文章を一言一句そのまま表す) 記号の対。

     (訳注: #v+ と #v- の二行で囲まれたテキストを MIME パートに見立てます。)

LaTeX
     LaTeX の文献。mm-uu-tex-groups-regexp に合致する名前のグループでのみ動作します。

いくつかの MIME ではない添付は mm-uu-extract というフェースを使って表示されます。ディフォルトではそれらのパートに MIME ボタンが付きません。K b (gnus-summary-display-buttonized) を使うか gnus-buttonized-mime-types に text/x-verbatim を加えることによって、ボタンの表示を強制することができます。See MIME コマンド (The Gnus Manual).

(訳注: ここで唐突に text/x-verbatim のことが出てくるのは、フェースが使われてボタンが付かない代表的なパートが verbatim-marks だからです。)

ハンドル
====

MIME ハンドルは、MIME の構成要素を完全に描写するリストです。

ハンドルの要素をアクセスするために、以下のマクロを使うことができます:

mm-handle-buffer
     デコードされていない MIME パートの内容物を保持しているバッファーを返します。

mm-handle-type
     パートの解析された Content-Type を返します。

mm-handle-encoding
     パートの Content-Transfer-Encoding を返します。

mm-handle-undisplayer
     表示されているパートを消すことができるもの (訳注: 関数など) を (それが表示されている場合に) 返します。

mm-handle-set-undisplayer
     表示されているパートを消すことができるもの (訳注: 関数など) を設定します。

mm-handle-disposition
     パートの解析された Content-Disposition (訳注: 配置指定) を返します。

mm-get-content-id
     Content-ID で参照されるハンドル (単数または複数) を返します。

表示
==

表示し、消去し、保存するための関数です。

mm-display-part
     パートを表示します。

mm-remove-part
     パートを (それが表示されていたら) 消去します。

mm-inlinable-p
     MIME タイプがインラインで表示可能かどうかを返します。

mm-automatic-display-p
     MIME タイプが自動的に表示されるべきかどうかを返します。

mm-destroy-part
     パートによって使われているすべての資源を開放します (訳注: パートの表示、およびパートを解体して得た個々の部品を一時的に保持しているバッファーやファイルを消去します)。

mm-save-part
     パートをファイルに保存します。

mm-pipe-part
     パートを何かのプロセスにパイプします。

mm-interactively-view-part
     パートを表示するために使う mailcap の手段を利用者が入力することを求めて、それを使って表示します。

表示のカスタマイズ
=========

mm-inline-media-tests
     これは連想リストです。鍵 (第一要素) は MIME タイプ、第二要素はパートを「インライン」で (すなわち Emacs の画面に埋め込んで) 表示するための関数、そして第三要素はそのパートがインラインで表示することが可能かどうかを調べるために eval (評価) される式です。

     この変数は、あるパートがインライン表示可能かどうかと、もし可能ならそのやり方を指定します。パートが現実にインライン表示されているかどうかを示すものではありません。

mm-inlined-types
     一方これは、上記の変数によって設定された条件を満足した場合に、インライン表示を行なうタイプを示します。これは MIME メディアタイプのリストです。(訳注: それぞれの要素は正規表現です。)

mm-automatic-display
     これは上記の変数が認めるタイプに限って「自動的」に表示されるタイプのリストです。つまり、インライン表示が可能なパートだけが自動的に表示されます。

mm-automatic-external-display
     これは外部ビューワーで自動的に表示されるタイプのリストです。

mm-keep-viewer-alive-types
     これは、別の記事を選択しても外部ビューワーが kill されないメディアタイプのリストです。

     訳注: postscript や dvi など (変数のディフォルト値を参照のこと) のように、読むのに時間がかかるかもしれないパートのタイプを含むリストです。一方、これに含まれない単純な画像のパートなどは、それが含まれていた記事の表示をやめたときに、自動的に外部ビューワーが kill されます。

mm-attachment-override-types
     いくつかの MIME エージェントは「添付ファイル」(attachment) の配置指定 (content-disposition) を持つパートを生成します。この変数に含まれる MIME タイプの場合はそんな配置指定を無視して、そのパートをインライン表示することができるようにします。(そのパートをインライン表示することが可能で、私たちがそうすることを望む場合に限って、配置指定が無視されることに注意して下さい。)

mm-discouraged-alternatives
     multipart/alternative に含まれている、見たくないパートの MIME タイプのリストです。メッセージの後半にあるパートが最も豊かな内容になっていると想定しているので、表示エージェントはそれを表示することになっています。しかし、利用者は代わりに他のタイプを見ることを好むかもしれません。このリストは、どんなタイプを最も見たくないかを指定するために使います。例えばもし text/html パートをぜんぜん見たくなくて、 text/richtext パートはあまり見たくないということであれば、以下のように宣言することができます:

          (setq mm-discouraged-alternatives
                '("text/html" "text/richtext")
                mm-automatic-display
                (remove "text/html" mm-automatic-display))

mm-inline-large-images
     ウィンドウより大きなインライン画像を表示すると、Emacs はスクロールすることができません。つまり画像の全体を見ることができないということです。これを避けるために、ライブラリーはそれをインライン表示する前に画像のサイズを計って、それがウィンドウに合わない場合は、ライブラリーはそれを外部で (例えば ImageMagick や xv で) 表示します。この変数を t に設定すると、この検査をさせなくして、ライブラリーにすべての画像をサイズに関わりなくインラインで表示させます。

mm-inline-override-types
     mm-inlined-types は、例えばすべての text/.* パートをインラインで表示することを指示するような正規表現を含んでいるかもしれません。一方、インライン表示が可能だけれども添付ファイルとして扱いたいタイプがあるならば、そのタイプに合致する正規表現のリストをこの変数に設定することによって、それを実現することができます。例えば mm-inlined-types が text/.* を含んでいるものとすると、この変数に text/html を含ませることによって、text/html パートは添付ファイルとして扱われるようになります。

mm-text-html-renderer
     HTML を描画するために使う関数を選択します。すでに用意してある描画プログラムは、w3, w3m (emacs-w3m についての詳細は http://emacs-w3m.namazu.org/ を見て下さい。), links, lynx, w3m-standalone または html2text のシンボル群のうちの一つを指定することによって選択します。もし nil だったら、外部ビューワーを使います。さらに関数 (引数として MIME ハンドルが与えられて呼ばれる) を設定することもできます。

mm-inline-text-html-with-images
     HTML メールには <img> タグを使った spammers (spam をばらまくやから) の卑劣な悪巧みが含まれているかもしれません。最もありそうなのは、あなたがそのメールを読んだことを確認するための意図があることです。このオプションを nil に設定する (それがディフォルトです) ことによって、あなたの個人情報が流出するのを防ぐことができます。今のところ Emacs/W3 はこれを無視します。Emacs-w3m では、これが nil であっても、画像が埋め込まれた場所で t 命令を使うことによって画像を表示することができます。 (T 命令はすべての画像を取り込みます。 w3m-key-binding オプションを info に設定した場合は、代わりに i か I を使って下さい。)

mm-w3m-safe-url-regexp
     安全な URL 名、すなわち HTML メールを描画するときに個人情報が流出しそうもない URL に合致する正規表現です (ディフォルト値は \\`cid: です)。nil にすると、すべての URL が安全だと判断します。

mm-inline-text-html-with-w3m-keymap
     このオプションを非-nil に設定することによって、インライン表示された text/html パートで emacs-w3m の命令キーを使うことができます。ディフォルト値は t です。

mm-external-terminal-program
     外部の端末を起動するために使われるプログラムです。

mm-enable-external
     外部の MIME ハンドラーを使うべきかどうかを指定します。

     t だったら、定義されているすべての外部の MIME ハンドラーが使われます。nil にすると、ファイルはディスクに保存されます (mailcap-save-binary-file)。これが ask というシンボルだったら、外部の MIME ハンドラーが起動される前に尋ねられるでしょう。

     Mailcap (see mailcap) を介して添付ファイルの表示を始めると、安全なビューワーを最も安全なオプションで使うことを試みます (添付ファイルをディスクに保存して、異なる手段 (コマンドラインかダブルクリック) でその表示を始める場合とは違います)。とにかく、必ずどんな外部プログラムも使わないようにしたいのであれば、この変数を nil か ask に設定して下さい。

ファイルとディレクトリー
============

mm-default-directory
     添付ファイルを保存するための、ディフォルトのディレクトリーです。 nil だったら default-directory を使います。

mm-tmp-directory
     一時ファイルを格納するためのディレクトリーです。

mm-file-name-rewrite-functions
     MIME パートのファイル名を書き換えるために使われる関数のリストです。それぞれの関数はファイル名に対して順繰りに実行されます (訳注: ある関数の戻り値が次の関数の引数になります)。出来合いの関数は以下の通りです。

     mm-file-name-delete-control
          すべての制御文字を消去します。

     mm-file-name-delete-gotchas
          欠陥があるシェルスクリプトで使われると意図しない結果を生じる文字、すなわち |, > および <、加えて最初の文字として使われる - と . を消去します。

     mm-file-name-delete-whitespace
          すべての空白文字を取り除きます。

     mm-file-name-trim-whitespace
          先頭と末尾の空白文字を取り除きます。

     mm-file-name-collapse-whitespace
          複数の連続した空白文字を単一のスペース文字で置き換えます。

     mm-file-name-replace-whitespace
          空白文字を下線 (underscore) で置き換えます。下線がお好みでなければ、他の文字を mm-file-name-replace-whitespace 変数に設定して下さい。

     Emacs 標準の関数である capitalize, downcase, upcase および upcase-initials も役に立つことがあるかもしれません。

mm-path-name-rewrite-functions
     MIME パートのフル・ファイル名を書き換えるために使われる関数のリストです。これはパートを外部で表示するとき (すなわち、融通の効かないプログラムが、ファイルが保存された場所を見つけることができるように、絶対パス名を変換するため) に使われます。

新しいビューワー
========

これは text/enriched パートをインライン表示するビューワーの例です:

     (defun mm-display-enriched-inline (handle)
       (let (text)
         (with-temp-buffer
           (mm-insert-part handle)
           (save-window-excursion
             (enriched-decode (point-min) (point-max))
             (setq text (buffer-string))))
         (mm-insert-inline handle text)))

この関数がパラメーターとして MIME ハンドルを受け取ることがわかりますね。それは一時バッファーに作業場所を移し、パートのテキストを挿入し、そのテキストに何かの処理を施し、結果を覚えておいて、関数が呼ばれたときのバッファーに戻ってその結果を挿入します。

ここにある二つの重要なお助け関数は mm-insert-part と mm-insert-inline です。最初の関数は、ハンドルのテキストを現在のバッファーに挿入します。これは文字セットおよびエンコーディグ (content transfer decoding) を取り扱います。二番目の関数は、挿入しろと言ったどんなテキストでも単に挿入しますが、テキストを手軽な方法で「表示されなくする」(undisplayed にする) ことができるような諸設定をも行ないます。

MIME メッセージの作成
*************

MIME メッセージの作成はうんざりする仕事だし簡単でもありません。そこで、MML (MIME Meta Language) という言語を解析して、MIME メッセージを生成するための、mml というライブラリーが作られました。

主要なインターフェース関数は mml-generate-mime です。これは現在の (狭められた) バッファーの内容物を調べて、MIME メッセージを含む文字列を返します。

単純な MML の例
==========

multipart/alternative の単純な例です:

     <#multipart type=alternative>
     This is a plain text part.
     これはプレーンテキストのパートです。
     <#part type=text/enriched>
     <center>This is a centered enriched part</center>
     <center>これは中心に置かれる enriched パートです</center>
     <#/multipart>

これを mml-generate-mime に通すと、次のものが得られます:

     Content-Type: multipart/alternative; boundary="=-=-="

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

     This is a plain text part.
     これはプレーンテキストのパートです。

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

     <center>This is a centered enriched part</center>
     <center>これは中心に置かれる enriched パートです</center>

     --=-=-=--

(実際には、日本語の部分は charset=iso-2022-jp でエンコードされたものになります。)

MML の定義
=======

MML 言語はとても単純です。SGML アプリケーションに少し似ていますが、異なるものです。

MML の主要な概念は「パート」です。それぞれのパートを異なるタイプにしたり、異なる文字セットを使うことができます。パートは <#part ...> タグで記述します。マルチパート型のパートは <#multipart ...> タグで始めます。それぞれのパートは <#/part> タグか <#/multipart> タグで終端しますが、(それらが無くても) <#part ...> で始まったタグは次のパートの始まりによっても閉じられます。

<#external ...> タグというものもあります。これは external/message-body 型のパートを記述するために使われます。

それぞれのタグは「parameter=値」の形式で、一つ以上のパラメーターを含むことができます (もちろん無いこともあります)。値をクォーテーションマーク ("...") で囲むことができますが、値が空白文字を含む場合以外は囲む必要がありません。したがって、filename=/home/user/#hello$^yes は完全に有効です。

以下のパラメーターは MML で使われるものです。意味を持たないパラメーターは無視されます。MML パラメーターの名前は MIME パラメーターの名前と同じで、括弧の中に付記してあるのは、それが使われるヘッダーです。

type
     パートの MIME タイプです (Content-Type)。

filename
     そのパートの本体が含むことになるファイルの名前です (Content-Disposition)。

charset
     パートの内容物をエンコードするときに使われる文字セットです (Content-Type)。See Charset Translation.

name
     パートをファイルに保存するときのファイル名を示唆するために使われるかもしれません (Content-Type)。

disposition
     配置指定に使います。有効な値は inline と attachment です (Content-Disposition)。

encoding
     有効な値は 7bit, 8bit, quoted-printable および base64 です (Content-Transfer-Encoding)。See Charset Translation.

description
     パートの説明書きです (Content-Description)。

creation-date
     パートが作成された時刻 (RFC822 形式) です (Content-Disposition)。

modification-date
     パートが変更された時刻 (RFC822 形式) です (Content-Disposition)。

read-date
     パートが読まれた時刻 (RFC822 形式) です (Content-Disposition)。

recipients
     パートを誰宛てに暗号化/署名するかを指定します。これは To/CC を基にした自動検出よりも優先されます。

sender
     パートに署名するときの名義です。このフィールドはディフォルトの鍵が使われないようにするために使われます。

size
     パートのサイズを octet (8-bit) の単位で表します (Content-Disposition)。

sign
     この MML のパートに、何の技術手段 (smime, pgp または pgpmime) で署名するかを指定します。

encrypt
     この MML のパートを、何の技術手段 (smime, pgp または pgpmime) で暗号化するかを指定します。

以下は text/plain のためのパラメーターです:

format
     テキストを整形するためのパラメーターで、有効な値は fixed (ディフォルト) と flowed です。普通はこれを手で設定しません。それは、テキストの本文が、RFC 2646 で定められた特別な方法で整形されることを必要とするからです。See Flowed text.

以下は application/octet-stream のためのパラメーターです:

type
     パートのタイプです (Content-Type)。これは人間が読むことを想定した、非公式なものです。

以下は message/external-body のためのパラメーターです:

access-type
     ファイルを取得するための、サポートされているアクセス手段を示す語です。値は ftp, anon-ftp, tftp, localfile および mailserver のどれかです。(Content-Type.)

expiration
     ファイルが取得できなくなるかもしれない日時 (RFC822 形式) です。 (Content-Type.)

size
     Octet (8-bit) の単位で表したファイルのサイズです。(Content-Type.)

permission
     有効な値は read と read-write です (Content-Type)。

以下は sign=smime のためのパラメーターです:

keyfile
     署名する人の鍵と証明書を含んでいるファイルです。

以下は encrypt=smime のためのパラメーターです:

certfile
     受取人の証明書を含んでいるファイルです。

高度な MML の例
==========

複雑なマルチパート・メッセージの例です。これは multipart/mixed です。多数のパートを含んでいて、その一つは multipart/alternative です。

     <#multipart type=mixed>
     <#part type=image/jpeg filename=~/rms.jpg disposition=inline>
     <#multipart type=alternative>
     This is a plain text part.
     これはプレーンテキストのパートです。
     <#part type=text/enriched name=enriched.txt>
     <center>This is a centered enriched part</center>
     <center>これは中心に置かれる enriched パートです</center>
     <#/multipart>
     This is a new plain text part.
     これは新しいプレーンテキストのパートです。
     <#part disposition=attachment>
     This plain text part is an attachment.
     このプレーンテキストのパートは添付ファイルです。
     <#/multipart>

そして、これが結果の MIME メッセージです:

     Content-Type: multipart/mixed; boundary="=-=-="

     --=-=-=
     Content-Type: image/jpeg
     Content-Disposition: inline; filename=rms.jpg
     Content-Transfer-Encoding: base64

     /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof
     Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/wAALCAAwADABAREA/8QAHwAA
     AQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQR
     BRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RF
     RkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ip
     qrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEB
     AAA/AO/rifFHjldNuGsrDa0qcSSHkA+gHrXKw+LtWLrMb+RgTyhbr+HSug07xNqV9fQtZrNI
     AyiaE/NuBPOOOP0rvRNE880KOC8TbXXGCv1FPqjrF4LDR7u5L7SkTFT/ALWOP1xXgTuXfc7E
     sx6nua6rwp4IvvEM8chCxWxOdzn7wz6V9AaB4S07w9p5itow0rDLSY5Pt9K43xO66P4xs71m
     2QXiGCbA4yOVJ9+1aYORkdK434lyNH4ahCnG66VT9Nj15JFbPdX0MS43M4VQf5/yr2vSpLnw
     5ZW8dlCZ8KFXjOPX0/mK6rSPEGt3Angu44fNEReHYNvIH3TzXDeKNO8RX+kSX2ouZkicTIOc
     L+g7E810ulFjpVtv3bwgB3HJyK5L4quY/C9sVxk3ij/xx6850u7t1mtp/wDlpEw3An3Jr3Dw
     34gsbWza4nBlhC5LDsaW6+IFgupQyCF3iHH7gA7c9R9ay7zx6t7aX9jHC4smhfBkGCvHGfrm
     tLQ7hbnRrV1GPkAP1x1/Hr+Ncr8Vzjwrbf8AX6v/AKA9eQRyYlQk8Yx9K6XTNbkgia2ciSIn
     7p5Ga9Atte0LTLKO6it4i7dVRFJDcZ4PvXN+JvEMF9bILVGXJLSZ4zkjivRPDaeX4b08HOTC
     pOffmua+KkbS+GLVUGT9tT/0B68eeIpIFYjB70+OOVXyoOM9+M1eaWeCLzHPyHGO/NVWvJJm
     jQ8KGH1NfQWhXSXmh2c8eArRLwO3HSv/2Q==
     --=-=-=
     Content-Type: multipart/alternative; boundary="==-=-="

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

     This is a plain text part.
     これはプレーンテキストのパートです。

     --==-=-=
     Content-Type: text/enriched; charset=iso-2022-jp; name=enriched.txt

     <center>This is a centered enriched part</center>
     <center>これは中心に置かれる enriched パートです</center>

     --==-=-=--

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

     This is a new plain text part.
     これは新しいプレーンテキストのパートです。

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

     This plain text part is an attachment.
     このプレーンテキストのパートは添付ファイルです。

     --=-=-=--

(実際には、日本語の部分は charset=iso-2022-jp でエンコードされたものになります。)

エンコーディングのカスタマイズ
===============

mm-body-charset-encoding-alist
     MIME 文字セットに割り当てるエンコーディングです。この変数は、例えば他の要件によって特定のエンコーディングが強制されないときに、通常使われます (電子署名されたメッセージは 7bit エンコーディングを必要とします)。ディフォルト値は次の通りです。

          ((iso-2022-jp . 7bit)
           (iso-2022-jp-2 . 7bit)
           (utf-16 . base64)
           (utf-16be . base64)
           (utf-16le . base64))

     例えば ISO-8859-1 文字セットが quoted-printable でエンコードされないようにしたい場合は、この変数に (iso-8859-1 . 8bit) を追加すれば良いでしょう。MML の encoding タグを使って、メッセージ毎にそれで指定した値をこの変数より優先させることもできます (see MML Definition)。

mm-coding-system-priorities
     送出するメッセージで使う coding system の優先度を指定します。ディフォルト値は nil です (その場合は Emacs におけるディフォルトの優先順位が適用されます) が、日本語環境で Emacs を実行する場合は (iso-8859-1 iso-2022-jp iso-2022-jp-2 shift_jis utf-8) になります。値は coding system のシンボルのリストです (coding system の別名を使っても構いません。設定するときは M-x describe-coding-system を使って、coding system の名前が正確であることを確かめて下さい)。例えば UTF-8 を最優先とするように Emacs を設定したものの、可能な場合は ISO-8859-1 でメッセージを送信するようにしたいという場合だったら、この変数を (iso-8859-1) にすれば良いでしょう。 MML の charset タグを使って、メッセージ毎にそれで指定した値をこの変数より優先させることもできます (see MML Definition)。

          訳注: 日本語環境とは current-language-environment 変数の値が Japanese になっている環境のことです。日本語のメッセージのエンコードには伝統的に iso-2022-jp が使われているのに対し、Emacs で定められた優先順位に基づくと euc-jp や shift_jis などが第一候補になってしまうので、この値が nil ではよろしくないのです。

          なお、ラテン語圏の人たちに宛てて送るメッセージが、彼らがデコードできないかもしれない iso-2022-jp-2 などでエンコードされてしまうのを防ぐために、ディフォルト値の先頭に iso-8859-1 が置かれています。

mm-content-transfer-encoding-defaults
     MIME のタイプに割り当てるエンコーディングです。この変数は、例えば他の要件によってより安全なエンコーディングが強制されないときに、通常使われます (電子署名されたメッセージは 7bit エンコーディングを必要とします)。通常の MIME エンコーディングの他に、 quoted-printable と base64 のうちで最も効率的な方を個々の場合に使うべきであることを示す qp-or-base64 を使うこともできます (訳注: qp-or-base64 の実際の動作は、quoted-printable と base64 の両方でエンコードしてみて、サイズが小さくなる方を採用することです)。

     qp-or-base64 にはもう一つの効果があります。それは MIME のパートが MTA によって壊されないようにするために、長い行を折り畳みます。quoted-printable と base64 もそうです。

     パートが受信したときのままの生の転送されたメッセージ (例えば、引数に 2 を与えた gnus-summary-mail-forward によって作られるもの) であるか、text/* タイプや message/* ではない場合に、これが本文のエンコーディグに影響を及ぼすことに注意して下さい。それらの場合でさえ、 MML の encoding タグを使って、メッセージ毎にそれで指定した値をこの変数より優先させることもできます (see MML Definition)。

mm-use-ultra-safe-encoding
     これが非-nil である場合、本文に 76 文字よりも長い行や "From " で始まる行があったら、それらのテキストのパートは quoted-printable でエンコードされます。非-7bit エンコーディング (8bit, バイナリー) は一般に認められていません。この変数を nil 以外の値に設定しておくことは、8bit を通さない MTA か MDA がメッセージを改変してしまう確率を下げます。これは直接に設定されるのではなく、他の関数によって (例えば、電子署名されるメッセージをエンコードするときに) 必要に応じて束縛されるべきです。

文字セットの変換
========

MML を MIME に変換するときに、Emacs の内部で作られた MIME パートのそれぞれについて、適切な文字セットを選ばなければなりません。

MULE 機能が無い Emacs を走らせている場合だったら、この処理は単純です。パートがどんな非-ASCII (8-bit) 文字を含んでいても、 mail-parse-charset で与えられる MIME 文字セット (シンボル) を使えば良いのです。(もっとも、この変数を直接に設定しないで下さい。ディフォルトの文字セットを変更したい場合は、MIME メッセージを処理するために使うパッケージの説明書を調べてください。例えば: see いろいろなメッセージ変数 (The Message Manual))。ASCII 文字セットしか無ければ、 US-ASCII が MIME 文字セットとして使われるのはもちろんです。

MULE 機能を備えた Emacs を走らせている場合は、ものごとは多少複雑になります。この場合は、パートで使われている MULE 文字セットのリストを取得し、Emacs 自身が提供するテーブルか、XEmacs のための mm-mime-mule-charset-alist 変数の値に基づいて、それらの MULE 文字セットを MIME 文字セットに変換します。結果が単一の MIME 文字セットだったら、それを使ってパートをエンコードします。しかし、結果の MIME 文字セットのリストが二つ以上の要素を含んでいる場合には、二つのことが起こり得ます。もしパートを UTF-8 でエンコードすることが可能だったら、その文字セットを使います。(このために Emacs は utf-8 coding system をサポートしていなければなりません。また、そのパートを構成するすべての文字に対応するものが、Unicode の定義に存在していなければなりません。)  何らかの理由によって UTF-8 を利用できない場合、そのパートは、それぞれが単一の MIME 文字セットでエンコードすることができるように、いくつかに分割されます。もっとも、パートは行の境界でしか分割することができないので、単一の行をエンコードするために複数の MIME 文字セットが必要だとすると、そのパートをエンコードすることは不可能です。

MULE 機能を備えた Emacs を走らせている場合、どの coding system を使うかの優先順位は Emacs 自身から継承されます。これは、もし Emacs が UTF-8 を優先するように設定されていると、それがメッセージのエンコードに使われるということです。ただし mm-coding-system-priorities 変数の値を変えることによって、これを変更することはできます (see Encoding Customization)。

メッセージを作成するときに MML の charset タグを設定することによって、使われる文字セットをそれにすることができます。

文字列のエンコーディング (quoted-printable, 8bit など) はここでの議論と直交する概念です。それは mm-body-charset-encoding-alist 変数と mm-content-transfer-encoding-defaults 変数によって制御されます (see Encoding Customization)。

変換
==

mime-to-mml 関数を使って MIME メッセージ (マルチパートでも可) を MML に変換することができます。これは現在のバッファーにある MIME メッセージに作用して、MIME の境界を MML の印付け (markup) で置き換えます。テキストではないパートの内容物は、そのバッファーに置かれる代わりに MML タグを介して参照される別のバッファーに置かれます。

mml-to-mime 関数を使って、逆に MML メッセージを MIME に変換することができます。

これらの関数が行なうことはある意味で「不可逆」(lossy) です。 mime-to-mml を実行し、次に mml-to-mime を実行すると、元とまったく同じメッセージには戻らないでしょう。ヘッダーの順序のようなどうでも良いことが違ってしまうだけでなく、それぞれのヘッダーの内容も変化してしまうかもしれません。例えば、元のメッセージが base64 でテキストをエンコードしてあっても、mml-to-mime は quoted-printable を使うかもしれない、というようなことです。

しかし本質的には、これら二つは互いに逆関数であるべきです。結果として生成されるメッセージの内容物が、同一でないにしても等価なままであるような。

流動テキスト
======

Emacs MIME ライブラリーは、メッセージをエンコードするときは use-hard-newlines 変数 (see Hard and Soft Newlines (Emacs Manual)) に従い、メッセージをデコードするときは Content-Type パラメーターの“format=flowed”を尊重します。

テキストをエンコードするとき、ソフト改行文字で終端されている各行は、use-hard-newlines に関わらずに fill-flowed-encode-column で決定される桁の後ろで折り畳まれて、耳を揃えられ (filled され) ます。引用の印 (^>* ?) は尊重されます。その変数は、流動テキストをサポートしないクライアントにおけるテキストの見え方を制御し、ディフォルトでは 66文字の後ろで折り畳みます。バッファーにハード改行文字が無ければ、流動 (flowed) テキストのためのエンコードは行ないません。

流動 (flowed) テキストをデコードするとき、ソフト改行文字を持つ各行は fill-flowed-display-column で決定される桁の後ろで折り畳まれて耳を揃えられ (filled され) ます。ディフォルトでは fill-column の後ろで折り畳みます。

mm-fill-flowed
     非-nil だったら、format=flowed の記事は流動的に表示されます。

インターフェース関数
**********

mail-parse ライブラリーは、次の章で述べる実際の低レベルなライブラリーを抽象化したものです。

標準は変化するので、プログラムも新しい鋳型に適合するために変化しなければなりません。例えば RFC2045 は、パラメーターのリストにおいて ASCII 文字だけを許容する Content-Type ヘッダーのための構文について述べています。RFC2231 は、複数行に渡って継続する単一のヘッダーと非-ASCII 文字の構成を規定するための RFC2045 の構文について詳しく記述しています。

これに対処する従来の方法は、単に新しい構文を解析するためにライブラリーの関数を更新することでした。しかしながら、これは時には誤った行為です。場合によっては、新しい構文と古い構文の両方を理解できるようにすることが重要かもしれないし、ライブラリーが一つしか無い場合には、ライブラリーの古いバージョンと新しいバージョンのどちらかを選ばなければなりません。

Emacs MIME ライブラリーは異なる方針で行くことにしました。これは、対応する標準に従って厳密に解析する一連の低レベルのライブラリー (rfc2047.el, rfc2231.el など) を定義します。とは言え、正規のプログラムは、これらのライブラリーが直接に提供する関数ではなく、代わりに mail-parse ライブラリーが提供する関数を使うべきです。このライブラリーにある関数は、最新の低レベルのライブラリーの、対応する関数への単なる別名です。この構成を使うことによって、プログラムはそれらが使うことができる首尾一貫したインターフェースを手に入れました。また、ライブラリーの開発者は、新しい標準を扱うコードを自由に作成することができます。

以下の関数が、このライブラリーで定義されています:

mail-header-parse-content-type
     Content-Type ヘッダーを解析して、以下の形式でリストを返します:

          ("type/subtype"
           (attribute1 . value1)
           (attribute2 . value2)
           ...)

     例です:

          (mail-header-parse-content-type
           "image/gif; name=\"b980912.gif\"")
          => ("image/gif" (name . "b980912.gif"))

mail-header-parse-content-disposition
     Content-Disposition ヘッダーを解析して、上記の関数と同じ形式のリストを返します。

mail-content-type-get
     上記の形式のリストと属性の二つのパラメーターを受け取り、その属性の値を返します。

          (mail-content-type-get
           '("image/gif" (name . "b980912.gif")) 'name)
          => "b980912.gif"

mail-header-encode-parameter
     パラメーターに使う文字列を受け取り、それをエンコードしたものを返します。これは Content-Type と Content-Disposition のようなヘッダーに入れるパラメーターのために使われます。

mail-header-remove-comments
     ヘッダーからコメントを取り除いたものを返します。

          (mail-header-remove-comments
           "Gnus/5.070027 (Pterodactyl Gnus v0.27) (Finnish Landrace)")
          => "Gnus/5.070027  "

mail-header-remove-whitespace
     ヘッダーから“linear white space”を取り除きます。クォートされた ("..." で囲まれた) 文字列の中にある空白文字とコメントは保存されます。

     訳注:“linear white space”とは一つ以上の空白文字のことで、その前に改行文字を置いたものは、長いヘッダーを折り畳むときに使われます。

          (mail-header-remove-whitespace
           "image/gif; name=\"Name with spaces\"")
          => "image/gif;name=\"Name with spaces\""

mail-header-get-comment
     ヘッダーの最後のコメントを返します。

          (mail-header-get-comment
           "Gnus/5.070027 (Pterodactyl Gnus v0.27) (Finnish Landrace)")
          => "Finnish Landrace"

     訳注: Finnish Landrace は 1998年8月23日にリリースされた XEmacs 21.0-pre11 のコードネームです。まあ、どうでもいいことですが。

mail-header-parse-address
     アドレスを解析して、メールアドレスとプレーンテキストの名前を含むリストを返します。

          (mail-header-parse-address
           "Hrvoje Niksic <hniksic@srce.hr>")
          => ("hniksic@srce.hr" . "Hrvoje Niksic")

mail-header-parse-addresses
     アドレスのリストを含んでいる文字列を解析して、上で述べたような要素のリストを返します。

          (mail-header-parse-addresses
           "Hrvoje Niksic <hniksic@srce.hr>, Steinar Bang <sb@metis.no>")
          => (("hniksic@srce.hr" . "Hrvoje Niksic")
               ("sb@metis.no" . "Steinar Bang"))

mail-header-parse-date
     日付の文字列を解析して、Emacs 形式の時刻を返します。

mail-narrow-to-head
     バッファーをヘッダーの区域に狭めます。ポイントは狭められたバッファーの先頭に置かれます。

mail-header-narrow-to-field
     バッファーを現在位置の (単一の) ヘッダーに狭めます。複数行に渡って継続するヘッダーを理解します。

mail-header-fold-field
     現在位置のヘッダーを折り畳みます。

mail-header-unfold-field
     現在位置のヘッダーの折り畳みを解除します。

mail-header-field-value
     現在位置のフィールドの値を返します。

mail-encode-encoded-word-region
     領域にある ASCII 以外の語をエンコードします。例えば Naïve は =?iso-8859-1?Q?Na=EFve?= としてエンコードされます。

     訳注: ここで言わんとしていることを確かめるには、以下を eval して下さい:

          (rfc2047-decode-string "=?iso-8859-1?Q?Na=EFve?=")

mail-encode-encoded-word-buffer
     現在のバッファーにある ASCII 以外の語をエンコードします。この関数は、ヘッダーの区域に狭められたメッセージで呼ばれることを意図しています。

mail-encode-encoded-word-string
     文字列に含まれているエンコードする必要がある語をエンコードして、結果を返します。

          (mail-encode-encoded-word-string
           "This is naïve, baby")
          => "This is =?iso-8859-1?Q?na=EFve,?= baby"

mail-decode-encoded-word-region
     領域にあるエンコードされた語をデコードします。

mail-decode-encoded-word-string
     文字列に含まれているエンコードされた語をデコードして、結果を返します。

          (mail-decode-encoded-word-string
           "This is =?iso-8859-1?Q?na=EFve,?= baby")
          => "This is naïve, baby"

現在 mail-parse は ietf-drums, rfc2047, rfc2045 および rfc2231 を網羅して抽象化します。これらについて、次以降の章で説明します。

基本的な関数
******

この章は、下位の階層に位置していて、解析と処理を行なうための基本的な関数について説明します。ここで扱うことは From 行の解析、ヘッダーの各行にあるコメントの削除、エンコードされた語のデコード、時刻ヘッダーの解析などです。上位階層の機能は最初の章 (see Decoding and Viewing) で扱われています。

訳注: RFC822bis == draft-ietf-drums-msg-fmt-09.txt

rfc2045
=======

RFC2045 は「主要な」MIME の文献です。ならば、そこにはたくさんの実装があるだろうと想像するでしょう。しかし、ほとんどの詳細な実装はその後の RFC に委ねられていて、そこにはありません。

と言うわけで rfc2045.el にはたった一つの関数があります:

rfc2045-encode-string
     パラメーターと値を受け取り、PARAM=VALUE の形式の文字列を返します。 VALUE に安全ではない文字があったらクォートされ ("..." で囲まれ) ます。

rfc2231
=======

RFC2231 は Content-Type と Content-Disposition ヘッダーの構文を定義します。その小粋な名称は「MIME パラメーター値と符号化単語拡張文字セット・言語そして継続」です。

一口で言うと、それらのヘッダーはこんなふうです:

     Content-Type: application/x-stuff;
      title*0*=us-ascii'en'This%20is%20even%20more%20;
      title*1*=%2A%2A%2Afun%2A%2A%2A%20;
      title*2="isn't it!"

普通はこんなにひどくないですが。

以下の関数がこのライブラリーで定義されています:

rfc2231-parse-string
     Content-Type ヘッダーを解析して、その要素を表すリストを返します。

          (rfc2231-parse-string
           "application/x-stuff;
           title*0*=us-ascii'en'This%20is%20even%20more%20;
           title*1*=%2A%2A%2Afun%2A%2A%2A%20;
           title*2=\"isn't it!\"")
          => ("application/x-stuff"
              (title . "This is even more ***fun*** isn't it!"))

rfc2231-get-value
     上記の形式のリストの一つを受け取り、指定された属性の値を返します。

rfc2231-encode-string
     Content-Type と Content-Disposition のようなヘッダーに入れるパラメーターをエンコードします。

ietf-drums
==========

drums は RFC822 の置き換え作業をしている IETF の作業部会です。

このライブラリーによって提供される関数は次の通りです:

ietf-drums-remove-comments
     引数からコメントを取り除いて、結果を返します。

ietf-drums-remove-whitespace
     文字列から“linear white space”を取り除き、結果を返します。クォートされた ("..." で囲まれた) 文字列の中にある空白文字とコメントには手を付けません。

     訳注:“linear white space”とは一つ以上の空白文字のことで、その前に改行文字を置いたものは、長いヘッダーを折り畳むときに使われます。

ietf-drums-get-comment
     文字列の最後尾にあるコメントを返します。

ietf-drums-parse-address
     アドレスの文字列を解析して、メールアドレスとプレーンテキストの名前を含むリストを返します。

ietf-drums-parse-addresses
     カンマで区切られた複数のアドレスを含んでいる文字列を解析して、メールアドレスとプレーンテキストの対を含むリストを返します。

ietf-drums-parse-date
     日付の文字列を解析して、Emacs 形式の時刻を返します。

ietf-drums-narrow-to-header
     現在のバッファーをヘッダーの区域に狭めます。

rfc2047
=======

RFC2047 (メッセージ・ヘッダーでの非-ASCII テキスト拡張) は、ヘッダーにある非-ASCII テキストをどのようにエンコードするかを定めています。実際これは少々複雑になるので、このライブラリーが行なうことを調整するために、多くの変数が必要です。

以下の変数が調整可能です:

rfc2047-header-encoding-alist
     これはヘッダーとエンコーディング・タイプの対を収めた連想リストです。その主な目的は、ある種のヘッダーがエンコードされないようにすることです。

     鍵 (訳注: 各要素の car 項) はヘッダーに合致する正規表現か t のどちらかです。

     値 (訳注: 各要素の cdr 項) は nil にすることができて、その場合、鍵に相当するヘッダーはエンコードされません。mime はそれらをエンコードすることを意味しますが、address-mime の場合はヘッダーがアドレスを含んでいることを想定して注意深くエンコードします。

rfc2047-charset-encoding-alist
     RFC2047 は二つのエンコーディングの形式を定めています。一つは Q (Quoted-Printable のようなエンコーディング) で、もう一つは B (base64) です。この連想リストは、ある文字セットに対してどのエンコーディングを使うかを規定します。

rfc2047-encode-function-alist
     これはエンコーディングとそれを実施するための関数の対を収めた連想リストです。エンコーディングとは Q, B および nil のことです。

rfc2047-encoded-word-regexp
     デコードを行なうとき、このライブラリーはこの正規表現に合致するものを探します。

rfc2047-encode-encoded-words
     エンコード済みの語 (例えば =?hello?=) を再度エンコードするかどうかを決めるブール変数です。

以上は変数でした。次は関数です:

rfc2047-narrow-to-field
     バッファーを現在の行のヘッダーに狭めます。

rfc2047-encode-message-header
     メッセージのヘッダーに狭められたバッファーで使わなければなりません。 rfc2047-header-encoding-alist に従ってエンコードを行ないます。

rfc2047-encode-region
     指定された領域にあるすべてのエンコード可能な語をエンコードします。

rfc2047-encode-string
     文字列をエンコードして結果を返します。

rfc2047-decode-region
     領域にあるエンコードされた語をデコードします。

rfc2047-decode-string
     文字列をデコードして結果を返します。

rfc2047-encode-parameter
     パラメーターを RFC2047 ふうの様式でエンコードします。これは rfc2231-encode-string の置き換えです。See rfc2231.

     ファイルを MIME のパートとして添付するとき、非-ASCII 文字を含むファイル名を指定するには RFC2231 のエンコーディングを使わなければなりません。しかし、実際問題として多くのメールソフトがそれをサポートしていないので、受信者は正しいファイル名を抽出することができません。代わりに RFC2047 ふうのエンコーディングが広く受け入れられています。そんな情けない風潮を甘受して、この関数は RFC2047 によく似たエンコーディグの機能を提供します。これを使うには ~/.gnus.el ファイルに次の行を入れて下さい:

          (defalias 'mail-header-encode-parameter 'rfc2047-encode-parameter)

time-date
=========

本当は MIME ライブラリーの一部ではありませんが、ここで説明することは都合が良いのです。これは日付ヘッダーの解析と時刻の操作を扱います。 (もっとも四次元立方体は使いません。ごめんなさい。)

これらの関数は五つの形式 (時刻の文字列、Emacs 形式の時刻、デコードされた時刻のリスト、秒数、および日数) の間で変換を行ないます。

時刻/日付/秒数/日数の相互変換の例です:

     (parse-time-string "Sat Sep 12 12:21:54 1998 +0200")
     => (54 21 12 12 9 1998 6 nil 7200)

     (date-to-time "Sat Sep 12 12:21:54 1998 +0200")
     => (13818 19266)

     (time-to-seconds '(13818 19266))
     => 905595714.0

     (seconds-to-time 905595714.0)
     => (13818 19266 0)

     (time-to-days '(13818 19266))
     => 729644

     (days-to-time 729644)
     => (961933 65536)

     (time-since '(13818 19266))
     => (0 430)

     (time-less-p '(13818 19266) '(13818 19145))
     => nil

     (subtract-time '(13818 19266) '(13818 19145))
     => (0 121)

     (days-between "Sat Sep 12 12:21:54 1998 +0200"
                   "Sat Sep 07 12:21:54 1998 +0200")
     => 5

     (date-leap-year-p 2000)
     => t

     (time-to-day-in-year '(13818 19266))
     => 255

     (time-to-number-of-days
      (time-since
       (date-to-time "Mon, 01 Jan 2001 02:22:26 GMT")))
     => 4.146122685185185

あと、safe-date-to-time というものもあります。これは date-to-time と同じことをしますが、日付が構文的に不完全だった場合にゼロ時刻を返します。

五つのデータは以下のように表現されます:

date
     RFC822 (または類似の) 形式の日付の文字列。例: "Sat Sep 12 12:21:54 1998 +0200"

time
     Emacs の内部形式の時刻。例: (13818 26466)

seconds
     Emacs の内部形式の時刻を浮動小数で表したもの。例: 905595714.0

days
     00000101 を基点とする経過日数を整数で表したもの。例: 729644

     訳注: 00000101 が何を意味するのか不明ですが、ソースコードによればグレゴリオ歴・紀元前 (BC ではなく BCE の方の) 0001年12月31日のことらしいです。

decoded time
     デコードされた時刻のリスト。例: (54 21 12 12 9 1998 6 t 7200)

上記のすべての例は、同じ時を表しています。

関数には以下のようなものがあります:

date-to-time
     日付を受け取って時刻を返します。

time-to-seconds
     時刻を受け取って秒数を返します。

seconds-to-time
     秒数を受け取って時刻を返します。

time-to-days
     時刻を受け取って日数を返します。

days-to-time
     日数を受け取って時刻を返します。

date-to-day
     日付を受け取って日数を返します。

time-to-number-of-days
     時刻を受け取って、それが表している日数を返します。

safe-date-to-time
     日付を受け取って時刻を返します。日付が構文的に正しくなかったら「ゼロ」時刻を返します。

time-less-p
     二つの時刻を受け取って、一つ目が二つ目より少ない (すなわち早い) かどうかを示します。

time-since
     時刻を受け取って、その時刻からどれほど時間が経過したかを示します。

subtract-time
     二つの時刻を受け取って、一つ目から二つ目を減算します。すなわち、二つの時刻の間の時間差を返します。

days-between
     二つの日付を受け取って、それら二つの日付の間の日数を返します。

date-leap-year-p
     年の数値を受け取って、それがうるう年かどうかを示します。

time-to-day-in-year
     時刻を受け取って、その年の元日から経過した日数を返します。

qp
==

このライブラリーは Quoted-Printable によるテキストのデコードとエンコードを扱います。

非常に手短かに説明すれば、qp エンコーディングはすべての 8-bit 文字 (と多くの制御文字) を =EF のようなもの (イコール記号と、それに続く 16進数にエンコードされたバイト) に変換することです。

このライブラリーでは、以下の関数が定義されています:

quoted-printable-decode-region
     指定された領域にあるすべてのエンコードされたテキストを QP-デコードします。

quoted-printable-decode-string
     文字列に含まれている QP-エンコードされたテキストをデコードして、結果を返します。

quoted-printable-encode-region
     指定された領域にあるすべてのエンコード可能な文字を QP-エンコードします。省略できる第三引数 FOLD は、長い行を折り畳むかどうかを指定します。 (ここで「長い」は 72桁を越えるもののことを意味します。)

quoted-printable-encode-string
     文字列に含まれているすべてのエンコード可能な文字を QP-エンコードして、結果を返します。

base64
======

Base64 は 3-バイトを 4-バイトにエンコードします。そのため、約 33% サイズが増えます。アルファベットだけでエンコードするので、伝送される途中で出会うかもしれない障害に対してとても耐久力があります。

以下の関数がこのライブラリーによって定義されています:

base64-encode-region
     選択された領域を base64 でエンコードして、エンコードされたテキストの長さを返します。省略できる第三引数 NO-LINE-BREAK は、長い行をより短い行に折り畳まないことを指図します。

base64-encode-string
     文字列を base64 でエンコードして結果を返します。

base64-decode-region
     選択された領域を base64 でデコードして、デコードされたテキストの長さを返します。領域がデコード可能でなかったら、nil を返すだけでバッファーは変更しません。

base64-decode-string
     文字列を base64 でデコードして結果を返します。文字列がデコード可能でなかったら nil を返します。

binhex
======

binhex はマッキントッシュの環境に源を発するエンコーディングです。以下の関数がそれらを扱うために供給されています:

binhex-decode-region
     領域にあるエンコードされたテキストをデコードします。第三パラメーターが与えられると、binhex のヘッダーをデコードしてファイル名を返すことだけをします。

uudecode
========

base64 がメールの世界を支配しているものの、おそらく uuencode はまだ Usenet で使われているものの中で、最も普及しているバイナリーのエンコーディングです。

以下の関数がこのパッケージによって供給されています:

uudecode-decode-region
     領域にあるテキストをデコードします。

yenc
====

yenc は Usenet でバイナリーをエンコードするために使われます。以下の関数がこのパッケージによって供給されています:

yenc-decode-region
     領域にあるエンコードされたテキストをデコードします。

rfc1843
=======

RFC1843 はメッセージにおける中国語と ASCII 文字の混在文を扱います。本質的には、RFC1843 は以下のように ASCII と中国語を切り替えるものです:

     This sentence is in ASCII.
     The next sentence is in GB.~{<:Ky2;S{#,NpJ)l6HK!#~}Bye.

まったく単純で、中国では広く使われています。

このエンコーディングを扱うために、以下の関数を使うことができます:

rfc1843-decode-region
     領域にある HZ-エンコードされたテキストをデコードします。

rfc1843-decode-string
     HZ-エンコードされた文字列をデコードして結果を返します。

mailcap
=======

~/.mailcap ファイルはほとんどの MIME に対応したメッセージ・ハンドラーによって解析されます。それには、各要素がどのように表示されるものと想定されているかを記述します。ファイルの例です:

     image/*; gimp -8 %s
     audio/wav; wavplayer %s
     application/msword; catdoc %s ; copiousoutput ; nametemplate=%s.doc

これは、すべての画像ファイルは gimp で表示されるべきであること、 WAVE 音響ファイルは wavplayer で再生されるべきであること、そして MS-WORD ファイルは catdoc によってインライン表示されるべきであると言っています。

mailcap ライブラリーはこのファイルを解析して、合致するタイプのための関数を提供します。

mailcap-mime-data
     この変数は、バックアップされた (訳注: mailcap ファイルの内容を解析して Emacs が扱い易い形式にした) 表示規則を含んでいる、連想リストの連想リストです。

インターフェース関数:

mailcap-parse-mailcaps
     ~/.mailcap ファイルを解析します。

mailcap-mime-info
     引数として MIME タイプを受け取り、合致するビューワーを返します。

標準
**

Emacs MIME ライブラリーは、(やや) 多くの RFC、ドラフトおよび標準ドキュメントに従って、様々な要素を取り扱います。この章では関連するものを列挙します。これらはすべて http://quimby.gnus.org/notes/ から取得可能です。

RFC822
STD11
     ARPA インターネットテキストメッセージの書式のための標準。

RFC1036
     USENET メッセージ交換のための標準。

RFC2045
     インターネットメッセージの本文の書式。

RFC2046
     メディアタイプ。

RFC2047
     メッセージヘッダーでの非-ASCII テキスト拡張。

RFC2048
     登録手続。

RFC2049
     適合基準と事例。

RFC2231
     MIME パラメーター値とエンコードされた単語の拡張: 文字セット、言語および継続。

RFC1843
     HZ - 中英混在文を含むファイル交換のためのデータ形式。

draft-ietf-drums-msg-fmt-05.txt
     RFC822 の後継のための草稿。

RFC2112
     MIME Multipart/Related Content-type。

RFC1892
     メールシステムの管理メッセージをリポートするための Multipart/Report Content Type。

RFC2183
     インターネットメッセージの情報通信表現: Content-Disposition ヘッダーフィールド。

RFC2646
     流動テキストのための text/plain 書式パラメーター。